> > 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