On Sun, 14 Jun 2015 18:17:44 +0100
KatolaZ <katolaz@???> wrote:

> On Sun, Jun 14, 2015 at 03:50:06PM +0200, Laurent Bercot wrote:
> > On 14/06/2015 15:29, Nikolaus Klepp wrote:
> > >And I thought the historic solution would be to give your web
> > >printing service an id higher than cups, eg.:
> > >
> > >/etc/rc*/S04cups
> > >/etc/rc*/S99awsomewebprinter
> > >
> > >Together with the nightmare from unix museum (aka fork when ready)
> > >it simply works.
> >
> > No, it doesn't.
> > The S04cups script will start cups, spawn the process, but exit
> > before the service is ready; your sysv-rc mechanism will only see
> > S04cups die, think it's okay, and start S99awsomewebprinter. There
> > is a race condition and the web printing service may be started too
> > early. Unless cups implements readiness notification, and S04cups
> > waits for this notification before returning. Then
> > S99awsomewebprinter will only be started once the cups service is
> > *actually* running.
> >
> > It's not a theoretical problem. It's a very real one. Some daemons
> > take ages to get ready after they've been started, their needed
> > prep work is longer than it takes for a shell script to exit and
> > another one to be spawned, and the race condition is real.
>
>
> I am sorry but you simply don't get rid of race conditions by
> signalling that the daemon is ready. If the daemon dies or hangs for
> whatever reason, you will still have a problem, since you thought the
> service was up and running while it is not any more....

I don't think we'll ever get rid of *all* race conditions. What daemon
readiness notifications do is get rid of a big source of race
conditions: Startup. Of course, the process manager must be equipped to
handle the readiness notifications.

Other race conditions are handled by readiness tests with ping and the
like. And some race conditions are too rare and too harmless and too
expensive to handle.

SteveT

Steve Litt
June 2015 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key