Sunday Feb 27, 2011

Automatic Starting Implementation Details for GlassFish 3.1

Process Nuts and Bolts

When you start a GlassFish 3.1 Server Service notice that there are 2 JVM processes running.  The 2 process are these:

  1. The GlassFish Server
  2. A JVM running asadmin start-[local-instance|domain] --verbose

Why?  We want to leverage the start command.  Asadmin does a great deal of work for you when you start a server.  The end-product of that work is mainly (but not only) the generation of a big complex JVM invocation command to start the server with.  I could have implemented the Services to call asadmin and have asadmin exit.  But then the Platform would see that asadmin exited and would report the service as "stopped".  It would not know in the future when the server really stops. 

When you start a server with the --verbose flag then the asadmin process waits for the server to die before exiting.  When the server stops -- asadmin stops and the Platform will update the state to "stopped".

Note that restart-[domain|instance] will still work perfectly.  In that case the server process dies but the asadmin process does not - not even for a moment.  The platform will not "see" anything happening.

Linux

I discovered that there seems to be a special way to create services for every different flavor of Linux.  And they are all different from each other.  Basically all of these different ways end up with writing out special files into a special area.  This one common denominator is to use the ancient UNIX way of setting up services which is, not surprisingly, editing lots of configuration files in a special area.  Even the exact details on the special area is different among the different flavors.  The code is flexible and will handle all known Linux flavors. The script can be found in /etc/init.d and links to it in the runlevel directories:  /etc/init.d/rc?.d


Automatic Starting of Servers in GlassFish 3.1

Note: At the end of this blog are links to older blogs from V3.0 about this feature.  You may want to look them over as well.

The way we offer the ability to automatically start GlassFish servers is via "services" on the platform.  "Services" are an ancient technology, available on all of our supported platforms (and I would imagine is available on every serious OS).  Services allow applications to run automatically when a computer boots up.  Nobody needs to login -- the service just starts automatically.  A simple example of this is the FTP server.  When you boot up your computer you can access FTP from any other computer without touching the FTP computer.  This is very important in the event of a power failure.  On Windows you can setup automatic security updates and Windows will automatically reboot your computer.  If you have a Subversion server that is not configured as a service and you are halfway around the world depending on it -- you will become a Services Specialist in the near future when you return home!

GlassFish 3.1 Platform Services now supports all Linux versions, Windows and Solaris10/SMF

Services can be quite complex.  For instance you might want to have it do this:

  1. Automatically start a GlassFish server upon booting
  2. If the server crashes (no way!) restart it
    What if it crashes every time?  The machine will be in trouble with an infinite loop so:
  3. Try to restart 3 times and then give up.

Setting up this level of services-granularity is very difficult and expensive to implement perfectly.  For one - we are supporting several platforms and they all do these things completely differently. The hard part is setting up services at all to do the basic things.  Once that is complete you can easily use the platform's native tools for adjusting things just the way you like.  What we support is the classic services model -- which is to start the service upon booting, unattended.

I worked hard to make it easy to setup services.  Here's how you would create them for an installation that has one Domain:

asadmin create-service

If you want to make sure it would work but you aren't yet ready to pull the trigger, or you just want to see what it would do -- then run this command:

asadmin create-service --dry-run

If your domain is named, say. domain1 then the service's name will be domain1.  Simple.

 After the service is created you are greeted with a platform-specific message giving you the details on how to start the service.  We do NOT automatically start it.  I personally recommend rebooting immediately -- and it will start.

Windows is particularly easy and flexible to work with.  You can manage the GlassFish service(s) by:

  1. GUI -- right-click on Computer/Manage/Services
  2. sc.exe  very handy tool for querying/starting/stopping/restarting etc.
  3. In the bin directory of the domain or instance run the your-service-nameService.exe application that we put in there. 

How to setup automatic starting for an instance?

Easy!  Simply give the name of the instance as the final argument to create-service.  The following command will create a service for myinstance:

asadmin create-service myinstance

There is an undocumented, unsupported command that will delete a service for you.  It is very very easy to delete a service on SMF and Windows.  On Linux it can be tedious.  I've personally tested the command successfully but it has not been through the merciless testing of QA at Oracle.  Use it at your own risk.

asadmin _delete-service 

Important blog for making sure GlassFish doesn't stop when you logout.

I have another blog with implementation details if you are interested.

Some older blogs that pertain to V3.0:

V3.0 Platform Services for Windows and SMF

DIY Cookbook for Configuring Linux Services

