Hello again Steve

> > The TLDR is that "A good daemon should fork soon, but have the
> > parent process exit only once the child is ready to service requests"
> >
> > Sadly it seems too subtle for many people and the concept goes
> > un-noticed ...
>
> It's as subtle as a 10 megaton nuclear device, and goes un-noticed
> because most of us who know of it hope it will be forgotten, so we
> don't speak of it.
>
> Read http://welz.org.za/notes/on-starting-daemons.html. According to
> this document, quite apart from the daemon's real function, the daemon
> must fork itself early, form a pipeline between parent and child, and
> when the child believes it's ready to function completely, it sends a
> message to the parent, who upon receipt of the message exits. That's
> not subtle: It's quite baroque. Your idea of canning it into a neat
> little tool is quite elegant, but it's an elegant implementation of
> something baroque.

Baroque, 10 megaton nuclear device, eh ? It is (error checking/reporting
elided) an effort of 6 system calls:

  pipe()
  if(fork() > 0){ /* if we are in parent */
    close()       /* close the child end of the pipe */
    read()        /* wait for child */
    exit()        /* exit the parent process */
  }
  ...             /* do whatever is need to bring up the daemon */
  close()/dup2()  /* no message required, Steve misunderstood that */

If these system calls make you hide in a nuclear fallout shelter
with your powdered white wig, one worries what will happen if somebody
tells you what gethostbyname() does.

Or even worse have you straced python recently ? It does 800+ system
calls before it even gets going ... and it only goes downhill from
there.

I appreciate that Steve likes the daemontools approach where the
server process stays in the foreground, and I have no quarrel with
the advice of including a -f foreground option... The daemontools
approach makes a completely different set of tradeoffs - some
people really like them, others consider them to be the lunatic
fringe. To each their own.

But for a classic sysvinit startup path, the above logic
will do a decent job of signalling that a process is ready to
serve requests. And has been an appropriate mechanism for
decades. No need for yet another API.

regards

marc