tech-userlevel archive

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

Re: Library support for two-phase daemonization



On Sunday, at 12:40, Andreas Gustafsson wrote:
| Anthony Mallet wrote:
| > 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).
| > 
| > So the pipe() approach does not really fit in my case. Or at least I don't 
see
| > an easy way to communicate a file descriptor the child.
| 
| Is this just meant as background to explain why your code example is
| structured the way it is, or are you suggesting that NetBSD should
| have library support for this pattern in addition to the traditional
| daemonization pattern?

Yes, I was suggesting this pattern as an alternative implementation of your
daemon_{fork,detach} with pipe(). 

Your suggestion solves one problem (the first use case above), and since you
are planning to add this to libc, it may be worth trying to solve the other use
case at the same time?

The API could be something like:
 - daemon_fork()
 - daemon_detach()

 - daemon_spawn(): basically a posix_spawn() with the additional signal
 notification pattern.

daemon_spawn() could of course only be used with programs using the
daemon_{fork,detach} API, which is maybe an argument against my proposal.


Home | Main Index | Thread Index | Old Index