[jboss-jira] [JBoss JIRA] Updated: (JBAS-3748) give run.sh the ability to run the VM in background and export the PID as an env. var.

[Ian Springer (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBAS-3748?page=all ]

Ian Springer updated JBAS-3748:
-------------------------------

    Attachment: run.sh.patch

Here is a patch to https://svn.jboss.org/repos/jbossas/branches/Branch_4_0/system/src/bin/run.sh that enables run.sh to intercept signals and pass them on to the JBoss java process. I've tested it on RHEL and Cygwin, and it works correctly. It will still need to be tested on Solaris, HP-UX, AIX, etc..

A few notes on the implementation:

Note, java is execed in the bg - this is necessary in order to get its pid and set traps which can send signals to the java process.

The while WAIT_STATUS loop was the tricky part - it took me a while to get this right. I found that the traps get triggered as soon as the java proc receives a signal, even if the process hasn't actually terminated yet.

It's necessary to call wait once to catch the signal and again to wait for the proc to actually terminate. Once the proc has terminated, the very next time you call wait, it'll return 127, indicating the proc no longer exists.

The other thing that hung me up for a bit is that JBoss appears to ignore SIGINT (2), so i had to have the trap for that signal send a SIGTERM instead so that Ctrl-C'ing run.sh will stop the server.

The script supports relaying of the following signals:
 1) SIGHUP       
 2) SIGINT (i.e. Ctrl-C)
 3) SIGQUIT (i.e. Ctrl-\ on UNIX or Ctrl-Break on Windows, which triggers JVM thread dump)
 13) SIGPIPE   
 15) SIGTERM (i.e. defaut signal for kill command) 

Finally, I also modded to have run.sh exit with the same status the JBoss java proc exited w/, so run.sh's exit code will actually be useful.


> give run.sh the ability to run the VM in background and export the PID as an env. var.
> --------------------------------------------------------------------------------------
>
>                 Key: JBAS-3748
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3748
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: John Mazzitelli
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: patch-pidfile.txt, patch.txt, run.sh.patch
>
>
> 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.
> See attached patch for the change.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira