How to Keep Long-Running Commands Alive Over SSH With tmux and screen (September 2026)

I have lost count of how many times I have kicked off a 4-hour database migration over SSH, closed my laptop lid, and come back to find the process gone. The terminal multiplexer is the fix. In this guide I will show you exactly how to keep your SSH session alive with tmux and screen so that long-running commands survive every disconnect, dropped Wi-Fi connection, and accidental terminal close.

If you regularly run builds, backups, model training jobs, or anything that takes longer than a coffee break on a remote server, this is the single most useful habit you can build. Let us walk through it step by step.

What Happens When Your SSH Session Disconnects?

Every time your SSH connection drops, the kernel sends a signal called SIGHUP (Signal Hang UP) to every process attached to the terminal. This signal tells running programs that the controlling terminal has gone away, and by default they exit.

This is why a process that ran perfectly fine for 3 hours suddenly vanishes when your Wi-Fi hiccups. It is not a bug. It is the default Unix behavior, designed back when terminals were physical devices that could literally hang up.

The SIGHUP signal explained

SIGHUP is a POSIX signal (number 1) originally tied to the hang-up of a modem or serial line. When the SSH daemon detects the connection has ended, it forwards SIGHUP to the login shell, which then propagates the signal to every child process. Unless a program explicitly traps or ignores SIGHUP, it terminates immediately.

Why background processes also die

You might think appending an ampersand (&) to your command protects it. It does not, by itself. Background jobs started from an interactive SSH shell are members of the same session and still receive SIGHUP. Even nohup, which does shield a process from SIGHUP, does not give you an interactive shell to monitor progress, scroll back through output, or attach to the job later.

What terminal multiplexers solve

tmux and screen create their own server process that detaches from the SSH login shell. They run as long-lived child processes of init (or systemd) once the parent SSH session ends. Inside that server, your shell and every command you launch live on, completely insulated from the death of the SSH session. When you reconnect, you simply reattach and everything looks exactly as you left it.

What Are tmux and screen (Terminal Multiplexers)?

A terminal multiplexer is a program that lets you create, switch between, and persist multiple terminal sessions inside a single window or connection. The two most common ones on Linux are tmux and GNU screen.

They both solve the same core problem: keeping your work alive across disconnections. They just differ in age, defaults, and feature set.

Definition and history

GNU screen was first released in 1987. It predates Linux itself and was built for the era of dial-up terminals. tmux appeared in 2007 and was written from scratch with a cleaner architecture, scriptable configuration, and modern status bar support. Both are still maintained today and ship by default on nearly every Linux distribution.

Core concepts: session, window, pane

Both tools use a layered model. A session is a container that survives your SSH connection. Inside it, windows act like tabs. Inside windows, panes act like split regions of that tab. tmux calls this session > window > pane. screen uses session > window > region, but the mental model is identical.

This nesting lets you run, for example, a build in one pane, tail a log file in another, and run a database shell in a third, all within one SSH session and all surviving disconnect.

Why both tools exist?

screen is older, smaller, and present on virtually every Unix system including embedded ones. tmux is more actively developed, easier to script, and offers better defaults for new users. Knowing both makes you flexible on any server you log into.

Installing tmux and screen on Linux

Both tools are usually already installed on most servers, but here are the commands in case you need them.

Debian, Ubuntu, Linux Mint, Pop!_OS:

sudo apt update
sudo apt install tmux screen

RHEL, CentOS, Fedora, Rocky, AlmaLinux:

sudo dnf install tmux screen

Arch Linux, Manjaro:

sudo pacman -S tmux screen

macOS (Homebrew):

brew install tmux screen

You can verify the install with tmux -V and screen -v. If you get a version number back, you are good to go.

How to Keep SSH Session Alive With tmux: Step-by-Step

Here is the exact workflow I use every day. Follow these five steps and your commands will outlive any SSH disconnect.

Step 1: SSH in and start a named tmux session

Once you are connected to the remote server, run a single command. The -s flag gives the session a friendly name so you can find it later.

tmux new -s mybuild

Your terminal will clear and you will see a green status bar at the bottom showing [mybuild]. You are now inside a tmux session.

Step 2: Run your long-running command

Start whatever needs to keep running. A model training job, an rsync, a database migration, a build. Output streams live into the tmux window.

python train.py --epochs 50

Step 3: Detach from the session

Press the tmux prefix key Ctrl+b, release both keys, then press d. You will see [detached (from session mybuild)] and return to a normal shell prompt. Your command is still running.

Step 4: Close SSH or lose connection freely

You can now run exit, close your terminal, shut your laptop, or lose Wi-Fi. Nothing inside the tmux session cares. The job keeps running on the server.

Step 5: Reattach when you return

SSH back into the server and run:

tmux attach -t mybuild

You will land right back where you left off, with the full scrollback buffer, command output, and cursor position preserved. If you have multiple sessions, use tmux ls to list them first, then attach with -t and the correct name.

How to Keep SSH Session Alive With screen: Step-by-Step

The flow is identical, only the prefix key and command names change. The screen prefix is Ctrl+a instead of Ctrl+b.

Step 1: Start a named screen session

screen -S mybackup

You will get a brief license welcome. Hit Enter to clear it. The status line is hidden by default in screen, which trips up many beginners.

