Le 13/06/2015 01:53, Laurent Bercot a écrit :
> 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.
>

     Thanks Laurent, I hope you explain it better than me. The point was 
already discussed on this list. It will take time before people are 
convinced because I think a lot of tutorials around still present 
auto-daemonization as the way to go.

     Didier