Should all services in rc.d support a status argument?

Hey there all,

I’m in the process of implementing a nagios check at the dayjob that basically ensures that all “enabled” services are running.  (Arguably, the answer to a service that fell over is *not* always to just quietly restart it).

However, not all services support the “status” command.

For example, /usr/local/etc/rc.d/dma_flushq is just a hook to flush the queue on boot — it doesn’t start a process with a long-running pidfile, and since there is no pidfile listes, there’s no useful output to the “status” command, and in fact, this yields an error:

# service dma_flushq status
/usr/local/etc/rc.d/dma_flushq: unknown directive 'status'.
Usage: /usr/local/etc/rc.d/dma_flushq [fast|force|one|quiet](start|stop|restart|rcvar|enable|disable|delete|enabled|describe|extracommands)
# echo $?
1

But if we take something like sshguard, then rc.subr is smart enough to look at the pidfile and figure out what I want, even though no special status command has been defined in /usr/local/etc/rc.d/sshguard:

# service sshguard status
sshguard is running as pid 814.

Now, I could go through each and every service in /usr/local/etc/rc.d, and parse the auto-generated “Usage:" to see what commands they offer…

# /usr/local/etc/rc.d/dma_flushq
Usage: /usr/local/etc/rc.d/dma_flushq [fast|force|one|quiet](start|stop|restart|rcvar|enable|disable|delete|enabled|describe|extracommands)

And use that to build a list of exceptions, but that’s annoying.

So here’s my fun question:  For scripts that don’t *have* a status defined, should rc.subr simply return 0 with a nicer message, because it’s not a statusable service?

The “practical rc.d scripting in FreeBSD” document mentions that “status” is a standard command, but is silent on this use-case.

-Dan

(Describe is also a valid command, but none of this stuff sets a description, even in the base OS.  I recall I took an action to make more of this stuff pass rclint).