Step 2: Run your command

tar -czvf backup-$(date +%F).tar.gz /var/www

Step 3: Detach with Ctrl+a d

Hold Ctrl, press a, release, then press d. screen prints [detached from mybackup].

Step 4: Disconnect safely

Same as tmux. Exit SSH, close the laptop, do whatever. The process keeps running because it lives inside the screen server, not inside your SSH session.

Step 5: Reattach

screen -r mybackup

You land back in the session. If the session is listed as (Attached), someone else or another terminal is already in it. Use screen -x mybackup to share the session between multiple windows instead of stealing it.

tmux vs screen: Which Should You Use?

Honest answer: for keeping SSH sessions alive, both work perfectly. Here is how they differ on the dimensions that matter most to beginners.

Feature comparison

• Default prefix key: tmux uses Ctrl+b; screen uses Ctrl+a (which collides with the shell’s jump-to-start-of-line shortcut).

• Status bar: tmux shows a visible bar by default; screen hides it.

• Pane splitting: tmux splits are easier and more discoverable; screen supports splits but with rougher defaults.

• Scripting and config: tmux has a cleaner config file at ~/.tmux.conf; tmux is generally easier to automate.

• Availability: screen ships on more obscure Unix systems; tmux is on most Linux and BSD distributions.

• Active development: tmux is more actively maintained and releases more often.

When to pick tmux

Pick tmux if you are starting fresh, want a visible status bar, need pane splits, or plan to customize your environment with a config file. It is the modern default and what most current tutorials assume.

When to pick screen

Pick screen if you are working on a minimal or legacy server where tmux is not installed, or if you are writing portable shell scripts that must work on any Unix box. screen’s small footprint and universal presence still make it the safer bet in shell automation.

Managing Multiple Sessions and Naming Conventions

Once you start using a multiplexer daily, you will end up with several sessions running at once. Naming them up front saves a lot of confusion later.

Naming your sessions

Pick names that describe the work, not the date. Good examples: db-migration, model-train-v3, logs-prod. Bad examples: tmux1, foo, test. A descriptive name tells you, three days later, exactly what each session is for.

Listing active sessions

For tmux:

tmux ls

For screen:

screen -ls

Both commands show session names, IDs, and creation dates. That output is the single source of truth when you have to figure out which one to reattach.

Killing and cleaning up

To kill a tmux session from outside:

tmux kill-session -t mybuild

To kill a screen session:

screen -X -S mybackup quit

You can also kill them from inside by typing exit at the shell prompt inside the session. Whichever way you choose, get into the habit of cleaning up finished sessions so the listing stays useful.

Common Beginner Mistakes to Avoid

These are the errors I see new administrators make repeatedly, and that forum threads about SSH and tmux are full of. Avoid them and you will save yourself hours.

Starting tmux AFTER the command

The single most common mistake. Once you have already launched a long job without a multiplexer, it is too late to put it inside one. Always start the session first, then run the command. If you forgot, you can still use disown or nohup, but you lose the interactive scrollback and reattach benefit.

Closing the terminal instead of detaching

If you just close the terminal window or type exit at the SSH shell prompt while still inside a tmux or screen session, that command also kills the multiplexer and everything in it. Always detach first with the prefix key shortcut, then exit the SSH shell as a separate step.

Sessions do not survive server reboots

Both tmux and screen survive SSH disconnects, lost connections, and closed laptops. Neither survives a server reboot or power loss, because the multiplexer process itself is killed when the OS shuts down. For true persistence across reboots, you need a process manager like systemd, supervisord, or a job scheduler.

Forgetting which session to reattach

Run tmux ls or screen -ls before you attach. Picking the wrong session can leave you confused about which project you are even looking at, especially if all your sessions default to a generic prompt. This is why naming matters.

Quick Reference Cheat Sheet

Bookmark this section. These are the only commands you need 95% of the time.

tmux essentials

tmux new -s name          # start named session
tmux ls                   # list sessions
tmux attach -t name       # reattach to session
tmux kill-session -t name # kill a session
Ctrl+b d                  # detach from inside
exit                      # close the session from inside

screen essentials

screen -S name             # start named session
screen -ls                 # list sessions
screen -r name             # reattach to session
screen -x name             # share an attached session
screen -X -S name quit     # kill a session
Ctrl+a d                   # detach from inside
exit                       # close the session from inside

Shortcut key reference

• tmux prefix: Ctrl+b, then the command key.

• screen prefix: Ctrl+a, then the command key.

• Detach: prefix + d in both.

• List sessions from inside: prefix + s (tmux switcher) or Ctrl+a " (screen window list).

• New window: prefix + c (tmux), prefix + c (screen).

• Split horizontally: prefix + % (tmux), prefix + S (screen).

• Split vertically: prefix + ” (tmux), prefix + | (screen).

Frequently Asked Questions

Wrapping Up: Keep Your SSH Work Alive

Keeping an SSH session alive with tmux or screen is one of those tiny habits that pays off for the rest of your career. Start the session, run the command, detach, walk away. Reattach later as if nothing ever happened.

If you are new to this, install tmux today, run a small test like tmux new -s test, then Ctrl+b d, then tmux attach -t test. Once that round trip clicks, you will never go back to losing hours of work to a dropped connection again.