tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Library support for two-phase daemonization

Christos Zoulas wrote:
> In article <>,
> Andreas Gustafsson  <> 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 choosed this approach so that the program can be used according two 
| > 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 
| > 
| >  - start from another unrelated "launcher" program. The launcher must of 
| >    implement the 'SIGUSR1' logic. In this mode, the child does not fork 
| >    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


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

> 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.
Andreas Gustafsson,

Home | Main Index | Thread Index | Old Index