How to Run on Linux as a Non-Root User

Thursday Mar 04, 2010

Run GlassFish V3 as a non-root Service on Linux Ubuntu/Debian

Background

I already showed you how to setup GlassFish V3 as a Service on Linux here.  In that blog I used root as the GlassFish "owner" for simplicity.  In this blog we will do the same thing except with a non-root user.  If you already have a user and/or you have V3 installed you can skip some of the earlier steps.  Once again my main motivation is to get these procedures worked out carefully so that I can implement it automatically.  Currently we support Windows and Solaris 10.  For each step I'll also show you how to undo the change in case you want to rollback everything.

1. Create a user

I decided to create my own GlassFish user that exists solely to run GlassFish.  You could use your own existing account as well.  I also created a new group for use only by this user.  I.e. I don't want this user to have any Linux admin privileges.

sudo groupadd glassfish
sudo useradd -s /bin/bash -d /home/glassfish -m -g glassfish glassfish 

UNDO:

sudo userdel glassfish
sudo groupdel glassfish

2. Login as the new user in a terminal window and set a password (if desired)

sudo passwd glassfish
sudo -i -u glassfish


3. Install GlassFish V3 using user glassfish

cd ~
wget  http://download.java.net/glassfish/v3/release/glassfish-v3.zip
unzip glassfish-v3.zip
rm glassfish-v3.zip

UNDO:

rm -rf ~/glassfishv3

 
  

4. Exit the shell from step 2

 
  

5. Copy the script to /etc/init.d  and configure it as a Service

sudo cp the-script /etc/init.d/glassfish
sudo update-rc.d glassfish defaults

UNDO:

sudo rm /etc/init.d/glassfish
sudo update-rc.d glassfish remove

All Done

You can start, stop or restart GlassFish V3 like so.  Note that you must do it with an account that has admin privileges.  The user "glassfish" ironically can not do this even though the server will run as "his" process.

sudo /etc/init.d/glassfish start|stop|restart

How to Allow GlassFish V3 to use ports less than 1024

 This technique configures the firewall to send all port 80 traffic to port 8080.  You can do the same thing for any other ports you need that are less than 1024.  I don't know how to undo it.

iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080
iptables -t nat -A PREROUTING -p udp -m udp --dport 80 -j REDIRECT --to-ports 8080

Service Script

#!/bin/sh
# Platform Services for GlassFish
#

GF_USER=glassfish
GF_HOME=/home/$GF_USER/glassfishv3/glassfish
ASADMIN=$GF_HOME/bin/asadmin
SU="su --login  $GF_USER --command  "

case "$1" in
start)

    $SU "$ASADMIN start-domain > /dev/null 2>&1 &"

    ;;

stop)

    $SU "$ASADMIN stop-domain > /dev/null 2>&1 &"

    ;;

restart)

    $SU "$ASADMIN restart-domain > /dev/null 2>&1 &"

    ;;

\*)
    echo "usage: $0 (start|stop|restart|help)"

esac

Wednesday Feb 24, 2010

How to Run GlassFish V3 as a Service on Linux Ubuntu/Debian

We already support running GlassFish V3 as a service on Solaris 10 and Windows platforms (see my blog).  I have been investigating how to provide support for automatically starting GlassFish V3 as a service on Linux.  Of course before I can hope to do that -- I must be able to set it up manually.  In this blog I will take you through the manual steps needed to run GlassFish V3 as a service on Linux.

This procedure was worked out on my Linux system which happens to be Ubuntu.  Other flavors of Linux may have slightly different procedures.

One decision you need to make right up front is what Linux user should "own" GlassFish V3.  Typically root is used as the owner.  If you choose root as the user you get the advantage that you can use ports < 1024 without complex configuration changes to the system.  For this blog I used root.

 Here are the steps  -- the file named "glassfish" in step 4 is the simple init script which appears at the end of this blog.

  1. Install JDK 6 if needed
  2. Have root install GlassFish like so:
    1. cd /opt
    2. wget  http://download.java.net/glassfish/v3/release/glassfish-v3.zip
    3. unzip glassfish-v3.zip
    4. rm glassfish-v3.zip
  3. cd /etc/init.d
  4. cp glassfish .
  5. update-rc.d glassfish defaults
  6. OPTIONAL /etc/init.d/glassfish start
  7. OPTIONAL Make sure GlassFish is running OK
  8. reboot -- you are done!

To start, stop, restart GlassFish simply run these commands:

