Subject: Re: rc.subr problem with interpreted daemons
To: Ed Ravin <>
From: Luke Mewburn <>
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 Mewburn  <>
Luke Mewburn     <>
Wasabi Systems - NetBSD hackers for hire
NetBSD - the world's most portable UNIX-like operating system