Re: Library support for two-phase daemonization

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Tue, Jan 28, 2014 at 11:41:20PM +0200, Andreas Gustafsson wrote:
> Joerg Sonnenberger wrote:
> > I don't like the approach.
> 
> Could you please elaborate on what aspects of it you dislike, and why?

It is the wrong abstraction and doesn't really save much compared to
just doing the dance by hand.

> > I would to just extend the existing daemon
> > interface slightly.
> > 
> > (1) daemon2() returns a filter descriptor.
> 
> I assume you mean a file descriptor.

Yeah, typo.

> > It is the responsibility of
> > the child to write '\0' to this fd and close it, once it is done with
> > initialisation.
> 
> Do you mean calling write() and close() directly rather than using a
> library function specific to the task?  IMO, having a library function
> hiding the implementation details of the file descriptor is cleaner.

Providing a function is fine, but it is an important implementation
detail. I don't think hiding it is a good idea -- it would break with
closefrom(2) for example.

> Would your daemon2() function also include the parts of daemon() that
> (optinally) do chdir("/") and close stdin/stdout/stderr?  I think you
> would usually want to do those after setting up sockets and such, not
> before, so that you can read configuration files using relative paths,
> and report any errors that occur during the setup via stderr.

Most daemons that want to deal with that are already set up to do those
steps seperatedly and early. chdir(2) is only really useful in
combination with chroot(2) and the later requires enough care by itself.

> > (2) If the child writes a code other than '\0', it is interpreted as
> > error by the parent and used as exit status.
> >
> > (3) A new argument provides the default exit code in case the child
> > terminates before writing the status byte.
> 
> Are there actually any daemons that distinguish between different
> kinds of failures to start by means of the exit status?  If there is a
> genuine need for that functionality, I will be happy to add another
> library function to support it, say daemon2_fail(int exit_status),
> but I don't think it should be done by calling write() directly.

If you want to communicate more than "something failed", the exit status
is certainly most helpful. As mentioned above, providing a function for
this purpose is fine.

> > Note that the existing daemon functionality can be obtained by just
> > closing the descriptor returned by daemon2.
> 
> After passing 0 as your proposed default exit code argument, right?

Yes.

Joerg