misc/96766: run_rc_command doesn't work for Python scripts

[Richard Brooksby]

>Number:         96766
>Category:       misc
>Synopsis:       run_rc_command doesn't work for Python scripts
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu May 04 11:50:16 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator:     Richard Brooksby
>Release:        6.0-RELEASE-p6
>Organization:
Ravenbrook Limited <http://www.ravenbrook.com/>
>Environment:
FreeBSD raven.ravenbrook.com 6.0-RELEASE-p6 FreeBSD 6.0-RELEASE-p6 #0: Tue Apr 11 13:52:12 BST 2006     root at coot.verity-networks.com:/usr/obj/usr/src/sys/GENERIC  i386
>Description:
The run_rc_command from /etc/rc.subr is intended to lift out the repetetive parts of starting and stopping system daemons.  However, it fails to work on Python scripted daemons which start with the usual #! line:

  #!/usr/bin/env python

Although it will start a daemon, it can't stop, restart, or report its status.  This gives failures like:

  raven# sh /usr/local/etc/rc.d/py-spamass-milter.sh status
  py_spamass_milter is not running.

even though

  raven# ps -p `cat /var/run/spamd/py-spamass-milter.pid`
    PID  TT  STAT      TIME COMMAND
  75992  ??  Ss     1:55.69 python /usr/local/sbin/py-spamass-milter -p /var/run/spamd/py-spamass-milter.sock

Setting the "interpreter" variable before calling run_rc_command doesn't help.  I think the run_rc_command function might be assuming that the interpreter will appear immediately after the #! in the script itself.  This won't just affect Python: there are other systems which use "env" in the same way.
>How-To-Repeat:
Create a simple daemon in a Python executable script, and a corresponding file in /usr/local/etc/rc.d, then try to stop or restart the daemon.
>Fix:
The rc_command function does a lot of work to make sure it's not going to kill the wrong process, but its assumptions about what will come out of "ps" are wrong, and probably too paranoid?  Perhaps a simpler check would be fine.
>Release-Note:
>Audit-Trail:
>Unformatted: