Date: Mon, 15 Dec 2003 23:08:07 +1030 (CST) From: David Bullock <db@dawnbreaks.net> To: Ernst de Haan <ernst.dehaan@nl.wanadoo.com> Cc: freebsd-java@FreeBSD.org Subject: Re: Debugging options for tomcat41ctl Message-ID: <20031215222744.H83388-100000@arwen.lorien.dawnbreaks.net> In-Reply-To: <200312151149.22912.ernst.dehaan@nl.wanadoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031215222744.H83388-100000>