Why Terminal Session Persistence Matters
Imagine this: you SSH into your server to launch a data backup that takes a couple of hours. Halfway through, your internet connection drops — and with it, the SSH session. When you reconnect, the process is gone. You have to start all over again, wasting time and resources.
By default, the terminal session and any running processes are tightly coupled to your SSH connection. Once it closes, the shell exits, and any foreground (and sometimes background) jobs are terminated unless special steps were taken.
This behavior is a real pain point for developers, system administrators, and anyone managing remote Linux systems. Fortunately, there are tools designed to help you keep processes alive independently of your SSH connection. Two popular approaches are:
- disown: a shell command to disassociate a job from the current session.
- tmux: a full-featured terminal multiplexer that lets you detach and reattach to entire sessions.
In the next sections, we’ll take a closer look at how these tools work — and why tmux is usually the better long-term solution.
Understanding disown: Minimalist Lifeline
The disown command is a built-in feature of many shells like bash and zsh. It’s a way to prevent background jobs from being terminated when you log out or your SSH session disconnects.
How it works:
- Start a long-running command in the background:
some-command &- List the current jobs:
jobs
Use disown to remove the job from the shell’s job table:
disown %1Once disowned, the process keeps running even after you disconnect.
Pros:
- No need to install anything.
- Simple and fast for occasional use.
Cons:
- No way to reattach to the process’s output later.
- Easy to forget to use disown before disconnecting.
- No session management — if something breaks, you’re in the dark.
Enter tmux: Your Persistent Terminal Powerhouse
Pre-installed on some distros:
- Minimal server-focused distros (e.g., Ubuntu Server, CentOS minimal, Debian netinst) usually do not include it by default.
Easily installable:
On Ubuntu/Debian:
sudo apt install tmux
On Red Hat/CentOS/Fedora:
sudo dnf install tmux
On Arch Linux:
sudo pacman -S tmuxOn Mac OS (brew setup necessary):
brew install tmuxWhile tmux isn’t always pre-installed, it’s just one command away on almost every Linux system — making it a no-brainer for anyone managing long-lived shell tasks
- Start a new tmux session (name it e.g. rclone):
tmux new -s rclone- Detach from tmux (keep it running in background), press:
Ctrl-b d- Later: Resume the session (from any new/existing session!)
tmux attach -t rcloneUse-Case Comparison: disown vs tmux in Action
| Scenario | disown | tmux |
| Start a long backup and disconnect safely | ✅ Yes, if disown is used before logout. | ✅ Yes, and you can reattach anytime. |
| Check logs or output later | ❌ No way to view command output after disconnection. | ✅ Full scrollback and live output available. |
| Run multiple commands in parallel | ⚠️ Doable with background jobs, but hard to manage. | ✅ Multiple panes, windows, and sessions. |
| Reconnect after an accidental disconnect | ❌ Job might be lost if not disowned. | ✅ Reattach seamlessly and resume work. |
| Interactive tools (editors, htop, etc.) | ❌ Won’t survive logout or disconnection. | ✅ Perfectly supported — keep your editor open! |
| Scriptable and automatable | ❌ Very limited. | ✅ Can be scripted, logged, and configured. |
| Learning curve | ✅ Minimal. | ⚠️ Slightly steeper, but worth it. |
Verdict:
Use disown if you’re in a pinch and only need to run one quick command without sticking around.
Use tmux if you care about reliability, multitasking, or seeing what your session was doing when you reconnect.
Ready for tmux ?
In the long run, tmux becomes indispensable — like ssh, once you start using it, you wonder how you lived without it.
You must be logged in to post a comment.