> Concerning the fork-parent.c and fork-parent.h revealed at
> http://welz.org.za/notes/fork-parent.tar.gz , I can't envision how
> you'd bind the fork-parent() function to the stuff your daemon actually
> does, in order to have your daemon properly fork and then terminate the
> parent when ready for business.
>
> I look at the code in fork-parent.c, and it looks to me like all the
> actual tasks of the daemon should be placed immediately above the
> child's closing p[1], so p[1] is closed when the daemon is ready. But
> in fact, fork-parent() has no interface to the real work of the daemon,
> as far as I can see.
So fork_parent() can be seen as a minor extension of the
daemon(3) library call: In both cases after you have called it
your function is now running in the child process. The parent
process stays "stuck" in the fork_parent() or daemon()
functions.
Note that there are "extra" close() calls in the fork_parent()
code, as after the fork() both ends of the pipe are visible
in both processes. Without closing the "other" end in each
process a read would not return EOF and the parent would stay
up even after the child has closed its end.
Here pseudocode, commented differently:
pipe() /* done in fork_parent */
if(fork() > 0){ /* in fork_parent */
close() /* in fork_parent, not the stderr of the child */
read() /* in fork_parent */
exit() /* in fork_parent */
/* parent no longer exists beyond this point */
/* this point in code, not in time */
}
/* here we are in the child, the parent is still running */
/* here do all the complicated setup routes, eg */
/* check databases, bind ports */
...
/* when everything is ready, you do: */
close(STDERR_FILENO);
/* at this point the parent exits (see above) */
/* and the rcS scripts know to start the dependencies */
It turns out that the same basic effect can be achieved with a
pause() and kill(getppid()), but that makes it tricky to relay
errors like "-x requires a parameter" to stderr, where usage
errors should be reported.
regards
marc