sudo /etc/init.d/glassfish start
sudo /etc/init.d/glassfish stop
sudo /etc/init.d/glassfish restart


#!/bin/sh

#
# glassfish init script for Linux
# Simplest possible case -- no password file, one default domain
# it would be simple to add such options

GLASSFISH_HOME=${GLASSFISH_HOME:-"/opt/glassfishv3/glassfish"}

case "$1" in
start)
    $GLASSFISH_HOME/bin/asadmin start-domain >/dev/null
    ;;
stop)
    $GLASSFISH_HOME/bin/asadmin stop-domain >/dev/null
    ;;
restart)
    $GLASSFISH_HOME/bin/asadmin restart-domain >/dev/null
    ;;
\*)
    echo "usage: $0 (start|stop|restart|help)"
esac



Saturday Feb 13, 2010

How to make GlassFish 3.1 Platform Services Survive Logoff

Refer to my other blog for general details about setting up Platform Services

A running JVM does not survive the user logging off unless you wave a magic wand over the JVM startup parameters.  It is very simple.  If you give the -Xrs option then the JVM will completely ignore logoff events (as well as others).  The solution in V3 is very simple but first let me give you a little background.  Skip to the end of  this blog to see the solution if you are in a hurry.

 In V2 all you needed to do was add -Xrs as a jvm-option to domain.xml and you were all set.  If you tried this on V3 you'll have noticed that it does not work.  The reason is that V3 running as a service is really two separate JVM's.  There is an asadmin "watchdog" JVM and the V3 JVM.  This arrangement is exactly like running asadmin start-domain --verbose at a command line.  These 2 JVMs go through life together.  If one dies then the other is automatically killed.  That's the problem.  You can set the -Xrs flag in domain.xml but if the asadmin JVM does not also have it set, then logging off will kill the asadmin JVM which, in turn, will automatically take the V3 JVM down with it. 

The solution is simple: set -Xrs on both JVMs.  I verified that V3 running as a service will only survive a logoff if both JVM's have it set.  I tested all 4 combinations:

 domain.xml   -Xrs ?

 asadmin   -Xrs?

 Survives Logoff event?

 No

 No

 No

 Yes

 No

 No

 No

 Yes

 No

 Yes

 Yes

 Yes


My recommendation is to set -Xrs for asadmin once and then forget about it.  You can always adjust the behavior exclusively from domain.xml.

 Solution

  1. asadmin create-jvm-options -Xrs

  2. edit install-root/bin/asadmin[.bat] and add the -Xrs option to the java command

To turn off the behavior run this command:

asadmin delete-jvm-options -Xrs


Sunday May 31, 2009

Platform Services Available in V3

Platform Services have just been rolled out for the first 2 platforms:

  • Solaris  Management Facility (SMF)
  • Windows

In the simplest case where you have one default domain and you want to run it as a service you run this command:

asadmin create-service

Here are all of the options:

[--passwordfile password-file] [--name service-name] [--serviceproperties (name=value)+] [--dry-run=false] [--domaindir domain_parent_directory] [domain_name]

 Once you have created the service it can be controlled in various ways by operating system and native tools. 

 Windows

We use Windows Service Wrapper as the tool for installing the service.  It can be used to start stop and uninstall the service.  It can be found in the bin subdirectory of the domain directory.  In the default case the name of the executable will be domain1Service.exe  The directory also contains the configuration file, domain1Service.xml.  Below are the available commands:

  • domain1Service start
  • domain1Service stop
  • domain1Service uninstall
  • domain1Service install
You can also manage the GlassFish service with Windows tools:  Services snap-in and the net command line program.

Solaris  Management Facility (SMF)

You create the service exactly the same as WIndows.  One big difference for most users is that on Windows most users have administration privileges.  I.e. everyone is super-user.  Not so on Solaris.  In order to create a service you must have SMF privileges.  How to set that up is beyond the scope of this blog, but root definitely has these privileges by default 

 Important: If root creates a service then only root can start that domain from then on.  The best way to set this up is to install and/or create the domain as root and then create the service as root.

Once you have created the service you need to start it yourself.  Here are the most typical Solaris commands of interest:

  • /usr/bin/svcs  -a | grep domain1  // status
  • /usr/sbin/svcadm enable domain1 // start
  • /usr/sbin/svcadm disable domain1 // stop
  • /usr/sbin/svccfg delete domain1 // uninstall

Future Directions

If there is interest, demand and time we will add support for controlling the service from CLI:

  • start
  • stop
  • uninstall
  • restart




About

ByronNevins

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today