Bug#727708: Bits from linux.conf.au
Thorsten Glaser <tg@mirbsd.de> writes:
> Steven Chamberlain dixit:
>> Actually, even if they forked in the same order every time, they might
>> not be *ready* in the same order. That would be the rationale for
>> readiness protocols and other features of the more complex init
>> systems.
> Strong disagree. This actually is a bug in the initscripts in question
> that they return before the service is operational. Fixing this does not
> require exchanging PID 1 at all. In fact, there was some posting on
> Planet Debian where someone used
> #!/path/to/some-initscriptwriting-helper instead of shell for them.
If the daemon itself is ill-behaved, you generally have to do some
additional work to make this happen beyond just writing a better init
script. Well-behaved daemons will provide some synchronization point (not
exiting in the parent until the daemon is started and ready, ideally, but
this requires a pipe or some other method to coordinate, so more common is
to have the child not write out its PID file until it's ready). If they
don't, then it requires upstream patching, and can be tricky.
This doesn't change across the various init systems, although upstart and
systemd provide less tricky and racy ways of synchronizing than writing
PID files. That said, most of the race conditions involved in the PID
file approach are rare. Mostly you get into trouble if two copies of the
process are started at the same time, particularly if they're racing each
other to write the PID file.
Synchronizing on the PID file is my personal preference for old-style
daemons since it's so much easier to implement than controlling when the
parent process exits.
I *think* that start-stop-daemon properly implements PID-file-based
synchronization based on the description of the --pidfile option, but I'm
not positive and haven't checked the source.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: