Debugging options for tomcat41ctl

[David Bullock]

On Mon, 15 Dec 2003, Ernst de Haan wrote:

> No. If we start using something other than daemonctl, then that's perfectly
> fine, but then we must keep the functionality we provide at this very
> moment. Perhaps we could have just a single wrapper C program that will set
> the UID and/or GID and then executes a script with the specified arguments.
>
> I don't have time to go really into this, but I'm really supporting all
> efforts to improve this feature.

Have you looked at Dan Bernstein's daemontools?

 http://cr.yp.to/daemontools.html
 /usr/ports/sysutils/daemontools

It has at least that setuid 'wrapper' you speak of, and well,
it's just elegant.  The 'supervise' program is kicked off from
/etc/rc.local, and functions like init.d for the deamons it
manages.  Unlike init.d, if the daemon stops, it restarts it.

The generic 'deamonctl' communicates with the 'supervise' process
... actually, it's called 'svc'.

  svc -u /path/to/management/dir    starts the process using a 'run' script
  svc -d /path/to/management/dir    stops with TERM
  svc -t /path/to/management/dir    stops then starts
  svc -h /path/to/management/dir    sends HUP
  svc -a /path/to/management/dir    sends ALRM

Utilities svok and svstat give status information.

In the 'run' script to start the process, instead of littering
the script with environment variable assignments, environment
variables are acquired by scanning a directory.  Files in the
directory are named according to the name of the variable, and
the value of the variable is acquired from the file.

So to start Jetty, for example, I have

  /service/                       directory
  /service/jetty/                 direcotry
  /service/jetty/env/             directory
  /service/jetty/env/JAVA_HOME    env var
  /service/jetty/env/JETTY_HOME   env var
  /service/jetty/env/PORT         env var
  /service/jetty/run              script
  /service/jetty/jetty            script

(the use of /service is recommended, but not required)

The contents of the run script is like:

  #!/bin/sh
  exec envdir ./env ./jetty

(the 'envdir' command runs ./jetty using environment variables from ./env)

./jetty in turn looks like:

  #!/bin/sh
  cd $JETTY_HOME
  exec setuidgid jettyd $JAVA_HOME/bin/java -jar start.jar etc/jettyplus.xml

The setuidgid runs the JVM with UID and GID for jettyd.
Deamontools takes care of backgrounding the process.  It also
has some groovy logging facilities.

This certainly works for me for running Jetty.  It even has
the nice side-effect that if a terminate the JVM when disconnecting
from a remote debussing session, it restarts the JVM for me ;-)

Of course, the HUP and ALRM are not of much semantic use to a
Java program, but TERM works just fine as a kill signal.

Anyways, might save some reinvention of the wheel, and it's just
plain cool, so I jumped at the chance to talk about it :-)
It er, doesn't quite solve any access-control issues for not
root users, but if there were to be a generic 'daemonctl' for
the numerous Java deamons out there, this codebase is worth
mining for ideas, at the very least.

cheers,
David.