Question

The reason for doing a double-fork when daemonizing is to prevent the daemon acquiring a controlling tty (What is the reason for performing a double fork when creating a daemon?)

What are some examples of programs that acquire a controlling tty, and why do they need to do so?

My question is motivated by this problem: How to monitor child process output and exit status without adversely affecting child?

Was it helpful?

Solution

Examples of programs that intentionally acquires a controlling tty are getty (the program that handles setting up "real" tty lines like consoles, RS-232 serial lines, and modems for use as login terminals) and sshd (forks and acquires a pesudo-terminal).

In the context of the reason for double-forking, however, it's much more important to emphasize programs that accidentally (unintentionally) acquire a controlling tty, because that is mainly what the double fork is guarding against, according to the answer you referenced. So an example of a program that unintentionally acquires a controlling tty is anything that:

  • doesn't already have a controlling tty (typically, a daemon);
  • doesn't double fork but calls setsid() and is therefore a session leader;
  • happens to open a tty without O_NOCTTY

In other words: since programs don't generally use O_NOCTTY on every open and don't generally intend to acquire controlling terminals when they open things, it's very useful to use the double-fork method to prevent the acquisition from happening.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top