The Danger of the Dropped Connection
When administering a Linux server via SSH, your terminal session is directly tied to the active network connection. This creates a critical vulnerability when executing long-running tasks.
If you connect to a production database server to run a complex SQL migration that takes four hours, and your laptop’s Wi-Fi drops for three seconds, the SSH connection is severed. The Linux kernel detects the broken pipe, sends a SIGHUP (Hangup) signal to your terminal session, and instantly kills the running migration script. A partially completed database migration can cause catastrophic data corruption.
To solve this, experienced Linux administrators never run critical tasks directly in an SSH shell. Instead, they use a terminal multiplexer like screen (or its modern alternative, tmux). The screen command creates a persistent, virtual terminal session that runs entirely in the background on the server. If your SSH connection drops, the screen session continues running safely. When you reconnect, you simply reattach to the session exactly where you left off.
Step 1: Starting a Screen Session
Before executing any long-running command (like an rsync backup, an apt upgrade, or a database dump), you must initialize a new screen session.
Simply type:
screenThe screen will clear, and you will be presented with a standard command prompt. However, you are now inside a virtual terminal. Any command executed here is insulated from your SSH connection.
To make management easier, especially if you plan to run multiple sessions, it is highly recommended to name your sessions using the -S flag:
screen -S database_migrationStep 2: Detaching from a Session
Once you start your long-running script inside the screen session, you don’t have to sit there and watch it. You can “detach” from the session, leaving it running safely in the background while returning to your original SSH shell.
To detach, you must use the keyboard shortcut sequence:
Press Ctrl + A, release both keys, then press d (for detach).
You will see a message in your terminal stating [detached from 12345.database_migration]. The script is now running safely in the background. You can safely close your laptop, drop your Wi-Fi, or log out of the server completely.
Step 3: Reattaching to a Session
When you reconnect to the server hours later and want to check on the progress of your migration, you must reattach to the session.
First, list the active screen sessions running on the server:
screen -lsThe output will show all detached sessions:
There are screens on:
12345.database_migration (Detached)
67890.nightly_backup (Detached)To reattach to a specific session, use the -r (resume) flag followed by the session name or PID:
screen -r database_migrationYour terminal will instantly snap back into the virtual shell, displaying the exact output and progress of your script exactly as it stands.
Step 4: Handling “Attached” Sessions
Occasionally, your SSH connection will crash violently while you are actively viewing a screen session. Because the SSH connection didn’t close gracefully, screen still thinks you are attached.
If you log back in and run screen -ls, the session will show as (Attached). If you try to run screen -r, it will refuse to connect, stating that someone else is viewing it.
To forcefully detach the ghost connection and reattach your current terminal to it, use the -d -r (detach and resume) combination:
screen -d -r database_migrationStep 5: Terminating a Screen Session
When your task is complete, you should close the virtual terminal to free up system resources.
If you are currently attached to the session, simply type exit or press Ctrl + D at the prompt. The terminal will output [screen is terminating] and return you to your main SSH shell.
If you want to forcefully kill a detached session from the outside (for example, if the script inside it is completely frozen), you can use the -X flag to send a quit command to the specific session:
screen -S database_migration -X quitConclusion
The screen command is an absolute necessity for anyone managing remote Linux servers. By insulating critical, long-running processes from the inherent instability of network connections, administrators eliminate the risk of accidental SIGHUP terminations, ensuring that complex migrations and backups complete successfully regardless of local connectivity issues.