init script behaviour

[Joe Orton]

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

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

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?

Regards, Joe