17

Say that I have opened some program from the terminal, and I have redirected its stdin and stdout and stderr to three files.

Even though this program no longer send its output to the terminal and no longer receive its input from the terminal, the program still has a "link" to the terminal. The terminal that the program has this "link" with is called the controlling terminal, the following image illustrates this:

enter image description here

My question is: what is the purpose of the controlling terminal, my guess is that the controlling terminal can be used to send signals to the program (for example: Ctrl+C).

Are there other purposes for the controlling terminal?

John
  • 171
  • Because it is a sub-process of the shell you were running in the terminal. Even if you ran this from soem other function like cron the cron process would be the parent process. Only way to get around it would be to boot a kernel and provide an init=/program - but then you couldn't redirect I/O to/from it – ivanivan Nov 14 '17 at 19:17
  • Related questions: https://unix.stackexchange.com/questions/405755/ and https://unix.stackexchange.com/questions/84737/ – JdeBP Nov 20 '17 at 16:18

1 Answers1

13

With controlling terminal, process is able to tell kernel which process group is foreground process group (in same session). If there is a foreground process group for a terminal, we can control the foreground process group via the terminal, e.g., Ctrl-C/Ctrl-\ to terminate the foreground process group. (A terminal may have only one foreground process group, or may not have any. To put it precisely, a terminal can only be associated with one process session.)

With controlling terminal, even if you already redirect stdin to other places/files, you still be able to read/write from/to controlling terminal, the /dev/tty. This special file is a synonym within the kernel for the controlling terminal of current process. If your process has no controlling terminal associated, then open this file will fail. What can you do regarding this file? E.g., some programs need user to input password before doing something, such as programs for login or encryption. These programs may prohibit user from inputting password from stdin, which means even if you redirect their stdin to a random file, they'll still wait for your type. The reason is they all open /dev/tty to read.

To sum up, with controlling terminal, kernel is aware of where to deliver terminal-generated signal and terminal input if they are expected by someone. That's all.

So it is unnecessary for a process to associate with a controlling terminal, if it doesn't want to be controlled by any terminal, and doesn't want to read/write from/to "/dev/tty" (like most daemon programs). However, a common process launched from within a shell always have controlling terminal associated, because it is member of shell session, which has already established a controlling terminal when shell starts up. (Actually, a random process cannot attach a terminal as controlling terminal, only session leader process can.)

Bruce
  • 1,241
  • Your first point is wrong, and is contradicted by your second. Foreground and background processes do not have their controlling terminals removed. – JdeBP Nov 14 '17 at 20:26
  • Thank you @JdeBP, you are right. I've modified my answer. – Bruce Nov 15 '17 at 03:00
  • This job control stuff can be implemented purely in userland, controlling terminal, or the whole terminal subsystem, seems to be an old thing since the time we only have terminal device instead of LCD screen and keyboard. – 炸鱼薯条德里克 Jan 13 '19 at 02:57
  • "a random process cannot attach a terminal as controlling terminal, only session leader process can". Technically, a privileged process with CAP_SYS_ADMIN capability can use ioctl() to do that, see https://stackoverflow.com/a/30693006/3701431 – Sergiy Kolodyazhnyy Mar 08 '19 at 19:41
  • I wonder how when you start bash as init it's still able to receive input from the tty and write output to it. If tty was synonymous to controlling terminal it won't be possible because at this point there's no controlling terminal. Or is it a special tty? – axk May 02 '21 at 13:29
  • @axk The kernel documentation specifies that the first non-kernel process, called init or "PID 1", is started with /dev/console connected to standard output, standard error, and standard input. So any output to /dev/console will display on your screen and keyboard input will go into it also. Controlling terminal just plays a role in handling signals. So if bash is invoked as pid 1, it can still read/write normally but can not handle any signals. (login program prepares for a controlling terminal for bash) – Li-Guangda Mar 13 '22 at 15:43