tmux Is Client-Server

In one line

What actually runs your commands in tmux is not your terminal but a server process. Your terminal is only a screen attached to that server, so when the screen goes away, the work keeps going.

Why this was needed

You are running a deployment script on a remote server when the Wi-Fi drops. When you reconnect, the script has died halfway and left things half applied. Everyone goes through this at least once.

Why did it die? When the SSH connection drops, the controlling terminal of that session disappears and the kernel sends SIGHUP to the session leader. The shell propagates it to its jobs. The deployment script was a child of my shell, so it died with it.

You can cut that link with nohup or setsid. But then the work survives, but you can never see its screen again. To follow progress you have to watch a log file separately, and you can't type input midway.

tmux solves this the other way. It makes the command a child of the tmux server, not of your shell. The tmux server is a separate process unrelated to your SSH session, and it owns the pseudo-terminal (pty) of each window. Your terminal is only a client that receives that screen. So when the client disappears, the server and its children are not affected at all. Reconnect and run tmux attach, and you get the screen back exactly as it was.

How it works

The structure has four layers, each with a familiar analogy.

Layer	Analogy	Command
Server	Operating system	Starts automatically when you create the first session
Session	Desktop / workspace	tmux new -s dev
Window	Browser tab	prefix + c
Pane	Screen split	prefix + % / "

Every key input has two stages: press the prefix key first, release it, then press the command key. The default is Ctrl-b, and many people change it to Ctrl-a, which is easier on the hand. That collides with the shell's "go to start of line" shortcut, so add bind C-a send-prefix as well, so that pressing it twice passes the original key through.

Knowing just five core commands for handling sessions is enough for the first day.

• tmux new -s 이름 – create and attach (name: the session name)
• tmux new -d -s 이름 – create without attaching (essential in scripts)
• tmux ls – list
• tmux attach -t 이름 – attach
• prefix + d – detach

And the most useful idiom in practice: tmux new -A -s dev attaches if the session exists and creates it if not. If you set it up as a shell alias, you never need to check whether it exists.

What you see in the field

An overnight migration. Log in to the DB server, create a session with tmux new -s migration, start the migration, detach and go home. Attach the next day and you see the progress exactly as it was. Unlike nohup, the screen and the input stay alive.

A three-way split development environment. An editor on the left, the development server at top right and a test watcher at bottom right. Instead of building this layout by hand every time, you reproduce it with one line of script. What people often forget here is -c "#{pane_current_path}". Without it, a newly created pane opens in the home directory and you have to type cd again each time.

Operating several servers at once. If you create 4 panes, each connected to one of 4 servers over ssh, and turn on synchronize-panes, every command you type runs in all 4 places at once. It is as dangerous as it is powerful, so it is wise to show the on/off state in the status bar.

One terminology trap. In tmux, split-window -h does not mean "split horizontally" but split left and right (panes are laid out along the horizontal direction). -v is top and bottom. It is confusing, so when you talk, say "left-right split / top-bottom split" and memorize the flags separately.

Two settings are worth changing on day one. base-index 1 and pane-base-index 1, because the 0 key is at the far right of the keyboard and is awkward. And history-limit defaults to 2000 lines, so even a short look at a log gets cut off. About 50,000 lines is a practical ceiling.

Making work that survives a disconnect

The biggest reason to use tmux is not splitting the screen but work that keeps going when the connection drops. To make proper use of that property, you need to settle a few things.

Give the session a name. Numbers change as you attach and detach. With a name, the one-line "attach if it exists, create if not" becomes possible.

tmux new-session -A -s deploy      # 있으면 attach, 없으면 새로

If you put this line in a script, you return to the same place every time you log in.

Give a long job a window of its own. Run a migration or a large copy only in that window, and rename the window to the name of the job. Even when you come back hours later, you know which window is which.

Ctrl-b ,        창 이름 바꾸기
Ctrl-b w        창 목록에서 고르기
Ctrl-b d        떼어 내기(작업은 계속 돈다)

Use copy mode instead of scrolling. The terminal scrollbar does not work well inside tmux. Enter copy mode with Ctrl-b [ and you can scroll up and even search. The default history is 2,000 lines, so long logs get cut off; increase it.

set -g history-limit 50000

Prepare for nesting. If you start tmux again on a remote server, the prefix keys collide. To send it to the inner one, press Ctrl-b twice. If you do this often, it is better to change the prefix of the inner session to something else.

Several people can view the same session. During incident response you can use it instead of screen sharing. But when you attach to the same session, the window size is fitted to the smallest screen. To look at different windows, create separate sessions.

tmux new-session -t deploy -s deploy-2   # 창은 공유, 보기는 따로

When tmux dies, everything is gone. If the server reboots, the sessions do not survive. Work that truly has to survive should be made a systemd unit or a batch job, not a tmux session. tmux is a tool for work that a person is attached to.

What you will do in the next lab

Two labs follow. In tmux-basics you create sessions and windows, check the detached state, and verify that the configuration file is really applied to the server. In tmux-panes you work with pane splitting, titles, zoom and synchronization, and at the end build a script that reproduces a development layout. The last step of both labs is an automation script because a layout made by hand disappears by the next day, while a script stays.