From: Tanaka Akira <akr@...17n.org>
Date: 2004-09-05T01:17:31+09:00
Subject: Re: ruby-dev summary 24054-24170

In article <1094170220.054512.4934.nullmailer@picachu.netlab.jp>,
  Yukihiro Matsumoto <matz@ruby-lang.org> writes:

> Processes will be zombies (half dead process during process
> termination) until their parents call wait(2) for them.  A daemon is a
> long living process, and should be detached from parent processes.  So
> here's the trick.  When parent processes die, child processes will be
> adopted to init (pid=1) which calls wait(2) for its adopted children,
> so that they will no longer become zombies.  Double fork is worked
> this way.

There is another reason for a fork after setsid: prevent unexpected
acquiring of a controling terminal.
[ruby-talk:87467], [ruby-talk:87500]

However the unexpected acquiring doesn't occur under 4.4BSD kernel
because open(2) doesn't acquire a controling terminal.  But Linux
does.

I'm not sure that glibc's daemon(3) implementation is proper.

Note that uClibc's daemon(3) does fork after setsid.

> In open3, double forks are 1) first fork just to die to pass its child
> to init, 2) second fork that eventually exec the command. 

The second fork is not required to avoid zombies.

> So if I understand you correctly, yours have triple forks instead of
> two.  One extra fork harms little.  Very small cost for an extra
> process creation.

Yes.  It is very small cost.
-- 
Tanaka Akira