[gentoo-dev] init script guidelines

[Eric Brown]

Services that use Gentoo init scripts often report a status of [started]
or
[OK] even though they fail to start.  The most recent bug like this that
I've
found is with snort.  If you have a bad rule, snort will initialize, the
rc-scripts will give it an [OK] status, and then it will die once it
parses the
rules.
 
The real problem is not that the daemons don't return errors, but that
our init
scripts do not make reasonable attempts to verify service startup.  If a
Gentoo
init script claims that a service started, it should make an effort to
check
that the processes are actually running shortly after the script is run,
even if
start-stop-daemon says the parent process initialized.  Relying on the
return
value of start-stop-daemon is simply insufficient for some services.
 
I am aware that there are services that can monitor the status of other
services
(app-admin/mon?) but I think this issue is a little different.  If an
ebuild
developer is aware of an error condition can commonly occur shortly
after a
daemon initializes, why not attempt to catch those errors?  Most of them
could
probably be caught by simply checking to see if the process is still
running
shortly after the script is run.
 
I propose increasing developer awareness of this problem, perhaps
through some
formal guidelines for ebuild developers.  At the very least, I would
like to see
these bugs being acknowledged in bugs.gentoo.org instead of getting the
same old
upstream/it's not our fault response.  We are responsible for our init
scripts,
and they are important to our users.
 
I have 2 ideas for the actual implementation:
 
1) Some kind of check() function in the init.d script, or a generic
check() function
that just checks with ps | grep.  This might typically be called after
having the
init script sleep for a certain amount of time.
 
2) Some kind of special init script that checks registered daemons after
all services
have started. (i.e. it depends on all daemons, or they are put into it's
config file).
With this scheme we could avoid excessive sleeping during startup (to
keep it fast),
And perhaps even keep using service specific check() functions
 
 
Does anyone else think this idea is worth looking into?