> On 12/06/2015 22:21, marc...@welz.org.za 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
It is only bad design if you have your heart set on a supervision framework like daemontools. Such frameworks have been around for decades too, and have not caught on (also for several reasons ;) The above link even lists all these attempts, and so presumably has the agenda of trying to make these frameworks happen The biggest reason is that in a number of applications it is unclear if and when things should turn in to a daemon. Consider something like screen - things only background when you press <control-A d>. In general terms having a supervision framework means that a daemon is something an administrator decides to create, not something which the user asks his application to become. This has at least four undesirable side-effects: * It becomes harder for end users to run their own daemons. Harder, less convenient, whatever. Not impossible - with enough contortions anything is possible. But it disempowers non-admin users. * Daemon programmers get to become lazy - where previously a crash was something horrible, a crash now means that the supervision framework restarts it, so no biggie. Welcome to windows, where software is expected to crash * People are lulled into the false sense of security: "My supervision framework thinks the process is still up, so things are ok". But your process has has been running in an infinite loop for the last couple of days. If you want to have monitoring, monitor your task at the service it provides (retrieve a web page from a web server, finger the finger daemon). Inevitably that requires domain knowledge, which supervision framework advocates struggle to realise. Or if you are Lennart, you end up absorbing all domains into your supervision framework, at which point we have to fork a distribution * Supervison frameworks are marketed as "So easy to use, any idiot can write a daemon". And assume it to be true and every idiot writes a daemon. People who don't know what an attack surface is, how a protection domain gets synthesised, etc. And typically in languages which assume infinite RAM and CPU time, cause if they run out, they just hit the wall... > 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. Closing stderr to the parent does not prevent logging to stderr, you can quite happily close a file descriptor with dup2(). Or you could use some other logging framework, but that would then conflict with the supervision framework. Framework collisions On a personal note: You have been making a number of pronouncements which suggest incomplete understanding of unix: Here unaware of dup2(), but in previous posts you were unclear on when a shell needs to do a stat() (5542b2d4.5030...@skarnet.org), misunderstood security through obscurity (55449253....@skarnet.org), do not realise that a setgid exectuable which isn't world executable is almost useless (5545e741.5000...@skarnet.org) So in general this ok, everybody starts off new, nobody is perfect, etc. But surely it is worth understanding something before wanting to redesign it wholesale (5542603e.8000...@skarnet.org, and now here with daemon startup). Especially in a forum (devuan) which appears to have been forked in response to such a poorly conceived redesign. Consider your closing statement here: > 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. This paragraph does not convey anything useful, and the tone comes across as arrogant - consider carefully whom label as not knowing how to write Unix software, cause you might fit that description rather well, like all of us regards marc _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
