screen Command in Linux: Terminal Multiplexer Guide

Quick take: screen is a terminal multiplexer that lets you run sessions that persist after SSH disconnects. Start with screen or screen -S name, detach with Ctrl+A D, reattach with screen -r. Create new windows with Ctrl+A C, switch between them with Ctrl+A N.

Introduction

The most frustrating thing that can happen during a long-running server task — a database migration, a large file transfer, a build that takes hours — is losing your SSH connection halfway through and having no idea whether your process survived. Before terminal multiplexers, this was a real and regular problem. You would come back to a dead terminal, no output, and no way to know if the job finished, failed, or was still running somewhere in the background.

screen solves this completely. It creates a session that runs on the server independently of any SSH connection. You start screen, run your command inside it, detach (the session keeps running), disconnect your SSH, reconnect hours or days later, and reattach to find your command still running — or finished with its full output history intact. This single capability — persistent sessions that survive disconnects — is why screen has been a staple of server administration for decades.

Screen also gives you multiple windows within a single SSH connection, the ability to split the terminal into regions, session sharing between users, and a scrollback buffer that lets you read output that has already scrolled off the screen. For anyone who manages Linux servers, screen (or its modern counterpart tmux) is an essential daily tool.

Installing screen

screen is pre-installed on many distributions. If it is missing:

# Debian, Ubuntu
sudo apt install screen

# RHEL, CentOS, AlmaLinux, Rocky Linux
sudo dnf install screen

# Arch Linux
sudo pacman -S screen

Verify installation:

screen --version

Syntax

The basic syntax of the screen command:

screen [OPTIONS] [COMMAND [ARGS]]

When called with no arguments, screen starts a new unnamed session with an interactive shell. When called with a command, it starts a session that runs that command and exits when the command finishes.

Starting a Session

The simplest way to start screen is to just type screen and press Enter. You will see a brief startup message (press space or enter to dismiss it), and then you will be in a new shell that looks exactly like your regular terminal. The difference is that this shell is now inside a screen session managed by the server — not tied to your SSH connection.

# Start a new unnamed session
screen

# Start a session with a descriptive name (recommended)
screen -S migration

# Start a session and immediately run a command
screen -S backup bash -c 'rsync -avz /data/ /backup/ > /tmp/backup.log 2>&1'

# Start a session in detached mode (it runs but you are not attached yet)
screen -d -m -S myjob ./long-running-script.sh

Naming your sessions with -S is a habit worth building from the start. On a server where you have multiple simultaneous screen sessions running — one for a database migration, one for a log watch, one for an interactive shell — descriptive names make it immediately clear which session is which when you run screen -ls.

Detaching and Reattaching

Detaching is the core workflow of screen. You press a key combination that tells screen to put the session in the background and return you to your normal terminal, leaving everything inside the session running:

# While inside a screen session, detach:
# Press Ctrl+A, then D (hold Ctrl, press A, release both, press D)

After detaching you will see a message like [detached from 12345.migration] and you are back at your regular prompt. The session is still running on the server. You can close your SSH connection entirely and the session persists.

To come back to it:

# List all screen sessions
screen -ls

# Example output:
# There are screens on:
#     12345.migration   (06/21/26 14:30:01)   (Detached)
#     12346.backup      (06/21/26 14:28:15)   (Detached)

# Reattach to a specific named session
screen -r migration

# Reattach by PID
screen -r 12345

# Reattach to the only session if there is just one
screen -r

If your SSH connection dropped unexpectedly without a clean detach — a network blip, a laptop lid close, a VPN timeout — the session may still show as (Attached) even though nobody is actually attached. Use -d -r to forcefully detach any existing attachment and reattach:

# Detach any lingering attachment and reattach
screen -d -r migration

Window Management

Within a screen session you can have multiple windows — each an independent shell. This is useful when you want to run a command in one window and monitor logs in another, all within the same screen session and accessible with a single reattach:

# All window commands start with the escape key: Ctrl+A
# Then press the second key

# Create a new window
Ctrl+A C

