> 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
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Reply via email to