Learn › Linux Foundations › Multiplexers
screen - a hands-on Linux lab on a real virtual machine.
Keep long jobs alive across a dropped SSH connection with screen. List sessions with -ls, start one bare or named with -S, detach with Ctrl-a d, and reattach with -r or -d -r. screen is a full-screen multiplexer that takes over the terminal, so the drills teach the shell-level subcommands and the key bindings; your session ids vary.
You start a long copy over SSH from a laptop. It will run for an hour. Then the coffee shop wifi hiccups, your connection drops, and the shell dies. On a normal terminal, everything running in it dies with it. The copy is gone. You start over.
There is one classic command built to make sure that never happens. It hosts your shell inside a session that keeps running on the machine even after you disconnect. You reconnect later and your work is exactly where you left it, still running. It is called screen.
The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. One honest catch, unique to this lesson: screen is a full-screen tool. When you start it, it TAKES OVER the terminal and drops you into a fresh shell inside the session. A sandbox cannot run a live multiplexer, so the runnable drills here are the SHELL-level subcommands you type at your normal prompt (screen -ls, screen -S, screen -r). The one moment INSIDE a session is shown as a single representative frame, with a note saying so.
screen is a terminal multiplexer. Multiplexer means one thing carrying many: a single real terminal hosts many separate shells, called windows, and keeps them all alive in a session. That session lives on the machine, not in your connection.
The word that matters most is detach. You can step away from a running session, leaving everything inside it running, and the session keeps going without you. Later you reattach and pick up exactly where you left off. Think of it like a workshop you can lock and walk away from: the machines inside keep turning, and your key lets you back in whenever you return.
That is the whole reason screen exists. A dropped SSH connection cannot kill work that is running inside a detached session, because the session was never tied to your connection in the first place.
screen, more properly GNU Screen, is one of the oldest tools of its kind, first released in 1987. For decades it was THE way engineers kept long jobs alive across flaky connections, and it is still installed on servers everywhere. Its newer cousin tmux is the next lesson; the ideas you learn here carry straight over.
Before you start anything, ask screen what sessions already exist. The -ls flag stands for list sessions: it prints every screen session running under your user. On a fresh machine with nothing started, that list is empty, and screen says so in plain words.
Run it now to see the empty state. This is a normal command you type at your prompt, and it is one of the few screen outputs that is stable enough to practice on:
screen -ls
prompt: student@linuxcamp:~$ answer: screen -ls output: No Sockets found in /run/screen/S-student. hint: Type screen, a space, then a dash and the letters l s: screen -ls
That single line is screen telling you nothing is running yet. A socket is the small file screen uses to track a live session, and /run/screen/S-student is the folder where your user's session sockets would live. No sockets means no sessions. The path ends in your username, so on your machine it will read your own name rather than student. Now that you know the empty state, you can start a session and watch the list change.
To start a session you type screen on its own. The instant you press Enter, the terminal clears and hands you a brand new shell running INSIDE the session. It looks almost like your normal prompt, because it is a normal prompt, just one that now lives inside a session that can outlive your connection.
You cannot run a live screen in this sandbox, so read the frame below as one snapshot of that takeover. In real life, typing screen here would wipe the screen and leave you at a fresh prompt like this:
prompt: student@linuxcamp:~$ answer: screen output: student@linuxcamp:~$ hint: The command that starts a session is just its name on its own: screen
This is a representative frame, not a live session. On a real machine, screen takes over the whole terminal and clears it, and the fresh prompt you land on is running inside the session. Nothing visible tells you that you are inside screen; the proof comes from the key bindings and from screen -ls, both coming up next. Your hostname and username will differ from the student@linuxcamp shown here.
Everything you do INSIDE a session starts with a prefix: hold Ctrl and press a, written Ctrl-a. That combination tells screen the next key is a command to it, not text for your shell. You press the prefix, release, then press one more key.
The one that matters most is detach: Ctrl-a then d. It leaves the session running and drops you back to the terminal you started from. Whatever was running inside keeps running. This is the move that saves the long copy: detach, close your laptop, and the job carries on.
These are keystrokes, not commands you type, so there is no box to run here. Commit the four that matter to memory:
Two more bindings round out the set. Ctrl-a then " (a double quote) shows a menu of all your windows so you can pick one. Ctrl-a then k kills the current window after asking you to confirm. The prefix is always Ctrl-a, then one key; that pattern is the whole muscle memory of screen.
Here is the payoff of detaching. You pressed Ctrl-a d and you are back at your normal shell, but the session did not die. Ask screen to list sessions again and this time the list is not empty: the session you started is sitting there, marked Detached, ready for you to come back to.
Run the list command once more, now that a detached session exists:
screen -ls
prompt: student@linuxcamp:~$ answer: screen -ls output: There is a screen on: 12345.pts-0.host (Detached) 1 Socket in /run/screen/S-student. hint: Same list command as before, now that a session exists: screen -ls
This is the diff that teaches the whole lesson. Before, screen -ls said No Sockets found. Now it lists one session, 12345.pts-0.host, marked (Detached), and reports 1 Socket. That word Detached is proof your work survived: you left, and the session stayed. The session id (12345.pts-0.host) is built from a process number and terminal name that are this machine's at this moment, so yours will read a different number and host. What matters is the (Detached) marker, not the digits.
A detached session is only useful if you can get back into it. The -r flag stands for reattach: screen -r drops you back inside your detached session, exactly where you left it, still running. With only one session, you do not even need to name it; screen -r finds the single detached one and reconnects.
Before you run it, commit to a picture. You are at your normal shell with one detached session waiting. Reattaching will clear the terminal and put you back inside that session's shell. There is nothing stable to show inside, so the runnable drill is the reattach command itself:
screen -r
prompt: student@linuxcamp:~$ answer: screen -r output: student@linuxcamp:~$ hint: Type screen, a space, then a dash and the letter r to reattach: screen -r
Another representative frame: on a real machine screen -r takes over the terminal and you are back inside the session. Anything you left running is still going. The prompt shown is illustrative and will carry your own hostname. The full round trip is the heart of screen: start it, Ctrl-a d to detach, walk away, screen -r to return.
Once you run more than one session, 12345.pts-0.host is no name to remember. The -S flag (a capital S, for session name) lets you name a session when you start it. screen -S backup starts a session called backup, and from then on it shows up by that name in screen -ls and you reattach with screen -r backup.
You cannot start a live session in the sandbox, but the -S command is a normal typed command, so practice the exact form you would use to start a named session for a backup job:
screen -S backup
prompt: student@linuxcamp:~$ answer: screen -S backup output: student@linuxcamp:~$ hint: Type screen, a space, dash capital S, a space, then the name: screen -S backup
Representative frame again: this really starts and enters a session on a live machine, clearing the terminal. The difference from bare screen is the label. In screen -ls this session shows as 12345.backup instead of 12345.pts-0.host, and you reattach to it by name with screen -r backup. Naming sessions is the habit that keeps a busy machine readable.
Scaffolding off. No command is printed this time. You have every piece you need.
You left a screen session attached on your office machine and went home. Now you connect from home and screen -r refuses, because the session still counts as attached over there. There is one move for this exact case: force screen to detach it from the other place AND reattach it here, in a single command. It combines the detach flag -d with the reattach flag -r you already know.
prompt: student@linuxcamp:~$ answer: screen -d -r output: student@linuxcamp:~$ hint: Combine two flags you know: detach elsewhere (-d) and reattach here (-r). Two dashes, two letters: screen -d -r
The command is screen -d -r. The -d detaches the session from wherever it is currently attached, and the -r reattaches it here in the same breath, so you take control from home without walking back to the office. Engineers reach for this constantly when a session is stuck attached to a connection that is long gone. You combined two flags from memory, which is exactly the recall the real machine will ask of you.
Three messages are worth recognising on sight, because each points at a different situation.
No Sockets found in /run/screen/S-student. This is not an error at all; it is screen -ls telling you no sessions are running yet. What to check first: nothing is wrong. If you expected a session, you either never started one or it already exited.
There is no screen to be resumed. You ran screen -r, but there is no detached session to reattach to. What to check first: run screen -ls. If it says No Sockets found, there is genuinely nothing to resume, so start a session first.
There are several suitable screens on: You ran screen -r with more than one session running, so screen cannot guess which one you mean and lists them all. What to check first: pick one from the list and name it, as in screen -r backup or screen -r 12345.
That last message trips up nearly everyone the first time they run two sessions. screen -r on its own only works when there is exactly ONE session to resume. The moment you have two, you must name the one you want. This is the single best reason to get into the habit of naming sessions with -S from the start.
You earned this cheat sheet. The top rows are commands you type at your prompt; the bottom rows are keystrokes you press inside a session.
The story that ties it together: screen to start, Ctrl-a d to detach and walk away, screen -r to return. That round trip is why a dropped connection can no longer kill your long-running work.
The prefix is Ctrl-a, and it is worth burning in: every in-session command begins with it. If a keystroke seems to do nothing, you almost certainly forgot the prefix. Press Ctrl-a first, release, then the command key.
The practice terminal has shown you the shape of screen. You listed sessions with -ls, started one bare or named with -S, learned the detach keystroke Ctrl-a d that makes it all worthwhile, and reattached with -r or -d -r. The shell-level commands you typed yourself; the key bindings you now carry in memory.
The Multiplexers module ends with one real Linux machine, the Multiplexers capstone mission. That is where you run screen for real: start a session, run something long inside it, detach, and reattach to find it still going. A VM boots just for you. It hands you objectives that use exactly what you practiced across this module. 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 detach a real session and watch it survive.
Practice screen in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.