init script behaviour

[Manuel Wolfshant]

On 06/15/2010 03:08 PM, Joe Orton wrote:
> Any opinions on this?  I've had a query.
>
> What should "service xxxx start" do for a daemon - or more specifically,
> when should it return?  There is inconsistency amongst different current
> init scripts, two general approaches:
>
> 1) fire and forget: start the daemon, return immediately
>    
which might give "false positives" as in "service started (I've seen the 
OK on screen!) but not running

> 2) stop and wait: start the daemon, and wait, either:
>   a) a short fixed period of time, or
>   b) in a loop until the pidfile appears, with some maximum wait time
>    
which might give "false positives" as in "service started (also known as 
"pidfile exists but the process is dead") but not running"

> Notable implication of (1) is that running e.g. "service xxx status" (or
> stop etc) may not immediately succeed after a "start", nor may the
> service be immediately usable directly after a "start" returns.
>
> (2b) may have surprising failure cases of an init script waiting a long
> time to return - dirsrv will wait up to ten minutes, which seems rather
> extreme.
>
> (2a) may be unreliable, being dependant on timing/machine speed
>
> I found at least one init scripts which also has this stop-and-wait
> behaviour for "stop" (mysqld).
>
> I'd instinctively prefer (1) from a "do one thing and do it well"
> perspective; (2) starts down the road of a better/more complex form of
> service-monitoring/management and ends up doing it really badly in messy
> sh script in N places.
>
> (A logical extension of (2) would be to require not merely that the
> pidfile exists, but that the service is accepting connections on TCP
> port N, before returning from the init script "start" invocation)
>
> Thoughts?
Well, I'd say it depends on how we define the "start" part. "fire and 
forget",  "start and make sure it was started" or "start and make sure 
it is running".