# List all windows and select one
Ctrl+A "

# Go to the next window
Ctrl+A N

# Go to the previous window
Ctrl+A P

# Jump directly to window by number (0-9)
Ctrl+A 0
Ctrl+A 1

# Show window list in status bar
Ctrl+A W

# Rename the current window
Ctrl+A A   (type new name, press Enter)

The window list shows you a numbered list of all open windows. When you create a new window, it starts at the next available number. Windows are persistent — they live for the lifetime of the session, even when you are not looking at them. A command running in window 1 continues while you are browsing logs in window 2.

Key Bindings Reference

All screen commands start with the escape prefix Ctrl+A. After pressing Ctrl+A, release both keys and press the command key:

Common Options and Flags

Practical Examples

The scenarios where screen saves you most in real infrastructure work:

# Run a database migration that takes 30+ minutes
screen -S dbmigration
./migrate.sh --env production
# Press Ctrl+A D to detach. Come back whenever to check progress.

# Watch a deployment in one window, tail logs in another
screen -S deploy
# Window 0: run the deploy
./deploy.sh
# Ctrl+A C (new window)
# Window 1: tail the application logs
tail -f /var/log/app/app.log
# Ctrl+A N to switch between them

# Start a long rsync in a detached session immediately
screen -d -m -S rsync-job rsync -avz --progress /data/ user@backup-server:/data/

# Log all output to a file
screen -L -S build
make -j4
# Output goes to screenlog.0 in your home directory

# Run a command and stay in screen if it fails, exit if it succeeds
screen -S test bash -c './run_tests.sh || exec bash'

# Send a command to a running session from outside
screen -S migration -X stuff "echo checking in\n"

The -d -m pattern is particularly useful in deployment scripts. You can fire off a background job in a screen session from a script that itself finishes immediately, and the job continues independently. This is an alternative to nohup for situations where you want to be able to reattach and see the output interactively later.

Scrollback and Copy Mode

One annoyance with terminal sessions is that output that has scrolled off the screen is gone — the terminal emulator's scroll buffer is separate from the server session. Screen has its own scrollback buffer that persists for the lifetime of the session, accessible via copy mode:

# Enter copy/scrollback mode
Ctrl+A [   (or Ctrl+A Esc)

# Inside copy mode:
# Arrow keys or j/k  - scroll line by line
# Page Up / Page Down - scroll one page at a time
# / (slash)          - search forward in buffer
# ? (question mark)  - search backward
# Space              - mark start of selection
# Space again        - mark end, copy to buffer
# Escape or q        - exit copy mode without copying

# Paste what you copied
Ctrl+A ]

The default scrollback buffer is 100 lines, which is not much for verbose commands. You can increase it significantly in your .screenrc:

defscrollback 10000

With 10,000 lines of scrollback, you can review the entire output of most build or migration runs after they complete, even if you were not watching in real time.

Sharing Sessions Between Users

screen supports multi-user mode, where multiple people can attach to and see the same session simultaneously. This is useful for pair debugging or for walking a colleague through a server configuration:

# Enable multi-user mode from within a screen session
Ctrl+A : multiuser on

# Add a specific user (they must have a system account)
Ctrl+A : acladd colleague

# The other user attaches with:
screen -x yourusername/sessionname

Both users see the same terminal in real time. This is not a frequently-used feature in daily work, but when you need remote pair programming or live troubleshooting with a colleague, it is invaluable — no screen-sharing software required, just SSH and screen.

Configuring screen with .screenrc

The ~/.screenrc file configures screen behaviour for all sessions. A practical configuration that improves the default experience:

# ~/.screenrc

# Large scrollback buffer
defscrollback 10000

# Disable the startup message
startup_message off

# Add a status bar at the bottom
hardstatus alwayslastline
hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %d/%m/%Y %{W}%c %{g}]'

# Use 256 colours
term screen-256color

# Enable mouse scrolling
mousetrack on

# Shorten the escape key to Ctrl+A (default, but explicit)
escape ^Aa

