Mastering GNU Screen: How to Keep Your Terminal Sessions Alive During SSH Disconnects – ITFROMZERO

Table of Contents

The “Broken Pipe” Nightmare: Managing SSH Disconnects

If you frequently manage servers via SSH, you’ve likely experienced this: while compressing a 100GB log file or running a database migration with millions of records, the connection suddenly drops. The result is a “Broken pipe” error, and your process stops instantly. Hours of waiting down the drain.

In reality, internet drops or local power outages are unavoidable risks. To solve this once and for all, I always use GNU Screen as an “insurance policy” for critical tasks. This tool allows you to create independent sessions. Your processes will continue running in the background on the server even if you close the terminal window or get disconnected unexpectedly.

Installing GNU Screen in 30 Seconds

Most modern Linux distributions include Screen in their official repositories. Installation takes only a few seconds.

On Ubuntu or Debian:

sudo apt update && sudo apt install screen -y

On CentOS, AlmaLinux, or RHEL:

sudo dnf install screen -y

Once installed, type screen -v. If the version information appears, you’re ready to go.

Essential Screen Commands for DevOps

The biggest difference with Screen is its control key combination. Every action starts with Ctrl+a (the prefix key), followed by a function key.

1. Creating and Naming a Session

Don’t just type screen without context, as it will be hard to distinguish sessions later. Give it a name related to the task:

screen -S update_system

Now you are inside a secure session. Suppose you start running yum update or a large rsync data transfer here.

2. Detaching and Reattaching Sessions

This is the most valuable feature. When you want to leave a script running and head to a cafe, press Ctrl+a then d. The screen will display [detached].

A few hours later, you log back into the server from a different computer. To check the list of running sessions, use:

screen -ls

To return to your previous session:

screen -r update_system

3. Managing Multiple Windows

Instead of creating separate sessions, you should create multiple windows within a single session for easier management:

Ctrl+a c: Create a new window (e.g., one for logs, one for commands).
Ctrl+a n: Quickly switch to the next window.
Ctrl+a “: Display a menu-style list of windows to choose from.

Customizing .screenrc for a Professional Terminal

The default Screen interface is quite plain and can make you forget which session you’re in. I usually add a status bar at the bottom for easier tracking.

Open the configuration file: nano ~/.screenrc and paste the following code:

startup_message off
hardstatus alwayslastline
hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %m/%d %{W}%c %{g}]'
defscrollback 10000

This configuration shows your hostname, active windows list, and the date/time at the bottom. Notably, the defscrollback 10000 line allows you to scroll up to view 10,000 lines of history.

Pro Tip: Debugging with Colleagues using screen -x

There is a fantastic feature many overlook: Multi-display. If you’re stuck on a difficult bug and need a colleague to take a look, both of you can log into the same user on the server. Your colleague just needs to type:

screen -x [session_name]

Immediately, both of you will share the same terminal screen. Whatever you type, they see, and vice versa. This is a highly effective way to do “pair programming” or mentor a newbie without needing third-party software.

Why Stick with Screen When Tmux Exists?

Many will recommend tmux because it’s more modern. However, Screen always has a place in my toolkit. The reason is simple: Screen is extremely lightweight and pre-installed on most legacy Linux systems or minimal installs. When dealing with “antique” client servers, Screen remains stable and reliable.

One final note: When running critical commands on production, always enable logging with Ctrl+a H. Everything appearing on the screen will be recorded in screenlog.0, providing evidence if issues arise.

Hopefully, this tip will help you manage servers more confidently, without worrying about internet connection stability.