Subject: rc.subr problem with interpreted daemons
To: None <email@example.com>
From: Ed Ravin <firstname.lastname@example.org>
Date: 03/18/2002 23:34:30
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:
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.
We've just upgraded to Perl 5.6.1, and the Perl folks are now
using setproctitle() to change the program information seen by
"ps". But setproctitle() enforces keeping the old name, followed
by a colon, at the beginning of the command line. So ps reports
root 1758 0.0 0.1 604 340 01- S 31Jan02 0:25.18 perl5.6.1: myname myarg1 myarg2 (perl5.00502)
And check_process and check_pidfile in rc.subr are unable to tell that
our daemon is running.
I can think of several different ways to fix this problem:
1. change Perl 5.6.1 to use the older (and more complicated) code that
modified the command line arguments without using setproctitle().
2. change setproctitle() to allow the caller to specify that they
don't want to keep the old programname. According to the comments
in mg.c in Perl 5.6.1, FreeBSD does this when the caller prepends a
hyphen to the argument to setproctitle():
# if __FreeBSD_version >= 410001
/* The leading "-" removes the "perl: " prefix,
* but not the "(perl) suffix from the ps(1)
* output, because that's what ps(1) shows if the
* argv is modified. */
setproctitle("-%s", s, len + 1);
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:
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).