On Sat, 15 Apr 2017 08:14:48 +0200
marc <marcxdv@???> wrote:

> > > Go on down your path, but I suspect not many people would cheer
> > > at you in this camp...
> >
> > I can see the merit - on two points, technical and political.
> >
> > > On the technical side, I can see the usefulness of a system
> > wide standardised service status reporting - making it easy
> > for one process to see if a service it depends on is actually
> > running and ready (as opposed to, "has started"). I have a
> > customer system I've inherited where it regularly fails to
> > startup properly because Asterisk starts before MySQL has
> > finished starting up.
>
> So it turns out that there exists an subtle yet elegant mechanism
> for a process to report that it is ready. It has been in use
> for decades - daemons as old as sysklog from the previous century
> use it.
>
> I have written up the details at
> http://welz.org.za/notes/on-starting-daemons.html

Danger Will Robinson!

If you write a daemon that backgrounds itself, whether early or late,
whether parent and child communicate via signals or pipes or, well,
what the heck, network sockets, be ABSOLUTELY sure to include a command
line option to tell your daemon NOT to background itself, but to stay
in the foreground all the time. If your daemon cannot stay in the
foreground, your daemon is incompatible with runit, s6, perp and
daemontools. And this foreground option should be separate from any
"debugging" options, because nobody wants production logs to have
debugging output.

>
> 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.

It's also not a good solution. It won't work unless:

1) ALL daemons act this way
2) All daemons accurately time parent destruction to full readiness
3) Nobody uses daemontools, runit, s6, perp, etc.

Once upon a time, daemon self-backgrounding was necessary, and this
fork-early, parent terminate on readiness was state of the art and the
Cadillac of the industry. But then, in 2001, daemontools was invented,
making self-backgrounding unnecessary. From 2001 on, a daemon author
could write a daemon as a normal foreground program, confident that
daemontools, or one of its descendents (runit, s6, perp,
daemontools-encore) would handle all aspects of getting it into the
background while still supervising it, without the need of a PID file.

Because daemontools, daemontools-encore, runit, s6 (and I would guess)
perp can run as mere process supervisors on any arbitrary init system,
the daemontools method of supervising foreground daemons is available
to anyone willing to install daemontools, and installing daemontools is
trivial.

Anyway, by far the most important thing I said in this email is this:
If you insist on making your daemon self-background, for gosh sakes
give it a command line option to stay in the foreground, and make that
command line option quite apart from any option that increases
debugging output.

SteveT

Steve Litt 
April 2017 featured book: Troubleshooting Techniques
     of the Successful Technologist
http://www.troubleshooters.com/techniques