Sending shutdown signal to JVM

[manish]

Hi, I'm writing a java daemon process. Starting the process up is fine,
(e.g. java -server Main args). However in order to shutdown the process
I have to manually kill the process (e.g. kill pid). However, if there
are many java server processes running on the box it is easy to kill
the wrong process. There must be a better way to do this, here are some
of the options I can think of:

1) Put the process id in a file.
2) Change the server process so that it listens on a port for a
shutdown command.
3) Change the server process so that it polls a directory for a file
containing the shutdown command.
4) Change the server process so that it registers to an rmiregistry and
can have shutdown called on it.

Does anyone have any other ideas? - I'm just trying to find the
cleanest and simplest method of shutting down the server that has the
minimal impact on the code and ensure that the correct jvm is shutdown.
(Pls note that I'm aware of the Runtime.addShutdownHook method)
thanks.

 

[Kai Schwebke]

Hi, I'm writing a java daemon process. Starting the process up is fine,

....

Hava a look at jsvc -- it's the wrapper also used by tomcat
(http://jakarta.apache.org/commons/daemon/jsvc.html).

It provides a complete framework for java daemons including changing
user id after init.


Kai

 

[Martin Gregorie]

Hi, I'm writing a java daemon process. Starting the process up is fine,
(e.g. java -server Main args). However in order to shutdown the process
I have to manually kill the process (e.g. kill pid). However, if there
are many java server processes running on the box it is easy to kill
the wrong process. There must be a better way to do this, here are some
of the options I can think of:
....
> 1) Put the process id in a file.
>

This is useful if you're running in a Linux/UNIX environment that uses
scripts in /etc/rc.d/init.d to control permanent servers, i.e. the
method used by RedHat and others. By doing this you get to use the
"chkconfig" command to control server startup order and the run levels
it runs in. You also get to use the "service" command to start, stop,
restart and inquire on the status of the server. This approach will keep
a simple server simple because all the control functions can be handled
via a straight forward shell script, but it isn't a portable solution.

2) Change the server process so that it listens on a port for a
shutdown command.
>

This works well for servers in any language. If the server is already
using sockets it probably has little effect on its overall logical
structure. I find that the command interface is also a good way of
checking status, controlling operation, e.g. turning diagnostics on and
off for a running process. I usually write a simple client that provides
a command line interface to send commands and interpret and display the
responses and can be included in scripts.

Possibly its biggest benefit is that it makes controlling the server
independent of the OS, which can be a big help to portability, and also
adds the possibility controlling it remotely at no additional cost.

3) Change the server process so that it polls a directory for a file
containing the shutdown command.
>

That sounds rather like adding a wart to the server. Reading the file
frequently enough to get a fairly instant response quite probably adds a
performance overhead.

4) Change the server process so that it registers to an rmiregistry and
can have shutdown called on it.

No comment: never tried it.

Does anyone have any other ideas?
>

Your option (2) could add a lot of flexibility, such as letting a
scheduler to issue commands via the control client. If the server
accepts "deactivate" and "activate" commands then a backup script could
use the client to pause the server while an associated database is
backed up.

 

[manish]

thanks for the very useful feedback!