:: Re: [DNG] tiny service state api [W…
Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: marc
Ημερομηνία:  
Προς: dng
Αντικείμενο: Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
> 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