Re: Library support for two-phase daemonization

[Andreas Gustafsson <gson%NetBSD.org@localhost>]

Joerg Sonnenberger wrote:
> I don't like the approach.

Could you please elaborate on what aspects of it you dislike, and why?

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

I assume you mean a file descriptor.

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

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.

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

> Whether a timeout should be provided as fourth argument is a question I
> can't answer right now.

I don't see a need for one.

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

In my proposal, the existing daemon() functionality can be obtained by
calling daemon2_detach() immediately after calling daemon2_fork().
I don't think either approach has an advantage over the other in that
regard.
-- 
Andreas Gustafsson, gson%NetBSD.org@localhost