> > I wonder why that general task of daemonizing cant just be done in a > > generic separate program and left out of the individual daemons. > > So, everybody can decide on this own how to actually start/manage > > the daemons - some use a supervisor, some just call via a daemonizer > > program from init scripts, etc, etc.
Only the program itself[*] knows when the transition between it being started and it being ready has happened. If the program daemonises itself, it can communicate this by having the parent exit at the correct point. [*]For a generic program to understand this, there would have to be some sort of convention (close stderr seems to be sanest I could think of). But no convention has been established yet and we have had some major boneheaded ideas (child processes stops itself when ready (WTF!?), write a magic sequence to stdout (fugly?)). Hiding this behind some library call makes it worse, as it ties things to a particular implementation. The daemontools advocates take the view that this notification when ready isn't strictly needed, as the dependent tasks should be smart enough to retry/persist. They have a point, but it can mask the actual source of failures and isn't workable for hard dependencies (fs not mounted). > > By the way: maybe we should write an RFC draft for the whole issue ... > > Looked for a relevant RFC. But found only this: > https://lists.ubuntu.com/archives/kernel-team/2008-December/003628.html > [RFC] [PATCH] notify init daemon when children are reparented to it > > But this doesn't seem to be quite what we want, and I can't say I have > enough context to understand it. It isn't what we want. Sadly some of the statements are outdated or something between misleading or incorrect. For example: *> *but* due to a quirk of POSIX, if it were to be made to open() a tty *> device, it would end up owning it! FAIL. POSIX anticipates this problem and provides a O_NOCTTY to the open call to prevent this problem happening. So NO FAIL. *> If there's two apache2 daemons running (in different chroots, or for *> different IPs or ports?), it [init] doesn't know which of the two died *> because the PID that died is unknown to it. This isn't the case. With a sigaction hander init can retrieve the pid and uid of the exited process. Also outdated because the kernel thesedays allows one to delegate the "default-child-collector" function of init to other processes - that is what the container infrastructure uses. > It seems to follow the practice of creating two processes for a > daemon, a parent and a child, and then orphaning the child. > This is not what we seem to be discussing here, and leads to > init having nontrivial ongoing work. Hmm... it is a bit of a tradeoff. This approach makes it possible to indicate readiness and thus order the system startup properly. It is also needed when random users need to daemonise their tasks (eg screen). On the other hand it makes automated respawning tricky. However it is an open question if well written daemons need to ever respawn. Respawning a crashed daemon favours availability over all other considerations. And uncontrolled respawn is a fork bomb, an oracle for an attacker, a log file filler, a database corruptor, etc, etc. > And although it says [RFC] in the title, it doesn't seem to be an > official RFC. Anybody can make a Request For Comments :-) (The RFCs of the IETF are different, they don't really relate to OS internals) Anyway here is my request for comments: If you want to signal that your daemon is ready close stderr, even if you don't do a fork(). Then the proposed generic wrapper can notice that. regards marc _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng