Project

General

Profile

Actions

Bug #1403

closed

Process.daemon should do a double fork to avoid problems with controlling terminals

Added by gwright (Gary Wright) over 15 years ago. Updated over 13 years ago.

Status:
Closed
Assignee:
-
Target version:
ruby -v:
ruby 1.9
Backport:
[ruby-core:23305]

Description

=begin
Standard practice when 'daemonizing' is to do a second fork so that the final process is no longer a session leader and therefore can't acquire a new controlling terminal.

See Stevens, Advanced Programming in the Unix Environment for details.
=end

Actions #1

Updated by nobu (Nobuyoshi Nakada) over 15 years ago

=begin
Hi,

At Sat, 25 Apr 2009 08:06:36 +0900,
Gary Wright wrote in [ruby-core:23305]:

Author: Gary Wright
Status: Open, Priority: Normal
ruby -v: ruby 1.9.0 (2008-07-25 revision 18217) [i686-darwin9]

Standard practice when 'daemonizing' is to do a second fork
so that the final process is no longer a session leader and
therefore can't acquire a new controlling terminal.

See Process.setsid. Process.daemon implies it.

And daemon(3) is deprecated on Darwin.

--
Nobu Nakada

=end

Actions #2

Updated by nobu (Nobuyoshi Nakada) over 15 years ago

=begin
Hi,

At Sat, 25 Apr 2009 09:52:46 +0900,
Gary Wright wrote in [ruby-core:23307]:

Author: Gary Wright
Status: Open, Priority: Normal
ruby -v: ruby 1.9.0 (2008-07-25 revision 18217) [i686-darwin9]

Standard practice when 'daemonizing' is to do a second fork
so that the final process is no longer a session leader and
therefore can't acquire a new controlling terminal.

See Process.setsid. Process.daemon implies it.

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?

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?

--
Nobu Nakada

=end

Actions #3

Updated by nobu (Nobuyoshi Nakada) over 15 years ago

  • Category set to core
  • Target version set to 1.9.2
  • ruby -v changed from ruby 1.9.0 (2008-07-25 revision 18217) [i686-darwin9] to ruby 1.9

=begin

=end

Actions #4

Updated by nobu (Nobuyoshi Nakada) over 15 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

=begin
Applied in changeset r23280.
=end

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0