When the connection drops and the work matters
You are SSHed into your Fedora server. You start a long database migration or a massive dnf upgrade. Your laptop lid closes, the Wi-Fi drops, or the coffee spills on the keyboard. The connection dies. You log back in. The process is gone. You have to start over. Or you are on a desktop, juggling three terminals, and you want to save that layout so you can pick it up tomorrow without hunting for windows. Terminal multiplexers solve both problems. They keep your sessions alive and your layouts intact, independent of the terminal emulator or network connection.
What's actually happening
A terminal multiplexer runs a server process in the background. Your terminal window connects to that server as a client. When you close the window, the client disconnects, but the server keeps running. You can open a new window and reconnect to the same server. Think of it like a persistent SSH session that lives inside your local machine. The multiplexer manages windows and panes, so you can split the screen and switch between tasks without Alt-Tabbing or managing multiple terminal windows.
tmux and screen are the two standard tools. tmux is the modern default on Fedora. screen is the legacy tool that exists everywhere, even on minimal rescue systems. Both tools run locally. Your firewall and SELinux policies do not interfere with local multiplexing. SELinux contexts for terminal sessions are well-defined, and tmux does not require special network permissions. If you are tunneling SSH, firewall-cmd applies to the SSH port, not the multiplexer.
Install and start tmux
Fedora ships tmux in the default repositories. Install it once and use it for every session that needs to survive a disconnect. Name your sessions from the start. Unnamed sessions get numeric IDs that are impossible to track when you have multiple jobs running.
# Install tmux from the standard Fedora repositories
sudo dnf install tmux
# Start a new session with a descriptive name
tmux new -s backup-job
# List active sessions to verify the server is running
tmux list-sessions
The -s flag assigns a name to the session. This name is how you find the session later. tmux list-sessions shows all running sessions, their names, and the number of windows in each. If you see backup-job: 1 windows, the server is up and waiting.
Detach before you close the terminal. Killing the window kills the client, not the server.
Manage windows and panes
Inside tmux, the prefix key is the gateway to all commands. The default prefix is Ctrl+b. Press Ctrl+b, release both keys, then press the command key. This two-step sequence prevents accidental triggers. You can create multiple windows within a single session and split panes within a window.
# Inside a tmux session, type these sequences
# Press Ctrl+b, release, then press c
# Creates a new window in the current session
# Press Ctrl+b, release, then press n
# Switches to the next window in the session
# Press Ctrl+b, release, then press %
# Splits the current pane vertically
# Press Ctrl+b, release, then press "
# Splits the current pane horizontally
Windows are like tabs in a browser. Panes are like split views within a tab. Use windows for distinct tasks like editing code versus checking logs. Use panes for related tasks like running a command while watching its output in a second pane. The status bar at the bottom of the screen shows window names and pane indices.
Name your sessions. tmux attach without a name attaches to the first session, which is rarely the one you want.
Detach and reattach
The core value of tmux is detachment. You can disconnect from a session and reconnect later, even from a different machine via SSH. The processes inside the session keep running. Detaching is a keyboard shortcut inside the session. Reattaching is a command outside the session.
# Inside the session, press Ctrl+b, release, then press d
# Detaches from the session without killing it
# From a new terminal, reattach to the named session
tmux attach -t backup-job
# Kill the session and all its processes if you are done
tmux kill-session -t backup-job
The d key detaches cleanly. The session remains in the background. tmux attach -t backup-job reconnects to that specific session. If you only have one session running, you can omit -t backup-job and just run tmux attach. tmux kill-session terminates the session and sends SIGHUP to all child processes. Use this when the job is finished. Do not kill the tmux server process manually; use the command to avoid leaving orphaned sockets.
Verify persistence
Test the setup before you rely on it for critical work. Run a long command, detach, wait, and reattach to confirm the process survived. This builds muscle memory for the detach sequence.
# Start a long-running process to test persistence
sleep 3600 &
# Detach from tmux, then reattach
# Verify the process is still running
jobs -l
The sleep 3600 command runs for one hour. The & puts it in the background. After detaching and reattaching, jobs -l lists the background jobs with their PIDs. If you see the sleep process, the session persisted correctly. If the process is gone, you likely killed the session instead of detaching.
Configure tmux for your workflow
Fedora users often customize tmux via ~/.tmux.conf. This file loads automatically when tmux starts. Changes take effect on the next session start, not immediately. Edit the file in your home directory. Never edit files in /usr/share/tmux/. Those are package-managed and will be overwritten on upgrade.
# ~/.tmux.conf
# Enable mouse support for resizing panes and selecting windows
set -g mouse on
# Increase the scrollback buffer to 50000 lines
set -g history-limit 50000
# Set the default terminal mode for better color support
set -g default-terminal "tmux-256color"
The mouse on setting allows clicking to switch windows and dragging to resize panes. This makes tmux feel more like a desktop environment. The history-limit expands the scrollback buffer. The default is often too small for long build logs. The default-terminal setting ensures applications detect the terminal capabilities correctly.
Check the config file. ~/.tmux.conf changes take effect on the next session start, not immediately.
Copy mode and scrolling
Standard terminals struggle with scrolling and text selection. tmux provides copy mode to handle this. Enter copy mode to scroll back through history and select text. This is essential for grabbing error messages or long command outputs.
# Enter copy mode to scroll and select text
# Press Ctrl+b, release, then press [
# Navigate with arrow keys or vim keys
# Press Space to start selection, Space again to copy
# Press q to exit copy mode
The [ key enters copy mode. You can now scroll up and down. Press Space to mark the start of a selection. Move the cursor and press Space again to copy the text to the tmux buffer. Press q to exit. If you have configured your terminal emulator to sync with the system clipboard, the text will be available for pasting outside tmux.
Common pitfalls and errors
Errors usually stem from socket issues or confusion about session state. If you see tmux: connect to server failed: No such file or directory, the tmux server crashed or the socket path is wrong. This happens if you killed the server process manually or if the /tmp directory was cleaned. Run tmux start-server to restart the server, then try attaching again.
If you see tmux: multiple sessions exist, you have more than one session running and you didn't specify which one to attach to. Run tmux list-sessions to see the names, then use tmux attach -t <name>.
A common misconception is that tmux sessions survive a reboot. They do not. The tmux server is a user-space process. When the system shuts down, the process dies. If you need a task to restart automatically after a reboot, use a systemd service or a cron job, not a multiplexer. Multiplexers persist across disconnects, not across reboots.
Run tmux list-sessions first. Guessing the session name wastes time and risks attaching to the wrong job.
When to use tmux vs screen
Use tmux when you want a robust multiplexer with pane splitting, copy mode, and a plugin ecosystem. Use tmux when you are on Fedora Workstation or Server and want the modern default. Use screen when you are on a minimal rescue system or an old server that only has screen installed. Use screen when you need compatibility with legacy scripts that expect screen behavior. Stay on the system default if you only need basic session persistence and don't want to learn keybindings.