tmux and the Terminal

lesson
terminal-emulation
pty
tmux
session-persistence
multiplexing
l1 ---# tmux and the Terminal: What's Actually Happening

Topics: terminal emulation, PTY, tmux, session persistence, multiplexing Level: L1 (Foundations) Time: 30–45 minutes Prerequisites: Basic command line

The Mission¶

You SSH into a server, start a long-running process, your WiFi drops, and the process dies. You learn about tmux, start using it, and your processes survive disconnects. But why? What is tmux actually doing that keeps processes alive? And what is a "terminal" anyway?

What a "Terminal" Actually Is¶

When you open a terminal app (iTerm2, GNOME Terminal, Windows Terminal), you're running a terminal emulator — software that pretends to be a 1970s VT100 hardware terminal.

The terminal emulator connects to a PTY (pseudo-terminal) — a kernel device that acts as the intermediary between your shell and the display:

Terminal emulator ←→ PTY (kernel) ←→ Shell (bash/zsh) ←→ Your commands

Name Origin: "TTY" stands for "Teletype" — the ASR-33 Teletype machine from the 1960s that printed output on paper at 10 characters per second. Terminal commands were kept short (ls, cp, mv) because typing was slow. "PTY" = "pseudo-TTY" — a software version of the hardware terminal. The names persist 60 years later.

When you SSH into a server, the chain extends:

Your terminal ←→ SSH client ←→ [network] ←→ SSH server ←→ PTY ←→ bash ←→ commands

If the SSH connection drops, the server's PTY closes. When the PTY closes, the kernel sends SIGHUP to all processes attached to it. SIGHUP = "your terminal hung up." The processes die.

What tmux Does¶

tmux creates its own PTY, independent of your SSH connection:

Without tmux:
  SSH ←→ PTY ←→ bash ←→ commands
  SSH drops → PTY closes → SIGHUP → commands die

With tmux:
  SSH ←→ PTY₁ ←→ tmux client
                    ↕
                  tmux server ←→ PTY₂ ←→ bash ←→ commands
  SSH drops → PTY₁ closes → tmux client dies
  But tmux server + PTY₂ + bash + commands survive!
  SSH reconnect → new tmux client attaches to surviving server

The tmux server owns the PTY. It runs as a background process. Your tmux client connects to the server. When SSH drops, the client dies but the server keeps running.

# Start a new session
tmux new -s work

# Detach (session keeps running)
Ctrl-b d

# List sessions
tmux ls
# → work: 1 windows (created Sat Mar 23 14:00:00 2026)

# Reattach (from any SSH session)
tmux attach -t work

Essential tmux for DevOps¶

# Split panes (multiple views in one window)
Ctrl-b %     → split vertically (left|right)
Ctrl-b "     → split horizontally (top/bottom)
Ctrl-b arrow → move between panes

# Windows (tabs)
Ctrl-b c     → new window
Ctrl-b n     → next window
Ctrl-b p     → previous window
Ctrl-b 0-9   → jump to window number

# Session management
Ctrl-b d     → detach (session survives)
Ctrl-b s     → switch between sessions
tmux attach  → reattach to last session

# Scroll/copy mode (essential for reading log output)
Ctrl-b [     → enter scroll mode (use arrow keys / Page Up/Down)
q            → exit scroll mode

The DevOps tmux workflow¶

# SSH in, start a tmux session with meaningful name
ssh server
tmux new -s deploy

# Pane 1: run the deploy
./deploy.sh

# Split and monitor logs in pane 2
Ctrl-b %
journalctl -u myapp -f

# Split again for monitoring in pane 3
Ctrl-b "
watch kubectl get pods

# WiFi drops, SSH reconnects:
ssh server
tmux attach -t deploy
# All three panes are still there, exactly as you left them

Gotcha: screen is tmux's predecessor (1987, GNU project). It still works but has fewer features, worse pane support, and an older codebase. Unless you're on a minimal system without tmux, use tmux.

Flashcard Check¶

Q1: Why do processes die when SSH disconnects?

The PTY closes, and the kernel sends SIGHUP to all processes attached to it. SIGHUP's default action is to terminate the process.

Q2: How does tmux prevent this?

tmux creates its own PTY (owned by the tmux server process). When SSH drops, the tmux client dies but the server and its PTY survive. Processes keep running.

Q3: Ctrl-b d — what does it do?

Detaches from the tmux session. The session (and all processes in it) keeps running in the background. tmux attach to reconnect.

Cheat Sheet¶

Action	Shortcut
New session	`tmux new -s name`
Detach	`Ctrl-b d`
Reattach	`tmux attach -t name`
List sessions	`tmux ls`
Split vertical	`Ctrl-b %`
Split horizontal	`Ctrl-b "`
Move between panes	`Ctrl-b arrow`
New window	`Ctrl-b c`
Next/prev window	`Ctrl-b n` / `Ctrl-b p`
Scroll mode	`Ctrl-b [` (q to exit)
Kill pane	`Ctrl-b x`

Takeaways¶

Processes die on SSH disconnect because SIGHUP. The PTY closes, SIGHUP fires, processes terminate. This is by design, not a bug.
tmux survives by owning its own PTY. The tmux server is a separate process with its own terminal. Your client connects to it. Client death ≠ server death.
Always use tmux for long-running operations. Deploys, migrations, backups — anything that takes more than 5 minutes should run in a tmux session. WiFi drops are not "if" but "when."

The Hanging Deploy — why processes receive signals (SIGHUP is one)
SSH Is More Than You Think — the SSH connection that tmux attaches to
The /proc Filesystem — /proc/PID/fd/0 shows the PTY