screen gives a terminal session that survives after you disconnect. Start it with screen, run a long job, detach with Ctrl-a then d, and log out - the job keeps running. Reconnect later with screen -r and you are back where you left off, output and all. This is the answer to the oldest SSH problem there is: your connection drops mid-command and the process dies with it. Inside screen, the process is anchored to the session, not to your fragile network link.
Everyone who has run a long job over SSH has watched their laptop sleep, the connection drop, and a two-hour migration die at the 90-minute mark. screen exists so that never happens again.
Table of contents
- The three commands that cover most use
- Detaching, and why it is the whole point
- Reattaching when it says already attached
- Multiple windows inside one session
- screen versus tmux versus nohup
- How this fits the rest of the stack
- FAQ
The three commands that cover most use
You can be productive with screen knowing almost nothing:
screen # start a new session, you are now inside it
# run your long command here
# press Ctrl-a then d to detach - the session keeps running
screen -r # reattach to it laterCtrl-a is the command prefix - you press it, release, then press the next key. Ctrl-a d detaches. screen -r reattaches. That is the core loop: start, detach, reattach. The job runs the entire time, whether you are connected or not.
Name your sessions so you can tell them apart:
screen -S deploy # start a session named "deploy"
screen -r deploy # reattach to it by name
screen -ls # list all sessionsNaming matters the moment you have more than one session, and you will. screen -ls shows what is running and whether each is attached or detached.
Detaching, and why it is the whole point
Detaching is what separates screen from a normal terminal. When you detach with Ctrl-a d, the session and everything in it keep running in the background, disconnected from your terminal. You can close your laptop, drop off the VPN, or log out entirely, and the processes inside carry on.
This is the fix for the classic failure: running a database migration or a big rsync over SSH, and the connection dies. Without screen, the process gets a hangup signal and stops. Inside screen, it is attached to the screen session, which does not care that your SSH link died - it just becomes detached, waiting for you to come back.
Reattach from anywhere: another machine, a new SSH session, hours later. screen -r finds the session and reconnects your terminal to it, mid-output. The job never knew you were gone.
Reattaching when it says already attached
A common snag: you try screen -r and it says there is a session but it is (Attached). This happens when your last connection dropped without cleanly detaching - screen still thinks a terminal is attached.
Force it:
screen -r # normal reattach
screen -d -r # detach the old terminal, then attach here
screen -r -d deploy # same, for a named sessionscreen -d -r tells screen to detach whatever it thinks is attached and connect you instead. This is the fix for the maddening it says I am already attached but I am clearly not situation, which is just a stale attachment from a dropped connection.
If screen -ls shows a session as (Dead), clean it up with screen -wipe. Dead sessions are leftovers from crashes and cannot be reattached; wiping clears them from the list.
Multiple windows inside one session
screen is a terminal multiplexer, so one session can hold several windows - like tabs:
Ctrl-a c create a new window
Ctrl-a n next window
Ctrl-a p previous window
Ctrl-a " list windows, pick one
Ctrl-a A rename the current windowThis lets one detached session hold an editor, a running server, and a log tail at once - all surviving disconnection together. Reattach and your whole workspace is intact.
For most people the single-window detach-and-reattach loop is enough, and that is fine. But when you find yourself opening three SSH connections to the same box, one screen session with three windows is tidier and all three survive a dropped link. It is the difference between three fragile connections and one durable workspace.
screen versus tmux versus nohup
Three tools solve overlapping problems and it helps to know when each fits:
screen- session persistence plus windows. Installed or oneapt installaway almost everywhere. The dependable default.tmux- the modern alternative. More powerful splits, scriptable, nicer status bar, active development. If you are choosing fresh, many people picktmux. The concepts map directly: detach, reattach, windows.nohup- not a multiplexer at all.nohup long_command &just detaches one command from the terminal so a hangup does not kill it. No reattaching, no interaction - you get the output innohup.out. Fine for fire-and-forget; useless when you need to check back in.
Reach for screen or tmux when you need to come back to an interactive session; reach for nohup when you only need one command to outlive your logout and do not care about watching it. For a long interactive job over SSH, screen is the honest default.
How this fits the rest of the stack
screen is a workaround for running things on a box you SSH into by hand - which is exactly the work a deployment platform is meant to take off your plate. When a long job is a managed service or a scheduled task on the platform, its lifecycle is not tied to your laptop staying awake, and you watch it through logs instead of a fragile terminal. The RunxBuild hosting calculator lays out the service, database, storage, and bandwidth as separate line items, and the RunxBuild dashboard is where the team watches deploys, logs, and restarts as they happen.
Useful related references:
- Allow Chrome Through Your Firewall: Windows, macOS, and Linux
- Application Server vs Web Server: The Line People Keep Blurring
- The Best Linux Distro Is Boring: Picking a Server OS in 2026
- Services on RunxBuild
FAQ
What does the screen command do in Linux?
It creates a terminal session that keeps running after you disconnect. You start it with screen, run a command, detach with Ctrl-a d, and the session and its processes continue in the background. Reattach later with screen -r to pick up where you left off.
How do I detach and reattach a screen session?
Detach by pressing Ctrl-a then d - the session keeps running. Reattach with screen -r, or screen -r name for a named session. List sessions with screen -ls. The job runs the whole time whether you are attached or not.
Why does screen say I am already attached?
Your last connection dropped without cleanly detaching, so screen still thinks a terminal is attached. Run screen -d -r to detach that stale terminal and attach your current one. It is the fix for a session that looks attached after an SSH link died.
What is the difference between screen and tmux?
Both give persistent, reattachable terminal sessions with multiple windows. tmux is the more modern, more powerful, actively developed option with better splits and scripting; screen is older, simpler, and available almost everywhere. The core detach and reattach concepts map directly between them.
When should I use nohup instead of screen?
Use nohup command & when you just need one command to keep running after you log out and do not need to interact with it again - the output goes to nohup.out. Use screen or tmux when you need to reattach to an interactive session later.