Re: Library support for two-phase daemonization

[christos%zoulas.com@localhost (Christos Zoulas)]

On Feb 3, 10:07am, gson%gson.org@localhost (Andreas Gustafsson) wrote:
-- Subject: Re: Library support for two-phase daemonization

| Christos Zoulas wrote:
| > In article <21230.27019.763030.648476%guava.gson.org@localhost>,
| > Andreas Gustafsson  <gson%gson.org@localhost> wrote:
| > >I'm afraid I still don't see why this is needed.  Is there currently
| > >code in NetBSD using this pattern?  What advantages does it offer over
| > >traditional daemonization?
| > 
| > This pattern is necessary for any threaded deamon and has been open-coded
| > in all such daemons (see dhclient, named, etc.)
| 
| Are we talking about the same pattern?  I was referring to the latter
| of Anthony's two use cases:

I was talking about the file descriptor write.

| | > I choosed this approach so that the program can be used according two 
distinct
| | > use cases:
| | >  - classic standalone mode, start within a shell script: daemonize with a
| | >    command line switch and return to the shell only once the program is 
ready.
| | > 
| | >  - start from another unrelated "launcher" program. The launcher must of 
course
| | >    implement the 'SIGUSR1' logic. In this mode, the child does not fork 
itself,
| | >    but it is still able to inform it's parent about it 'ready' state. 
(think
| | >    for instance about inetd, although it's not inetd in my use case).
| 
| That latter pattern is not used in dhclient nor named.
| 
| > file descriptors are better than signals because they can pass state (where
| > that is needed) and offer better control semantics
| 
| Agreed.

Good :-)

| > (like a parent that
| > can spawn many children that waits until all of them have been initialized
| > before it exits).
| 
| Yes, pipes are better for that, too, but I don't think that case is common
| enough to warrant library support.

It is a generalization of the single child case.

| > This is one more reason to pass the file descriptor back to the
| > parent like joerg suggested.
| 
| I don't see any such proposal from Joerg - he proposed returning the
| file descriptor from deaemon2(), which amounts to passing it to the
| child, not the parent.

I think the easiest pattern is to fork early, do all the work in the child,
then have the parent exit once it is notified that the child is done.

christos