run.sh to launch JBoss in background

[mazz]

I want to write an init.d script with the typical start - stop options to start JBossAS. I want to use the method of writing a pid file when started and killing the pid found in the file when stopping.

I do not want to use the "normal" shutdown mechanism to stop it because that assumes the JBoss instance has exposed its remote MBean interface (and I do not want to assume that). Plus, I want to ensure it is killed, and using the "kill" command is as fool-proof as I need it to be.

I also want to be able to use run.sh to start the instance (I do not want to have to do all the work run.sh does - setting up the JVM, passing in arguments, worrying about all the cygwin - darwin things, etc. etc.).

But, if my init.d script starts run.sh, I cannot use $! in my init.d script as the pid file contents because $! is the pid of run.sh script process. It is NOT the pid of the JBoss JVM instance itself. If I then go to kill the run.sh process, it dies, but the JVM process does not. Therefore, the init.d stop option does not work - it cannot stop the JBoss VM.

I would like to propose to make the following change to run.sh that would facilitate this. This change is backwards compatible. What this change does is - if I set the environment variable "LAUNCH_JBOSS_IN_BACKGROUND" and source run.sh, run.sh will export JBOSS_PID as the pid value of the JVM process. My init.d script (the thing that sources run.sh) will be able to write JBOSS_PID anywhere I want and thus later be able to use it to kill the JBoss VM. Here is the change I propose (it only changes the bottom - I wrap the existing loop in an if-statement with the else clause running the VM in background):

if [ "x$LAUNCH_JBOSS_IN_BACKGROUND" = "x" ]; then
### START - BELOW IS WHAT ALREADY EXISTS IN run.sh
 STATUS=10
 while [ $STATUS -eq 10 ]
 do
 # Execute the JVM
 "$JAVA" $JAVA_OPTS \
 -Djava.endorsed.dirs="$JBOSS_ENDORSED_DIRS" \
 -classpath "$JBOSS_CLASSPATH" \
 org.jboss.Main "$@"
 STATUS=$?
 # if it doesn't work, you may want to take a look at this:
 # http://developer.java.sun.com/developer/bugParade/bugs/4465334.html
 done
### END - ABOVE IS WHAT ALREADY EXISTS IN run.sh
else
 "$JAVA" $JAVA_OPTS \
 -Djava.endorsed.dirs="$JBOSS_ENDORSED_DIRS" \
 -classpath "$JBOSS_CLASSPATH" \
 org.jboss.Main "$@" &
 JBOSS_PID=$!
 export JBOSS_PID
fi

Its important to note that if you use this LAUNCH_JBOSS_IN_BACKGROUND feature, you have to "source" run.sh (you can't execute it from your init.d process because environment variables do not export up to a parent process - you have to ". run.sh" in order to get that exported environment variable into the shell that sourced run.sh).

[starksm64]

I guess I would ask why even keep the loop. As far as I know its useless as when does an exit code of 10 show up? Certainly no problem with this change, but why not make the only change whether or not the command in run in the background?

[ips]

Another option would be to modify run.sh so that it writes out a pidfile. For example:

server/default/log/jboss.pid

Then, John's rc script could read that file to figure out the pid of the JBoss instance, and it would not be necessary to source run.sh.

Ian

[mazz]

I don't know why the loop :-) I was assuming the server would exit specifically with a code of 10 as a way for it to indicate it wants to be "rebooted" immediately. I don't know if it ever does, but why that loop if not for the ability for the server to say it wants to be restarted upon exit? Just a guess.

But for 100% backward compatibility, I just left it as is so the script would do exactly what it did before if that LAUNCH_IN_BACKGROUND var isn't set. I have no problems with taking that loop out:

if [ "x$LAUNCH_JBOSS_IN_BACKGROUND" = "x" ]; then
 "$JAVA" $JAVA_OPTS \
 -Djava.endorsed.dirs="$JBOSS_ENDORSED_DIRS" \
 -classpath "$JBOSS_CLASSPATH" \
 org.jboss.Main "$@"
else
 "$JAVA" $JAVA_OPTS \
 -Djava.endorsed.dirs="$JBOSS_ENDORSED_DIRS" \
 -classpath "$JBOSS_CLASSPATH" \
 org.jboss.Main "$@" &
 JBOSS_PID=$!
 export JBOSS_PID
fi

[dimitris]

I guess I would ask why even keep the loop. As far as I know its useless as when does an exit code of 10 show up? Certainly no problem with this change, but why not make the only change whether or not the command in run in the background?

The loop now works (it was broken for some time)

http://jira.jboss.com/jira/browse/JBAS-2483

[mazz]

see:

http://jira.jboss.com/jira/browse/JBAS-3748

patch is attached to that JIRA issue.

[dimitris]

I don't think this is the right way to solve this.

It would be better to avoid the passing of variables back and forth and the background functionality in run.sh script and control it solely from the init.d script or whatever.

Then change run.sh to

a) remember the PID of the java process
b) install a trap that will simply forward the signal you are interested to the child java process

See
http://learnlinux.tsf.org.za/courses/build/shell-scripting/ch12s03.html

[mazz]

That's OK with me too. Just as long as it works on all platforms (hopefully, the traps syntax and feature is supported on all platforms, Cygwin included - I haven't tried this method because I wasn't sure I could get it to work on all platforms - if you are confident that this would work, I'm all for it).

[ips]

+1 - I like it because it encapsulates all the complexity in run.sh, and the user can simply treat the run.sh process as if it is the JBoss process itself.

So we'd have to add a line like the following to run.sh for each signal we want to relay:

trap "kill -1 $JBOSS_PID" 1

I guess, at a minimum, we'd want to support 1 (HUP), 10 (JBoss restart), and 15 (TERM).

Or you could use something like the following to support all signals:

i=0
while [ "$i" -le 64 ]; do
[ "$i" -ne 9 ] && [ "$i" -ne 19 ] && trap "kill -$i $JBOSS_PID" $i
i=`expr $i + 1`
done

Note, I skip 9 (KILL) and 19 (STOP), because these can't be trapped, and POSIX impls of trap are not required to even allow them as args. I'm not sure if the max signal number on Solaris, HP-UX, etc. is 64, as it is on Linux, so some testing would be required there in order to make sure the above while loop is portable.

[dimitris]

I think trap'ing 1 10 15 would be Ok.

Ian, you look quite confident, so do you want to test this and attach a patch to the case.

I wonder if this will work in cygwin.

[dimitris]

Actually 10 is the exit code of jboss when restarted, so the loop can kick in, so we don't need to catch this.

[ips]

Sure, I'll add support for trapping 1, 10, and 15, and test it on RHEL and Cygwin. If it appears to be working, I'll attach a patch to JBAS-3748.

[dimitris]

It it possible to have this patch today?

[ips]

Yes, I'm testing it now.

[dimitris]

Ideally we just want to say, forward received traps to any child process, like what the shell does when executed in interactive mode.

When using 'trap' the problem is you don't have the PID of the executing java process, unless you start java in the background.

The following seems to work

 # Execute the JVM in the background
 "$JAVA" $JAVA_OPTS \
 -Djava.endorsed.dirs="$JBOSS_ENDORSED_DIRS" \
 -classpath "$JBOSS_CLASSPATH" \
 org.jboss.Main "$@" &
 JBOSS_PID=$!
 trap "kill -HUP $JBOSS_PID" SIGHUP
 trap "kill -TERM $JBOSS_PID" SIGTERM
 wait

i.e. using this you can run.sh in the background, then killing run.sh kills the JVM too, but I'd prefer a solution where we don't have to start the JVM in the background and wait.