Re: [gentoo-dev] init script guidelines

[Chris Gianelloni]

On Tue, 2005-07-19 at 12:42 -0400, Eric Brown wrote:
> 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.

So snort shouldn't be giving the OK until it really is OK.
>
> 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.

Not really.  An init script is simply a script.  It doesn't guarantee
anything other than what the service told it.  If a service is returning
status codes when it really isn't completed its initialization, that is
a bug in that service, not in the init script code.  While code might
need to be adjusted in the init script, this will most likely require
patches to the upstream sources.
>
> 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 agree with you that we should catch the errors, but running another
check is simply a waste of time.  The service should not ever show a
completed state until it is completed.  It shouldn't ever be like "Yes,
snort worked.......... oh wait, no it didn't."  That is even more
confusing for users.

> 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.

You really need to take this up with the developers in question, as this
is not a global matter, but really a matter with specific packages.
Those are bugs in those packages.  If the ebuild maintainers are
refusing to resolve issues in the init scripts, which are definitely
Gentoo works, please take it up with user relations or attempt to
provide a fix for the problem.
>
> 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.

I would object to this.  Having a function to check the status of a
service for all of the possible services, when it is only a few that are
showing this error, is a bad idea.  It adds extra load on all developers
that have any init scripts, and is unnecessary in most cases.
>
> 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

This would require much more knowledge on the end-user's part.  Plus, it
will need to be aware of init script dependencies.  All in all, it
sounds like a bad patch for a situation.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux