Learn › Linux Foundations › Multiplexers
tmux - a hands-on Linux lab on a real virtual machine.
Keep work alive across a disconnect with tmux, the modern terminal multiplexer. Detachable sessions, windows, and split panes in one terminal. The shell subcommands (tmux ls, tmux new -s, tmux attach -t, tmux kill-session -t) plus the Ctrl-b key bindings for detach, windows, and panes. tmux takes over the screen, so the drills teach the shape of the frame and the bindings; your clock and hostname vary.
You are halfway through a long job on a remote machine. A copy is running, a build is churning, a download is crawling. Then your laptop sleeps, the wifi drops, or you simply close the lid to go home. When you reconnect, the work is gone: the connection died and took your running command with it.
There is one command that makes that impossible. It holds your session on the remote machine itself, alive and running, whether you are connected or not. You detach, walk away, close everything, come back tomorrow, and reattach to find your work exactly where you left it, still running. It is called tmux.
The black boxes below are a practice terminal: a safe sandbox that checks the one shell command each step teaches. One honest catch, bigger here than in any other lesson: tmux is a full-screen program. When you start it, it takes over the entire terminal and paints a status bar along the bottom. A sandbox can only show you a still snapshot of that takeover. So read every full-screen frame below as one frozen picture of a live screen, and know the keystrokes that drive it (the Ctrl-b combinations) are pressed, not typed, so they are taught in prose rather than graded in a box.
tmux is short for terminal multiplexer. A multiplexer takes one thing and lets it hold many. Here the one thing is your single terminal window, and tmux lets it hold many independent shells at once, and keeps them all running even when you disconnect.
It gives you three superpowers stacked on top of a plain terminal. Sessions keep running on the machine after you detach, so nothing dies when your connection does. Windows are like tabs: several full-screen shells you flip between inside one session. And panes split one screen into side-by-side shells, so you watch a log on the left while you type on the right.
One idea carries the whole lesson: detach and reattach. You leave a session running (detach) and later reconnect to it (reattach). That is the superpower that survives a closed lid, and everything else in tmux builds on it.
tmux was written by Nicholas Marriott and first released in 2007, decades after the older tool it replaced. That older tool is screen, from 1987, and for a long time it was the only game in town for keeping a session alive across a disconnect.
One sentence to file away: tmux is the modern one (split panes, easy scripting, a readable config), while screen is the older, ubiquitous one you will still meet on machines that predate tmux. They solve the same core problem, detach and reattach, so learning tmux teaches you the idea; you will recognise screen when you see it.
Before you start anything, ask tmux what sessions it is already holding. The subcommand ls (short for list sessions) prints every session the tmux server is running for you. On a fresh machine there is no server running yet, so tmux tells you exactly that.
Before you run it, commit to a picture. Nothing has been started, so there is no server for tmux to talk to. Expect a short complaint, not a list.
tmux ls
prompt: student@linuxcamp:~$ answer: tmux ls output: no server running on /tmp/tmux-1000/default hint: Type tmux, a space, then ls for list sessions: tmux ls
That message is not an error you caused; it is tmux reporting the honest truth that nothing is running yet. The path /tmp/tmux-1000/default is the socket file tmux would use, and the 1000 in it is your numeric user id, so on a machine where your id is different that number changes. What stays constant is the meaning: no server means no sessions, so start one next.
tmux runs as a background server, and tmux ls asks that server for its list of sessions. With no server started, there is no one to answer, so you get no server running instead of an empty list. This is the safe, read-only way to check the lay of the land before you do anything: run tmux ls first and you always know whether you are about to create a fresh session or step back into an existing one.
Now start a session, and give it a name so you can find it again. The subcommand new creates a session, and the -s flag (short for session name) labels it. Name it work. The instant you run this, tmux takes over the screen.
Before you run it, commit to a picture. You will not drop back to your prompt. Instead the whole terminal becomes a fresh shell with a coloured bar pinned along the bottom: that bar is how you know you are inside tmux.
tmux new -s work
prompt: student@linuxcamp:~$ answer: tmux new -s work output: student@linuxcamp:~$
[work] 0:bash* "linuxcamp" 14:23 05-Jul-26 hint: Type tmux new, then the -s flag, then the name work: tmux new -s work
This is one frozen frame of a screen that tmux now owns completely. The top is an ordinary shell prompt, ready for commands. The bottom line is the tmux status bar: on the real machine it is green. On the left, [work] is your session name and 0:bash* is window 0 running bash (the * marks the window you are looking at). On the right is the hostname and a live clock. That clock, the hostname, and the date are this machine's at that one second; yours will read differently, and the clock keeps ticking.
Here is the superpower in two moves. To leave a session running and drop back to your normal shell, you press a key binding, not a typed command. Every tmux binding starts with the prefix, Ctrl-b (hold Control, press b, release both), followed by one more key. To detach, the key is d.
So inside the session you press Ctrl-b then d. The full-screen takeover vanishes, tmux prints a short [detached] line, and you are back at your ordinary prompt, but the work session is still alive on the machine, still running whatever you left in it.
To step back into it later, use the attach subcommand with -t (short for target, meaning which session by name). Reattach to work:
tmux attach -t work
prompt: student@linuxcamp:~$ answer: tmux attach -t work output: student@linuxcamp:~$
[work] 0:bash* "linuxcamp" 14:24 05-Jul-26 hint: Type tmux attach, then the -t flag for target, then the name work: tmux attach -t work
The detach itself is a keystroke (Ctrl-b then d), so it cannot be typed into a box; only the reattach, tmux attach -t work, is a shell command you run. This frame is the takeover coming back: the same green status bar, the same [work] session, everything exactly as you left it because it never stopped. The clock jumped forward a minute (14:24) to show time passed while you were away. There is a shorthand worth knowing: tmux a -t work is the same as tmux attach -t work.
That pair is the whole reason tmux exists. Ctrl-b d detaches: your session keeps running on the machine while you go do something else, or lose your connection entirely. tmux attach -t work reattaches: you find the session running exactly where you left it. Close your laptop, reconnect tomorrow, run tmux attach -t work, and your long job is still going. That is the closed-lid problem from the top of the lesson, solved.
Inside a session, the same Ctrl-b prefix drives everything. You never type these as commands; you press the prefix, release, then press one more key. A few earn their place from day one.
Windows are like tabs. Ctrl-b c creates a new window, Ctrl-b n moves to the next one, Ctrl-b p to the previous, and Ctrl-b w shows a pick-list of all your windows.
Panes split one screen into side-by-side shells. Ctrl-b % splits the current pane into a left and a right (a vertical divider). Ctrl-b " splits it into a top and a bottom (a horizontal divider). Once you have panes, Ctrl-b then an arrow key moves your cursor between them. This is how you watch a log in one pane while you type in another.
There is no :::terminal for these because they are keystrokes, not commands, and a static box cannot capture a key press or the split screen it produces. On the real machine in the capstone, you will press each one and watch the screen respond. For now, learn the map: prefix first (Ctrl-b), release, then the action key.
Scaffolding off. No command is printed this time. You have every piece you need.
You started a session earlier and named it work, then you detached from it and closed your laptop. You are back at a plain shell prompt and you want to step back into that exact session, by name, and pick up where you left off. Recall the subcommand that reconnects you and the flag that says which session by name.
prompt: student@linuxcamp:~$ answer: tmux attach -t work output: student@linuxcamp:~$
[work] 0:bash* "linuxcamp" 14:31 05-Jul-26 hint: The subcommand reconnects you to a running session, and the flag names the target. Think tmux attach, then -t, then the session name: tmux attach -t work
The command is tmux attach -t work. attach reconnects you to a running session and -t work names which one, so the full-screen work session paints back exactly as you left it, still running. This is the move you will type most often in real work: tmux ls to see what is running, then tmux attach -t <name> to step back in. You recalled both the subcommand and the flag from their meaning alone, which is exactly the recall the real machine will ask of you.
Three failures are worth recognising on sight, because the fix is different for each.
no server running on /tmp/tmux-1000/default. This is not really an error: it is tmux ls telling you nothing is running yet. It appears whenever you list or attach before any session exists. What to check first: nothing is wrong, just start one with tmux new -s <name>.
can't find session: work. You tried to attach to a name that does not exist, usually a typo or a session that was already killed. What to check first: run tmux ls to see the real session names, then attach to one that is actually in the list.
sessions should be nested with care, unset $TMUX to force. You ran tmux while already inside a tmux session, so it is warning you against a session inside a session. What to check first: you are probably already where you want to be, so detach with Ctrl-b d first, or if you truly need a nested session, the message names the escape hatch.
The nesting warning trips up nearly everyone once. Before you type tmux, glance at the bottom of the screen: if you see a green status bar, you are ALREADY in tmux, and you want a key binding (Ctrl-b something), not a fresh tmux command.
You earned this cheat sheet. The top rows are shell commands you type at the prompt; the bottom rows are key bindings you press inside a session (prefix Ctrl-b, release, then the key).
When you are done with a session for good, do not just detach, remove it: tmux kill-session -t work stops it and frees the name. Detach keeps work alive for later; kill-session ends it. Reach for kill-session once the job it held has finished.
The practice terminal has shown you the shape of tmux: the status bar takeover, tmux ls to see what is running, tmux new -s to start a named session, the Ctrl-b d and tmux attach -t detach-and-reattach pair, and the prefix bindings for windows and panes. The shell subcommands you typed yourself; the key bindings you now hold in your head.
The Multiplexers module ends with one real Linux machine, the Multiplexers capstone mission, and that is where you run tmux for real, take over the screen, split a pane, detach, and reattach to a session that kept running while you were gone. A VM boots just for you. It hands you objectives that use exactly what you practiced across this module: holding a session open, detaching, reattaching, and driving windows and panes. One difference from here: the mission shows no commands. You read the objective, you recall the command, you type it. That recall is what makes it stick.
Finish the other Multiplexers lessons, then go run a session that outlives your connection.
Practice tmux in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.