tech-userlevel archive

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

Re: Library support for two-phase daemonization



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?

> However, I think the race that you mention can be fixed by moving the
> sigprocmask() and related code before the fork(), and restoring the former 
> mask
> in the child. What do you think of the following?

Looks correct to me, but signal semantics are not really my speciality.
-- 
Andreas Gustafsson, gson%gson.org@localhost


Home | Main Index | Thread Index | Old Index