I want to start a java process using Upstart. Currently, on our OpenSuSE servers, I use the System V init system to achieve this, but on our Ubuntu servers I'd rather use Upstart. But I have two questions…
I have an Upstart job (a task) that configures the server, called, say, myconfig.
And in the job that starts my java processes I ostensibly have:
start on stopped myconfig
exec /path/to/myjavastartscript.sh
myjavastartscript.sh runs 'java -classpath blah MyClass'. In System V init, starting the service runs 'nohup /path/to/myjavastartscript.sh &'.
So my first question is whether I still need to do the nohup or run-in-background with the exec command?
When running, MyClass starts other Java processes. In System V init, the service stop just looks for java processes owned by a certain user and kills them. My second question is how could I control the termination of these processes with Upstart?
Best Answer
You do not need to use
nohup
since when Upstart runs a program, that process will not be associated with a terminal (by default).For Upstart, I'd suggest either just having the job call:
... or ensuring that /path/to/myjavastartscript.sh calls:
Note that the first
exec
above is an Upstart stanza whereas the 2nd is a shell keyword. If your shell script does not call the shell version ofexec
, you'll need to be careful to ensure you set the Upstartexpect
stanza correctly - see http://upstart.ubuntu.com/cookbook/#expect.Regarding stopping the service, Upstart will automatically kill the process it is tracking (the main JVM process associated with
MyClass
) and any children of that process (technically any process in the same process group (see http://upstart.ubuntu.com/cookbook/#stopping-a-job)).Without more details, I'm not sure your
start on
condition is suitable - presumably, you want the MyClass job start if and only if a configuration file has been setup? If so, the standard idiom is for the jobspre-start
stanza to read in/etc/default/MyClass.conf
. If it decides that either the file doesn't exist, or the config file somehow indicates that the service is disabled / not setup correctly, thepre-start
can simply callstop
to stop the job from (fully) starting (see http://upstart.ubuntu.com/cookbook/#pre-start). The advantage of this approach being that yourstart on
condition can then be reliably set to whatever set of conditions should cause the job to start. When those conditions are met, Upstart will run the job; the pre-start will run, determine the configuration is not yet valid and simply exit. The day the admin does decide to configure the service, the job will fully start.See http://upstart.ubuntu.com/cookbook/#determining-the-start-on-condition-ubuntu-specific and http://upstart.ubuntu.com/cookbook/#ubuntu-well-known-events-ubuntu-specific for determining the
start on
condition.Note finally that you should really always specify a
stop on
condition too. See http://upstart.ubuntu.com/cookbook/#stop-on.