The status bar configuration shows your hostname, all open windows with the active one highlighted, and the current date and time. This makes it easy to know which machine you are on and which window you are in, especially when managing multiple servers simultaneously.

screen vs tmux

Both screen and tmux are terminal multiplexers with overlapping capabilities. Here is an honest comparison based on daily use:

screen wins on availability. It is installed by default on RHEL, CentOS, and many minimal server images where tmux is not. If you are logging into a client's server for the first time and need a multiplexer without installing anything, screen is usually there. Its configuration syntax, while dated, is well-documented and stable across versions going back decades.

tmux wins on usability. Its key-binding design is more consistent, its status bar is easier to configure, pane splitting is more intuitive (tmux uses % and " for split; screen uses S and |), and it handles terminal resizing better. tmux also has a cleaner session/window/pane hierarchy that is easier to reason about. If you are installing a multiplexer on a new system where you have package access, tmux is generally the better choice for new users.

In practice, I keep both installed. I use screen on servers where it is pre-installed and I do not want to install additional packages. I use tmux on my own development machines and servers where I have full control of the package list. Knowing both means you are never without a multiplexer.

Common Mistakes

The most common mistake is starting screen after already starting a long-running command. If you forget to start screen first and your command is already running, you cannot move it into a screen session retroactively — unless you use a tool like reptyr. The habit to build is: before running any command that might take more than a few minutes on a remote server, start screen first.

Another common issue is orphaned sessions. If you forget to detach cleanly (you just closed the SSH window), the session might show as Attached but with no real terminal attached. Run screen -d -r sessionname to forcefully detach the phantom attachment and reattach cleanly. Run screen -wipe to clean up dead sessions from the list.

A subtler mistake is nesting screen sessions — starting screen inside a screen session. This leads to key-binding conflicts (the inner screen also uses Ctrl+A) and confusion about which session you are actually in. If you must nest them, use a different escape key for the inner session: screen -e '^Bb' uses Ctrl+B as the escape key for the inner session.

Tips and Best Practices

• Always name your sessions with screen -S name — unnamed sessions are hard to identify when you have several running.
• Add startup_message off and a scrollback value of at least defscrollback 5000 to your ~/.screenrc to improve the default experience immediately.
• Before running any migration, backup, or deployment on a remote server, start a named screen session first — this takes three seconds and can save hours.
• Run screen -ls periodically to check for forgotten sessions and clean them up. Old detached sessions consume memory.
• Use screen -L (logging) when running commands whose full output you want to review later, especially builds and migrations.
• If you accidentally hit Ctrl+A then a wrong key, press Ctrl+A again to send a literal Ctrl+A to the terminal (for applications that need it).
• On shared servers, name sessions with your username prefix to avoid confusion: screen -S irfan-migration.

Final Thoughts

screen is one of the oldest tools in the Linux server administration toolkit, but it remains genuinely essential. The ability to start a job, detach, close your laptop, and come back to it later is not a nice-to-have — it is a fundamental reliability guarantee for any work done over an SSH connection. Network connections fail, laptops sleep, time zones differ, and jobs take longer than expected. Screen handles all of these gracefully.

If you work on remote servers regularly, the investment in learning screen (or tmux) pays back immediately and continuously. The key bindings take an hour to get used to, the session persistence model becomes second nature within a day, and after that it becomes hard to imagine working without it. Start with the three essential commands — screen -S name, Ctrl+A D to detach, screen -r name to reattach — and build from there.

Beyond persistence, screen also changes how you think about remote work. Instead of a single terminal session representing the entire state of your work on a server, you maintain a collection of named screen sessions for ongoing tasks — one for monitoring, one for active development, one for log watching. You drop in, do what you need, detach, and leave the sessions exactly as you found them. This workflow is especially effective when managing servers across time zones, where a task started in the morning in Saudi Arabia might need to be checked by a colleague in Europe hours later, or by a client in the USA the following morning. The screen session bridges those gaps seamlessly — no restart, no lost output, no wondering whether the job finished.