Course contentsShow
← Linux
Lesson 63 of 1,8191. Shell Architecture and Process EnvironmentFree lesson

The Controlling Terminal Lifecycle

Handle terminal reattachment and the loss of standard input/output devices.

In this lesson, you will learn how processes maintain, lose, and regain their connection to the terminal that governs their input and output.

The Bond Between Process and Terminal

Every interactive shell session begins with a controlling terminal (often /dev/tty). When you launch a process, it inherits this terminal as its default gateway for stdin, stdout, and stderr. This "lifecycle" is essentially the story of how a process stays tethered to your screen and keyboard.

The Loss of the Terminal

The lifecycle enters a critical phase when the terminal window is closed or the network connection drops. When the terminal session terminates, it sends a SIGHUP (Hangup) signal to the Session Leader (the shell). The shell then propagates this signal to all child processes.

If a process is not designed to handle SIGHUP, it dies immediately because its file descriptors for stdin, stdout, and stderr are now effectively broken pipes or invalid references. The process loses its "controlling terminal" because that terminal literally no longer exists.

Reattachment Mechanics

Processes cannot simply "reattach" to a new terminal automatically because the kernel strictly manages which process owns which terminal. If you want a process to survive the lifecycle of a terminal, you must "detach" it from the terminal's death signals.

Tools like nohup do this by ignoring SIGHUP, while terminal multiplexers (like tmux or screen) act as a middleman. When you use a multiplexer, the process is tethered to a virtual terminal managed by a persistent background server. When your physical terminal window closes, the process remains connected to the virtual one:

# Starting a process in a persistent shell
tmux new -s my_session
# Even if you exit the window, the process keeps its 'terminal'

When you open a new terminal, you "reattach" to the multiplexer, which simply reconnects your new physical terminal to the existing virtual input/output streams. The process never realized its original terminal window had closed, so it never lost its controlling environment.

Key Takeaway: A process’s lifecycle is tethered to its controlling terminal; to survive a terminal closure, a process must either ignore the hangup signal or be moved to a persistent virtual terminal that manages I/O on its behalf.