Is it the process that has a controlling terminal, or is it the session that has a controlling terminal?

Question

When we say that a process has a controlling terminal, do we mean that the process itself has a controlling terminal, or is it the session that the process belongs to that has a controlling terminal?

I used to think that it is the session that has a controlling terminal, but then I have read the following (from here) which implies that it is the process that has a controlling terminal:

One of the attributes of a process is its controlling terminal. Child processes created with fork inherit the controlling terminal from their parent process. In this way, all the processes in a session inherit the controlling terminal from the session leader. A session leader that has control of a terminal is called the controlling process of that terminal.

Answer 1

It is indeed the session that has a controlling terminal

The Single UNIX Specification describes the relationship in terms of the controlling terminal being "associated with a session". As it goes on to specify, a controlling terminal has a 1:1 relationship with a session. There is "at most one controlling terminal" associated with a session, and "a controlling terminal is associated with exactly one session".

The FreeBSD Design and Implementation book approaches this slightly differently, but reaches the same place. It is not possible for processes that share the same session to have different controlling terminals, nor is it possible for a single terminal to be the controlling terminal of multiple sessions.

Internally in FreeBSD that is how the data structures actually work. The process structure has a pointer to the pgrp structure representing the process group that the process belongs to, which in turn points to the session structure representing the session that the process group belongs to, which in turn points to the tty structure of the controlling terminal for the session.

Internally in Linux, things are slightly more complex. Each task_struct has a set of pointers to pid structures for its process group ID and session ID; and has another pointer to a per-process signal_struct structure that in turn directly points to the tty structure of the controlling terminal.

Further reading

• George V. Neville-Neil, Marshall Kirk McKusick, and Robert N.M. Watson (2014-09-25). "Process Management". The Design and Implementation of the FreeBSD Operating System. Addison-Wesley Professional. ISBN 9780133761832.
• Donald Lewine (1991). "Terminal I/O". POSIX Programmers Guide. O'Reilly Media, Inc. ISBN 9780937175736.
• Daniel P. Bovet and Marco Cesati (2005). "Processes". Understanding the Linux Kernel: From I/O Ports to Process Management. 3rd edition. O'Reilly Media, Inc. ISBN 9780596554910.
• "Definitions". The Open Group Base Specifications. Issue 7. 2016. IEEE 1003.1:2008.
• "General Terminal Interface". The Open Group Base Specifications. Issue 7. 2016. IEEE 1003.1:2008.

Answer 2

_{^{my knowledge is not sufficient, following answer can be wrong}}

@key::

any process can detach from its controlling tty, if it has one, with the TIOCNOTTY ioctl.

https://stackoverflow.com/questions/50649796/how-would-the-existing-processes-in-the-session-learn-about-and-acquire-the-cont

existing children are not affected.

When a session leader acquires a controlling terminal, how would the other existing processes in the session also acquire the controlling terminal?

=> (@answer::)

• in a large scope, the session_SS (as a whole of many process) & the controlling_terminal_FF can be associated or not

• (say now, session_SS is associated with the controlling_terminal_FF)

  for each individual processes (inside session_SS),

  they are still not necessarily be associated with the controlling_terminal_FF (ie: detached, have no controlling terminal)

  (they have the option of being associated with the controlling_terminal_FF or not)

  • but the option is constrained to only one terminal -- the controlling_terminal_FF.

• [[so, there isnt really any strict "have/contain" relation how you commonly call it,

  its about the "association/rules/constraints",

  the session can "have/associate" & the process can also "have/associate" with the terminal -- the session "constrains" how the process can associate]]

@details::

say you have created a lot of processes, process groups, sessions.

now you have a process session_leader_AA in session_SS

you have a terminal_FF

when a session_leader_AA in session_SS connects/open() a terminal_FF -- that terminal_FF becomes the controlling terminal of session_SS (and session_leader_AA becomes the controlling process of terminal_FF)

• a child process inherits the controlling terminal from its parent process

  • any child process in session_SS that already existed before session_leader_AA connects to a terminal_FF

    -- are still not connected with any terminal

  • any child process in session_SS that are created after session_leader_AA connects to a terminal_FF, but not child processes of session_leader_AA

    -- are still not connected with any terminal

• any process can detach from its controlling tty, if it has one, with the TIOCNOTTY ioctl.

@rule,note::

• 1 controlling terminal can only connect with 1 session

  1 session can only connect with 1 controlling terminal

• All of the processes in a session can have a (single) controlling terminal

  ie: processes have a controlling terminal, (some processes have no controlling terminal,) and that controlling terminal they have, must be referring to the same one.

• The ioctl(fd, TIOCNOTTY) operation can be used to remove a process’s association with its controlling terminal.

  (any process can call ioctl(fd, TIOCNOTTY), if that process has an associated controlling terminal)

  (Especially,) If the controlling process session_leader_AA for the controlling_terminal_FF calls ioctl(fd, TIOCNOTTY)

  the following steps occur:

  1. All processes in the session lose their association with the controlling terminal.

  2. The controlling terminal loses its association with the session,

     (and can therefore be acquired as the controlling terminal +- by another session leader.)

  3. The kernel sends a SIGHUP signal (and a SIGCONT signal)

     +- to all members of the foreground process group,

     +- to inform them of the loss of the controlling terminal.

  • (these are the same steps occur when the controlling process terminates)

  The Linux Programming Interface

• there are other associated pbs, no confirmation on the answer yet:_

  1. so call non-controlling terminal:_ regular terminal as file / terminal connected but non-controlling, only for reading data

  2. does the detached process not receving inputs from the Controlling_Terminal (purpose)

  3. 1. a session_leader_AA in session_SS connects/open() a terminal_FF -- that terminal_FF becomes the controlling terminal of session_SS

     2. a child process inherits the controlling terminal from its parent process

     seems the only 2 way to associate a (session/)process with a terminal

  4. seems even process in Foreground_Process_Group can be detached from the Controlling_Terminal