[#23231] What do you think about changing the return value of Kernel#require and Kernel#load to the source encoding of the required file? — =?ISO-8859-15?Q?Wolfgang_N=E1dasi-Donner?= <ed.odanow@...>

Dear Ruby developers and users!

8 messages 2009/04/17

[#23318] [Feature #1408] 0.1.to_r not equal to (1/10) — Heesob Park <redmine@...>

Feature #1408: 0.1.to_r not equal to (1/10)

19 messages 2009/04/26

[ruby-core:23310] Re: [Bug #1403] Process.daemon should do a double fork to avoid problems with controlling terminals

From: Gary Wright <gwtmp01@...>
Date: 2009-04-25 04:05:30 UTC
List: ruby-core #23310
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




In This Thread