/etc/init.d/* status .. what to do when transitioning to an upstart job?

[Clint Byrum]

So during our discussion of upstart server enhancements at UDS-Natty[1],
one point of contention was whether the 'status' argument to init.d
scripts is important, and if so, where to put it.

For init scripts, LSB states:

        The start, stop, restart, force-reload, and status actions shall
        be supported by all init scripts; the reload and the try-restart
        actions are optional. Other init-script actions may be defined
        by the init script.[2]
        
It goes on to define the return codes, and how these are to be printed.

Because of this fact, most init scripts that are written, have some kind
of status stanza.

Many of them are just checking to see that the daemon is running. This
is a passive check, and the transition to upstart maps well to this,
with upstart's status command printing a parse-able "start/running" or
"stop/waiting", and reserving the return code for whether or not it was
able to query the status of the job.

However, others are more active checks, that interrogate the service to
make sure it is running. This code is very useful, but its not clear
where it should go after one transitions to using an upstart job.

One thought is that many times, it is a good idea to put this in the
post-start stanza. Interrogating the service for an actual ready state
will prevent race conditions where a job's 'started' event may be fired
before the service is actually ready to work.

However, if the code is in post-start, it cannot be called by users
wishing to interrogate the service.

One thought that Dustin Kirkland had was to ehnance the 'service'
command to look in a directory for shell snippets, something like

/etc/service/status.d

And if one exists for the job name, run it, otherwise just run the
upstart status and provide an LSB compatible return code.

This would also allow for the post-start stanza to call the same code if
it is needed.

Does anyone have strong thoughts on this? Given the service.d approach,
it would seem the correct course of action is to open a feature request
against sysvinit, document it in our upstart job writing best practices,
and to document this feature in the server guide.

--

1. https://blueprints.launchpad.net/ubuntu/+spec/packageselection-server-n-upstart-server-enhancement
2. http://refspecs.freestandards.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html