How Terminal Multiplexers Keep Sessions Alive
A terminal multiplexer is more than several shells in one window. PTYs, a persistent server, and reattachment explain why tmux and screen survive a dropped SSH connection.
When a normal SSH session disappears, its shell usually loses the terminal that connected it to the user. A multiplexer such as tmux changes that ownership model: the shell belongs to a long-lived local server, while the visible terminal is only a replaceable client.
The kernel object behind a terminal window
Modern terminal emulators and SSH daemons use a pseudoterminal, or PTY. A PTY has a master side and a slave side. The terminal emulator controls the master; a shell opens the slave as its controlling terminal. Bytes written by the shell become output, while bytes sent to the master become input after the terminal driver’s line discipline processes them.
Interactive programs do not need to know whether the other end is a physical serial terminal, an SSH connection, or a graphical terminal emulator. They ask the PTY for its size and settings, emit escape sequences, and receive signals such as SIGWINCH when the window changes.
Where the multiplexer fits
Starting tmux creates, or contacts, a server process. For every pane, that server allocates another PTY and starts the requested shell on its slave side. The server owns the master sides and continually reads their output. A tmux client then renders one or more panes onto the user’s current terminal.
This adds a layer:
terminal or SSH -> tmux client -> tmux server -> pane PTY -> shell/program
The pane’s shell is therefore not directly attached to the SSH PTY. Detaching closes the client connection but leaves the server, pane PTY, and shell intact. Reattaching creates a new client and redraws the saved screen state.
Sessions, windows, and panes are server state
A session is a named collection of windows; a window is a layout of panes; a pane corresponds to a PTY and foreground process group. These are tmux concepts rather than kernel terminal types. Multiple clients can attach to the same session, and the server decides how to map its virtual screen onto clients with different dimensions.
The server also interprets the prefix key before ordinary input reaches a pane. Commands such as splitting, selecting, or detaching manipulate server state; other keystrokes are forwarded to the active pane’s PTY.
What persistence does and does not mean
The session survives a lost network connection because the server runs on the remote host. It does not survive that host rebooting, the tmux server being killed, or its user account losing all processes. A multiplexer also is not a job scheduler: important unattended work should still have durable logs, explicit restart policy, and an appropriate service manager.
Sources: