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?

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

"scott.stark@jboss.org" wrote:
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?

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

+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.

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.

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

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.

It it possible to have this patch today?

Yes, I'm testing it now.

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