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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng