On 12/06/2015 22:21, marcxdv@??? wrote:
> The trick is for the daemon process to only background when
> it is ready to service requests (ie its parent process exits
> when the child is ready).

You already mentioned it in a reply to me, indeed. I intentionally
did not follow up, and here is why.

This is bad design, for several reasons. It's actually worse design
than sd_notify(), and I'd rather have every daemon use sd_notify()
and write a sd_notify server myself than recommend your solution.

The reasons why it's bad are mostly described here:
http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/unix-daemon-design-mistakes-to-avoid.html

Your solution enforces forking, i.e. auto-backgrounding, and
prevents logging to stderr; in doing so, it prevents daemons from
ever being used with a supervision framework. systemd may be able
to supervise it, using cgroups, but that's about it, unless the
admin is using foreground hacks.
Moreover, the method you are using to transmit one bit of information,
i.e. readiness of the service, is *the death of a process*. This
is pretty heavy on the system; a simple write() does the job just
as well, and hundreds of times faster.

If auto-backgrounding was an absolute necessity, then sure, the
parent would need to die anyway, and you could time its death so
it transmits readiness. Why not. But auto-backgrounding is not good
design in the first place; it comes from ancient Unix times when we
did not know better, and the daemon() function should either
disappear into oblivion, or have a place in the museum of medieval
programming as an example of how not to write Unix software.

--
Laurent