From: Gary Wright <gwtmp01@...>
Date: 2009-04-25T13:05:30+09:00
Subject: [ruby-core:23310] Re: [Bug #1403] Process.daemon should do a double fork to avoid problems with controlling terminals


On Apr 24, 2009, at 9:10 PM, Nobuyoshi Nakada wrote:
>> setsid is not sufficient.  That makes the child process a session
>> leader, establishes a new process group, and breaks the association
>> with the controlling terminal, but it doesn't prevent the process  
>> from
>> acquiring a controlling terminal if it should happen to open a tty
>> device (generally on system V based systems, BSD systems are  
>> different).
>
> Then `i686-darwin9' is irrelevant at all?

I may have confused things by including ruby -v from my laptop.  I was  
making a more general claim about Process.daemon--not something  
specific to Mac OS X.

>> The second fork ensures that the process (the grandchild of the
>> original process) is no longer a session leader and therefore can't
>> acquire a controlling terminal by opening a tty device.
>
> Could you show concrete example?

I'm not sure if you are asking for a code example or just a better  
explanation of the consequences of having a controlling terminal.

<http://www.faqs.org/faqs/unix-faq/programmer/faq/>
Has a good rundown of creating a daemon including the second fork. The  
umask recommendation also might be worth considering.

As for a controlling terminal, <http://opengroup.org/onlinepubs/007908799/xbd/termios.html 
 > has lots of the gory details of controlling terminals.

The point is that the process probably doesn't *want* a controlling  
terminal (otherwise it wouldn't have called Process.daemon in the  
first place) and so to be sure it doesn't get one inadvertently if it  
opens a tty device, a second fork should be done after the setsid:

     proc_setsid();

     switch (rb_fork(0, 0, 0, Qnil)) {
       case -1:
         return (-1);
       case 0:
         break;
       default:
         _exit(0);
     }

After the second fork, the remaining process is no longer a session  
leader and so can't inadvertently get a controlling terminal.

I admit that this is an obscure case. Perhaps Process.daemon should be  
extended with some options so that the behavior can be tuned as needed:

Process.daemon(:chdir => "/tmp", :double_fork => true, :umask => 0)

Gary Wright