On 12/06/2015 22:21, [email protected] 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 _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
