Roy Marples wrote:

>On Tue, 2005-07-19 at 12:42 -0400, Eric Brown wrote:
>
>
>  
>
>>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 agree.
>
>Infact, rc-services.sh (/lib/rcscripts/sh) has been totally re-written
>for the baselayout-1.12.x branch. It now intercepts calls to
>start-stop-daemon and checks if the daemon is still active after a
>default time of 0.1 (adjustable) seconds. If not, the we assume the
>daemon failed. This solves many existing bugs :)
>
>Also, we kill any rogue processes and other such checks when a stop call
>to start-stop-daemon is made - which is handy for when asterisk fails to
>start and leaves mpg123 processes lying around :)
>
>Check it out when baselayout-1.12.0pre1 hits portage!
>
>Caveat: - some init scripts abuse start-stop-daemon. One example are all
>courier scripts which pass the env program as a daemon. This is easily
>worked around, but we fail badly if env then calls a shell script which
>in turn launches a daemon. Of all the server stuff I run, only couier
>has this issue - but there may be other programs too. Basically
>start-stop-daemon should only call daemons!
>
>http://bugs.gentoo.org/show_bug.cgi?id=98745
>
>Roy
>  
>

what about to define two additional functions

check_startup() and check_shutdown()

intended to be filled from package mantainer.
The rc scripts can call these one to check if a service is
started/stopped or not.
If not it wait and retry untill a timeout is reached.

This open the road also to centralized policies of waits between check
like :
(1,1,1,1,1,1) (1,2,3,4,5,6) (1,2,4,8,16,32) and other nice stuff.

Francesco
-- 
[email protected] mailing list

Reply via email to