The dropped connection scenario
You are halfway through a database migration or compiling a custom kernel module over SSH. The coffee shop Wi-Fi flickers. Your laptop lid closes. The terminal prints Connection to server.example.com closed by remote host. The process dies. You have to start over. This happens to everyone who works remotely. The fix is not better Wi-Fi. The fix is a terminal multiplexer.
What actually happens when SSH drops
SSH is a transport layer, not a process manager. When the network link breaks, the SSH daemon on the server sends a SIGHUP signal to the parent shell. The shell forwards that signal to every child process. Everything stops. A multiplexer like tmux or screen sits between your shell and the SSH transport. It creates a virtual terminal that lives independently of the network connection. Think of it as a persistent workspace pinned to the server. The network cable can be unplugged, the laptop can be closed, and the workspace stays exactly where you left it. When you reconnect, you are just plugging a new monitor into the same running machine.
The multiplexer runs as a background daemon on the server. It maintains a Unix socket in /tmp/ that listens for client connections. Your local terminal is just a client talking to that socket. The socket survives network drops because it lives in the server's filesystem, not in the SSH tunnel. This architecture is why tmux is the standard for remote administration on Fedora and RHEL systems.
Detach early. Let the process run while you grab coffee or switch networks.
Setting up tmux for persistent work
Fedora ships tmux in the base repositories. Install it if it is missing.
sudo dnf install tmux # WHY: pulls the latest stable release from Fedora's official repos
# WHY: verifies the package manager resolved dependencies correctly
Start a named session. Names make reconnection predictable.
tmux new -s deploy # WHY: creates a new virtual terminal named deploy
# WHY: attaches your current window to the newly created session
You are now inside the multiplexer. Run your long command.
tar -czf backup.tar.gz /var/www/html # WHY: archives the web root while tmux tracks the process
# WHY: keeps the shell prompt available for monitoring or interruption
Detach without killing the work. Press Ctrl+B, release both keys, then press D. The terminal returns to your local shell, but the session runs in the background.
# Press Ctrl+B then D to detach
# WHY: sends the detach command to the tmux server process
# WHY: leaves all child processes running in the background
Reconnect later.
tmux attach -t deploy # WHY: reattaches your local terminal to the existing background session
# WHY: restores the exact cursor position and scrollback buffer
Convention aside: tmux sessions are tied to your user ID. Root sessions are completely separate from user sessions. If you run sudo tmux new -s root-work, you must reattach with sudo tmux attach -t root-work. Mixing contexts causes confusion. Keep administrative work in a dedicated session.
Run tmux ls before you attach. Guessing session names wastes time.
Managing sessions and recovering from drops
Check what is running on the server.
tmux ls # WHY: lists all active sessions with their creation time and window count
# WHY: shows whether the session is attached or detached
# WHY: confirms the process survived the network interruption
If the output shows deploy: 1 windows (created Mon Oct 23 10:00:00 2023), your work survived the drop. You can create multiple windows inside one session using Ctrl+B then C. Each window gets its own shell. Switch between them with Ctrl+B then N for next or P for previous. The session persists across reboots only if you explicitly save it, but for daily remote work, the in-memory persistence is enough.
Copy-paste mode requires a specific sequence. tmux intercepts your mouse and keyboard to manage panes. To copy text, press Ctrl+B then [. Navigate with arrow keys. Press Space to mark the start. Move to the end. Press Enter to copy. Press q to exit copy mode. The text lands in your terminal's primary selection buffer. Paste with Shift+Insert or your terminal's middle-click binding.
tmux new-window -t deploy # WHY: opens a second shell inside the same session
# WHY: shares the same session lifecycle and network independence
# WHY: keeps related tasks grouped under one name
Convention aside: configuration files belong in ~/.tmux.conf. Never edit /usr/share/tmux/ or /etc/tmux.conf unless you are managing a fleet of servers. User-level config overrides system defaults safely. Add set -g default-terminal "screen-256color" to fix color rendering in older SSH clients. Add bind r source-file ~/.tmux.conf \; display "Reloaded" to reload config without detaching.
Snapshot your session state before major changes. Future-you will thank you.
Common pitfalls and error messages
Keybinding conflicts happen immediately. tmux uses Ctrl+B as the prefix. If you are used to screen, you expect Ctrl+A. You can change it, but stick to the default until you memorize it. Muscle memory beats configuration files.
Session not found errors appear when the background daemon dies or the name is wrong.
tmux: connect to server failed or no server running
This means the background daemon died. Start a new session. Do not force attach. Run tmux ls first to verify what actually exists.
Terminal type mismatch breaks colors and line editing. Some older SSH clients send TERM=xterm while tmux expects screen-256color. Fix it by adding set -g default-terminal "screen-256color" to ~/.tmux.conf. The multiplexer then advertises the correct capabilities to child programs.
Detached sessions consuming resources is a real risk. Long-running compiles or downloads will keep using CPU and disk. Check resource usage before you walk away.
tmux list-sessions -F '#{session_name} #{session_windows} #{session_created_string}' # WHY: formats output to show name, window count, and age
# WHY: helps identify stale sessions that should be killed
# WHY: prevents zombie processes from filling your disk
Kill abandoned sessions cleanly.
tmux kill-session -t old-work # WHY: terminates the session and all its child processes
# WHY: frees the server socket and releases allocated memory
# WHY: prevents orphaned processes from running indefinitely
Run tmux ls daily. Clean up what you do not need.
Choosing your terminal multiplexer
Use tmux when you want active development, modern keybindings, and plugin support via tpm. Use screen when you are maintaining legacy infrastructure that already has it installed and you cannot install new packages. Use mosh when you are on unstable mobile networks and need automatic reconnection with UDP. Use a raw SSH connection with ControlMaster when you only need connection multiplexing and do not care about persistent terminal state. Stay on the default tmux configuration until you hit a specific workflow bottleneck.