Guide VPS & Servers

How to keep a job running after you disconnect

How screen and tmux keep a command running on your VPS after you disconnect, and the handful of shortcuts you actually need to use them.

iFastHosting Support Team Updated 26 August 2026 7 min read Beginner

Close an SSH connection and every command it was running dies with it, including a long file transfer, a database import, or a build that was three-quarters finished. screen and tmux both solve this the same way: they run your terminal session inside a program that keeps going on the server regardless of whether you are still connected, so you can disconnect, reconnect from a completely different location, and pick the session back up exactly where you left it.

Either tool solves the same problem. Use whichever is already installed on a given server; if neither is, tmux is the more actively developed of the two and a reasonable default choice for a new install.

screen

sudo apt install screen -y      # Ubuntu / Debian
sudo dnf install screen -y      # RHEL / Rocky / AlmaLinux

Start a named session:

screen -S mytask

Run whatever long-running command you need inside it, exactly as you would in a normal terminal. When you need to step away, detach without ending it:

Ctrl+A, then D

You are back at your normal shell, and the session — with the command still running inside it — continues in the background. List what is currently running:

screen -ls

Reattach to it later, from the same connection or a completely different one:

screen -r mytask

If a session shows as "Attached" when you try to reattach — usually left over from a connection that dropped without cleanly detaching — force it:

screen -d -r mytask

tmux

sudo apt install tmux -y      # Ubuntu / Debian
sudo dnf install tmux -y      # RHEL / Rocky / AlmaLinux

Start a named session:

tmux new -s mytask

Detach with a different key combination than screen's:

Ctrl+B, then D

List sessions:

tmux ls

Reattach:

tmux attach -t mytask

Splitting the screen into panes

Both tools support running several things side by side in one session — genuinely useful for watching a log in one pane while working in another. In tmux, from inside a session:

Ctrl+B, then %    # split vertically
Ctrl+B, then "    # split horizontally
Ctrl+B, then arrow key   # move between panes

In screen, the equivalent is Ctrl+A then | for a vertical split, and Tab to move between panes.

	screen	tmux
Start named session	`screen -S name`	`tmux new -s name`
Detach	`Ctrl+A`, `D`	`Ctrl+B`, `D`
List sessions	`screen -ls`	`tmux ls`
Reattach	`screen -r name`	`tmux attach -t name`
Kill a session from inside	`exit` in every pane	`exit` in every pane, or `Ctrl+B`, `&`

Scrolling back through output

Neither tool behaves like a normal terminal window when it comes to scrolling — your mouse wheel or terminal's own scrollback often will not work as expected inside a session, which catches people out the first time they need to check something that scrolled past. Both have their own copy mode instead:

# tmux
Ctrl+B, then [       # enter copy mode, then use arrow keys or Page Up
q                    # exit copy mode

# screen
Ctrl+A, then Esc     # enter copy mode
q                    # exit copy mode

A minimal tmux config worth having

tmux reads ~/.tmux.conf on startup, and a couple of small changes make it noticeably more comfortable without needing to learn its full configuration language:

echo 'set -g mouse on' >> ~/.tmux.conf
echo 'set -g history-limit 10000' >> ~/.tmux.conf

mouse on re-enables normal mouse scrolling and pane selection inside tmux, which resolves the scrollback confusion above for most everyday use. history-limit increases how many lines of output tmux keeps, which matters if you are watching something that produces a lot of text and want to scroll back further than the default allows. Changes to ~/.tmux.conf take effect the next time you start tmux, or immediately in an existing session by reloading it:

tmux source-file ~/.tmux.conf

Troubleshooting: when a session does not behave as expected

What you see	Likely cause	What to do
`screen -r` says "There is no screen to be resumed"	The session already ended — the command inside it finished, or the session was killed rather than detached	Run `screen -ls` to confirm nothing is listed, then start a new session; the previous output is gone once a session ends
Pressing the detach key combination does nothing	You are inside a nested session (screen or tmux running inside another), so the outer session intercepts the key combination first	Send the key combination twice — once for the outer session, once for the inner one — or use a different prefix key for the nested session
The command still died when the connection dropped	The command was started in a normal terminal before entering screen or tmux, or was started outside the session by mistake	Start the session first, confirm the prompt shows you are inside it, then run the command — not the other way around
The display looks garbled or misaligned after reattaching	The terminal window is a different size than it was when you detached	Resize the terminal to roughly match, or run `clear` and, in tmux, `Ctrl+B` then `:` and type `resize-window`
"Duplicate session name" when starting a new one	A session with that name is already running, possibly one you forgot about	List existing sessions first and reuse or rename as needed, rather than guessing at a name that might already be taken

When you actually need this

A database import or export that takes longer than you want to stay connected for.
A large file transfer or compression job over a slow or unreliable connection, where the SSH session itself might drop.
Compiling something from source that takes more than a few minutes.
Any command you want to keep an eye on periodically without holding a dedicated terminal open the whole time.

This is not a substitute for a proper background service

For something that should run indefinitely and restart automatically after a crash or a reboot — a web application server, for example — use a systemd service instead of leaving it running inside a screen or tmux session. These tools are for a task with a beginning and an end that you want to survive a disconnection, not a permanent process.

For anything you want to run on a fixed schedule instead of manually watching, cron is usually the better tool — screen and tmux are for a job you are actively supervising, at least on and off, rather than one running unattended on a timer.

Frequently asked questions

What happens to my session if the server itself reboots?

It is lost. screen and tmux keep a session alive across a dropped SSH connection, but the session is a process running on the server itself — if the server restarts, every process on it, including screen and tmux sessions, ends along with it. For something that needs to survive a reboot automatically, use a systemd service instead.

Can I have more than one window inside a single session?

Yes, and this is different from splitting into panes. In tmux, Ctrl+B then C creates a new window within the same session, and Ctrl+B then a number switches between them. In screen, Ctrl+A then C creates a new window, and Ctrl+A then N moves to the next one. Panes split one window into visible sections; windows are separate full-screen views within the same session.

Is there a limit to how many sessions I can run at once?

Not one imposed by screen or tmux themselves — the practical limit is your server's own memory and CPU, and your own ability to keep track of what each session is doing. Naming sessions descriptively when you create them makes this far easier to manage once you have more than one or two running.