You launch an update, a backup, or a long command via SSH, and then the connection drops. If the command was running in a regular terminal, it’s often over. Screen under Linux This avoids precisely this kind of unpleasant surprise: the session remains active on the server side, even if your local terminal disappears.
I mainly use it for simple tasks where I want to maintain control without creating a complex system. It’s not as convenient as tmux for working all day in multiple panels, but for detaching and resuming an admin command, screen still does the job very well.
Install screen if the command is not available
On many servers, screen is not installed by default. Check first:
screen --versionIf the command is missing, install the package using your distribution’s package manager.
sudo apt update
sudo apt install screensudo dnf install screensudo pacman -S screenBefore launching a sensitive operation, open a stable SSH session and, if possible, maintain a secondary backup connection. Screen mitigates the damage when your terminal crashes, but it doesn’t replace an emergency console if you lose your network or SSH connection.
Create a screen session named
Avoid anonymous sessions. With a clear name, you’ll immediately know what’s still running on the server.
screen -S saveYou will arrive in a new terminal. From there, run your command as usual. For example:
The important point: this command runs within the screen session, not directly in your SSH terminal. If your computer goes to sleep or your connection drops, the screen session can continue on the server side.
Detach the session without stopping the command
To exit the screen session without stopping what’s running within it, use the following shortcut:
Ctrl+HAS- Then
D
Screen usually displays a message like this You then return to your normal shell. The command launched in screen continues to run.
Be careful not to hit exit if you only want to detach the session. exit Close the shell in screen. If it was the last active window, the session ends.
List and resume a screen session
To view existing sessions:
screen -lsYou can then resume the session by name:
screen -r saveIf only one session exists, screen -r Often that’s enough. On a shared server or a machine where you’re running multiple tasks, I prefer to use the name. It’s less risky than resuming the wrong session at the wrong time.
If the screen indicates that the session is still attached elsewhere, for example after a poorly detected SSH disconnection, use:
screen -d -r backupThis option first disconnects the old connection, then reconnects the session in your current terminal. It’s convenient, but use it with caution on a shared account: you could disconnect someone who was actually working in that session.
Follow the same session from two terminals
In some cases, you may want to view the same session from two devices. For example, one console open on a monitor and another on your laptop.
screen -x saveBoth terminals then share the same session. Everyone sees the same thing and types in the same shell. This is useful for a guided intervention, much less so if two people are writing at the same time without coordinating.
Properly closing a screen session
When the command is complete, exit the shell opened in screen:
exitYou can also use Ctrl + DOnce the last window is closed, the screen session disappears from the list.
To force the termination of a named session from outside the network, use:
screen -S save -X quitBe sure of your choice. This command closes the screen session and whatever is running within it. When performing a backup, migration, or update, I always prefer to resume the session, check the actual state, and only stop if necessary.
Common pitfalls in administration
The first trap is rootIf you launch sudo screenThe session belongs to root. You will therefore often need to resume it with sudo screen -rIn most cases, I prefer to launch screen with my normal user, then use sudo only for orders that require it.
The second pitfall is confusing `screen` with a service manager. A command running in `screen` remains tied to an interactive session. For a persistent service, a daemon, or a scheduled task, use systemd, a timer, or a dedicated service instead. (See the article on…) systemd timers is more suited to this type of need.
The third pitfall is using a command without a log. If you’re running an important task, redirect the output to a file or use a logging tool. You can then monitor the results with tail under Linux.
./script-maintenance.sh > maintenance.log 2>&1You can then detach the screen, come back later, and reread what happened even if the display scrolled too quickly.
Screen, nohup or tmux: which one to choose?
For a non-interactive command that simply needs to continue after SSH closes, nohup That may be enough. You run the command, you retrieve the output in a file, and you don’t need to use an interface.
For a proper work session with multiple windows, panels, a more modern layout, and better ergonomics, tmux is often more pleasant. But on a minimal server, screen remains available, simple, and very efficient. For a short intervention, I don’t bother with anything else. screen -S nameI launch the command, I detach, then I come back to check.
The check to perform before closing SSH
Before closing your SSH session, take ten seconds to verify that screen correctly recognizes your session:
screen -lsIf your session appears as detached, you can exit SSH with greater peace of mind. If it doesn’t appear, don’t assume that `screen` is protecting your command. Return to the terminal, check where you launched the task, and correct it before closing the connection.
Documentation screen(1) and the GNU Screen manual detail all the options. For routine admin use, remember four commands in particular: create with screen -Sdetach with Ctrl + HAS Then D, resume with screen -rand check with screen -ls.