init script behaviour
jorton at redhat.com
Tue Jun 15 12:08:54 UTC 2010
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
(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)
More information about the devel