init script behaviour

Manuel Wolfshant wolfy at
Tue Jun 15 12:30:05 UTC 2010

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

More information about the devel mailing list