Subject: Re: rc.subr problem with interpreted daemons
To: Ed Ravin <eravin@panix.com>
From: Luke Mewburn <lukem@wasabisystems.com>
List: tech-userlevel
Date: 03/19/2002 18:31:26
On Mon, Mar 18, 2002 at 11:34:30PM -0500, Ed Ravin wrote:
| My shop has a few daemons that we run that are Perl scripts.
| When we moved to NetBSD 1.5 and ported our startup stuff to the
| rc.d system, we modified our Perl scripts to do something like:
|
| $0= "myname";
|
| Which changes the program's name as reported by "ps" to "myname".
| "ps" would see this:
|
| root 1758 0.0 0.1 604 340 01- S 22Jan02 0:45.10 myname myarg1 myarg2 (perl5.00502)
|
| And that would fool check_process and check_pidfile in rc.subr into
| properly detecting our running script.
|
| [...]
|
| I can think of several different ways to fix this problem:
|
| [...]
|
| 3. change /etc/rc.subr to support specifying what interpreter is
| running the daemon. I've implemented this and it adds ten or so
| lines to rc.subr. In the rc.d script for the daemon, I put:
|
| name=myname
| myname_interpreter=perl5.6.1
|
| and added a few lines to check_process and check_pidfile to test the
| ps output for both $myname_interpreter and $myname.
|
| Any comments on which of these solutions would be better long-term?
| Fixing setproctitle() is tempting, but there will still be daemons
| written in languages that don't let you change the command line
| arguments (/bin/sh comes to mind).
I'm looking at this problem at the moment. The intention is to
support "interpreters" for arbitrary rc.d commands, such that
check_process() and check_pidfile() do the right thing.
I've been considering the "cleanest" way to do this; we don't just
want to check the first arg (which might be "/bin/sh" or "javac"
or something), because there may be multiple scripts running.
We can't assume that the second arg will be the script name, as
scripts with
#!/path/to/interpreter -some-args -more-args
will confuse that. I've considered various methods to solve this, but
the more complicated (and general) a solution I consider, check_*()
will end up being significantly slower.
My current thoughts are along the lines of supporting two more
optional variables:
interpreter interpreter-name
command_shift # of args to shift to find the command
I'll try and get this working R.S.N.
Luke.
--
Luke Mewburn <lukem@wasabisystems.com> http://www.wasabisystems.com
Luke Mewburn <lukem@netbsd.org> http://www.netbsd.org
Wasabi Systems - NetBSD hackers for hire
NetBSD - the world's most portable UNIX-like operating system