4

What happens with process when it is run without a controlling terminal? How is that process different from a standard processes? What features does it lose and what does it acquire?

UPDATE #1

The question listed as a possible duplicate: Concept of controlling terminal in Unix doesn't contain the answer. Also that other question is too broad and doesn't mention process qualities at all.

Community
  • 1
anatoly techtonik
  • 2,644
  • 2
    Possible duplicate of Concept of controlling terminal in Unix – Jeff Schaller Mar 19 '17 at 13:14
  • This doesn't seem like a duplicate to me on the grounds that he's asking for the specific mechanics as to how this works. There is a potential for both questions to be answered by a single answer that shows the specifics of what the accepted answer in the dup is describing at a high level. If such an answer were to materialize then these 2 Q's could be marked as dups of one another. I'll bring attention to a link on the other Q as a good start to this: http://www.linusakesson.net/programming/tty/index.php. – slm Mar 19 '17 at 14:54
  • @slm, thanks. The question may sound lame, but so far my understanding of Linux internals (signals, IPC etc.) is very vague, so all descriptions of controlling terminal are overly confusing. However, process concept is simple, so I hope it serve as an entrypoint to dig further. – anatoly techtonik Mar 19 '17 at 15:18
  • @anatolytechtonik - question is a fair one. I think you'll find that the only difference b/w a controlling terminal and one that's not is that the STDIN/STDOUT/STDERR are not connected to a TTY along with a few other esoteric bits in the process group etc. as described in the other Q's accepted A'er. – slm Mar 19 '17 at 15:21
  • You may find some useful info in Does keyboard input always go through a controlling terminal? – Stéphane Chazelas Mar 20 '17 at 14:01

1 Answers1

2

Not much.

Mostly a process without a controlling terminal is not subject to receiving (mostly job control related) signals from terminal events.

These would include SIGINT, interrupting the foreground process (group) if the interrupt character is received (usually ^C); SIGTTIN/SIGTTOU stopping the process if it tries I/O to the terminal from the background, and; SIGHUP telling the controlling process (the shell) to terminate, in when the terminal sees a disconnection. (Originally a modem hangup.)

The standard has the details if you like.

ilkkachu
  • 138,973
  • Thanks. I will appreciate if the explanation won't include word "terminal", if that at all possible, because it assumes a lot of knowledge about underlying subsystem. Maybe there is an image that shows how signals travel to a process from ...? Human? – anatoly techtonik Mar 21 '17 at 06:24