First, Matt Green wrote:

>   Yes.  The actions should be supported by all scripts.  They may do
>   nothing or they may do something.  At least that way when you want
>   to do something like "for i in /etc/init.d/*; do $i querylog; done"
>   you don't get a bunch of crap from scripts which don't support that
>   particular switch.  I think things like the cachefs.daemon script
>   on Solaris7 are bad examples (that particular script has been written
>   in such a way that it does start but not stop).  The S99dtlogin is
>   another bad example because it supports a bunch of switches which
>   are otherwise unused elsewhere (reset/update_printers/get_server_pid).
>   There should be some semblance of orthogonal design across all the
>   scripts.
> 
> this is ludicrous!  these scripts are modular *individual* beings.
> if you attempt to force a defined set of `operations' on them, you
> will cripple them.  it does not allow for expansion.  personally,
> if i call a script with an unsupported argument, i *want* it to fail
> for me!

What about a rc.conf option that allows silent failures for unsupported
arguments?  Obviously not all 3rd party rc scripts would know about this
(and we can "fix" this with pkgsrc), but it would seem to keep both
camps happy.

Then Nathan Williams wrote:

> Luke Mewburn <lukem@cs.rmit.edu.au> writes:
> 
> > a) Extra functions in /etc/rc.subr
> 
> > 	check_process procname
> > 		Ensures that a process (or processes) named procname
> > 		is running. Prints a list of matching pids.
> 
> This is nigh-impossible to get totally right. It should probably deal
> with paged-out processes that show up as (process), and the
> documentation should mention problems with setproctitle()-happy
> daemons (sendmail, for example) and user-named processes unrelated to
> the actual service (it'd be an annoying DoS attack if I could just run
> some programs that happened to be named "portmap" and "mountd" that
> kept the sysadmin from restarting those). 
> 
> Checking the uid might be a win here. 

Note: I haven't looked at the examples, just followed the discussion.
It seems that you may be able to:

	check for /var/run/<process>.pid
	else check for ps -c if <process> < MAXCOMLEN chars long
	else check for ps

This should be relatively resiliant to setproctitle() changers as I'd
say most process names are less than MAXCOMLEN characters long - on a
smattering of different boxes here "rpc.frameusersd" is the longest at
exactly MAXCOMLEN...

Simon.