Bug #2712


Wait for grandchild to be ready when daemonizing

Added by pasdVn over 8 years ago. Updated about 8 years ago.

Target version:


When lighttpd does the sys-v-init daemonizing (without the -D switch) the parent process will immeadeatly terminate after the first fork (see function daemonize in server.c).
This can cause problems, when right after the start of lighttpd the presence/correctness of the pid is checked or the pid of the daemon process is tried to grabbed by `pidof lighttpd` or similar. The second problem becomes a problem because of the double forking. If the timing "fits" you get only the pid of the child but not the grandchild (or both).

Following this guide ( it is a more clean way to terminated the parent process only if the child is fully up and running (after every initialization is ok and the pid file is written).

I wrote a patch that fixes this behaviour. As suggested in the reference above it uses a pipe as communication channel between parent and grandchild.


Actions #1

Updated by gstrauss over 8 years ago

The child should


before returning from daemonize(), or else that fd leaks in the child.

Actions #2

Updated by gstrauss over 8 years ago

Additionally, when there are multiple workers, the first worker (greatgrandchild) calls write(), and then the grandparent calls read() and close(). Once you fix the pipefd[0] leak in the grandchild (which I mentioned in the comment above), then subsequent workers might fail to write() with EPIPE after the grandparent calls close() on the read-end of the pipe (pipefd[0]).

Please consider moving the write() to a location prior to spawning of workers, but after the daemonized grandchild is up and running, and after the grandchild has written its pid to the pidfile. Such a location would be a reasonable place for the grandparent to exit while still ensuring that pidof would return the proper pid of the running grandchild.

Actions #3

Updated by pasdVn over 8 years ago

Thanks for your feedback. I moved the grandchild's write() directly before the fork-loop where the workers are created. I think this is the best place under this circumstances.

Actions #4

Updated by gstrauss over 8 years ago

Thanks for the update. This second patch looks better to me.

@stbuehler: what do you think?

Actions #5

Updated by stbuehler over 8 years ago

  • Target version set to 1.4.40
Actions #6

Updated by gstrauss over 8 years ago

Prepared patch with credit to pasdVn:

Actions #7

Updated by stbuehler about 8 years ago

  • Status changed from Patch Pending to Fixed
  • % Done changed from 0 to 100

Applied in changeset r3127.


Also available in: Atom