tmux: Running Long Tasks on the Server Without Getting Disconnected

You've run the mysqldump command, the progress bar is creeping forward, and the laptop is on battery. The Wi-Fi drops for a moment. You reconnect and find the process is dead and the dump file is half-finished. This is exactly where tmux comes in: a small program that keeps a shell inside a session independent of your terminal. When SSH disconnects, the session stays and so does the command.

Let me explain the difference from nohup and &, because many people confuse the two. nohup only blocks the HUP signal and detaches the process from the terminal, but you can no longer look at it mid-task or give it input. tmux gives you a real terminal that you can return to whenever you want. For tasks like database migration, rsync on a hundred gigabytes of files, or a long build, this difference is critical.

Why running a command directly dies when SSH disconnects

When you log in via SSH, your shell is a child of the SSH session. The moment the connection drops, the kernel sends a SIGHUP signal to the processes of that terminal. Foreground processes receive this signal and die. If you're lucky, the task is just left half-done; if you're unlucky, a database table gets stuck in a half-migrated state and you have to restore from backup.

The symptom is also clear: after disconnecting and reconnecting, ps aux | grep mysqldump returns nothing and you have no error log. Just an incomplete file left on disk.

Creating your first persistent session with tmux

It's installed on most distributions. If not:

apt install tmux        # Debian and Ubuntu
dnf install tmux        # Red Hat and Fedora

Now create a session with a specific name. Take naming seriously; when you have three sessions open, tmux ls without names just shows you a bunch of meaningless numbers.

tmux new -s backup

You enter the session. Run your long command right there. Now press the key combination Ctrl+b and then d to detach from the session. The session stays alive in the background. To return:

tmux attach -t backup

If you forgot the session name, tmux ls gives you the list and with tmux attach -t 0 you connect to number zero. That's it. Everything you needed to keep a six-hour backup alive is done.

The keys you'll actually use

All tmux commands start with a prefix, which by default is Ctrl+b. Memorize these few, you don't need the rest:

• Ctrl+b then d — detach from the session without closing it
• Ctrl+b then c — create a new window inside the same session
• Ctrl+b then n and p — next and previous window
• Ctrl+b then % — vertical pane split
• Ctrl+b then " — horizontal pane split
• Ctrl+b then [ — enter scroll mode to see previous output

Don't underestimate scroll mode. When a build produces a thousand lines of log and you just want to see the error in the middle, without this mode you'd have to save the log to a file. With Ctrl+b [ you enter, move with the arrow keys, and exit with q.

This is where people make mistakes

The most common mistake I see in support tickets is this: the user works inside tmux, then closes the terminal window by clicking the X and thinks the session stayed on the server. In some terminals, this action sends a real SIGHUP instead of detaching and kills the session. The symptom is that tmux ls says no server running on /tmp/tmux-1000/default and you think the server has been reset.

The correct habit is: always press Ctrl+b d first, then close the terminal. If you're not sure, after detaching, SSH in once more and check tmux ls.

Second mistake: running a command with sudo inside a regular user's session. A tmux session belongs to the same user who created it. If you create a session with sudo -u www-data tmux new -s deploy, you can't attach to it later with your own user and you get a no sessions error. For service-oriented tasks, create the session with the same owning user.

tmux or screen or systemd?

All three do similar work, and choosing between them depends on the situation, not on preference.

My choice for everyday work on the server is tmux. But if a task is supposed to run every night at three and also come back after a reboot, tmux is the wrong answer; there you should write a systemd unit file with Restart=on-failure. tmux is made for "right now, manually, until it finishes."

Let me also mention a real limitation that few people know in advance: tmux sessions are lost after a server reboot. If the server restarts, all sessions are gone. For tasks that take hours and carry reboot risk, always dump the output to a file with tee:

mysqldump -u root -p shop | gzip > /root/shop-$(date +%F).sql.gz

This way, even if the session dies, you know how far it got and can continue.

Small settings that change the experience

Create the ~/.tmux.conf file and put these few lines in it:

set -g mouse on
set -g history-limit 50000
set -g base-index 1
setw -g pane-base-index 1

The first line enables scrolling with the mouse and selecting panes by clicking. The second line raises the history buffer from the default 2000 lines to 50000 lines; you need this number for long logs. The last two lines change window numbering from zero to one, which is more natural for most people. After saving, apply it with tmux source-file ~/.tmux.conf.

If you work on a shared server and several people need to see one session, tmux has this too: create a session with tmux new -s shared and others join the same session with tmux attach -t shared. Both people see the same view and both can type. For debugging a problem together, this is faster than screen sharing.

If you've just set up the server and haven't prepared the environment yet, before anything else take a look at the documentation and knowledge base; the initial server checklists are gathered there. For lighter tasks like testing commands or checking DNS, the free tools get you going without needing SSH. And if your whole task is on a WordPress site and you don't want to get involved in managing shell sessions, ServerNet's WordPress hosting takes this layer off your shoulders.

One last note about servers that have just come up: if the site doesn't come up after installation and you're not sure whether the problem is DNS or the service, first check the DNS_PROBE_FINISHED_NXDOMAIN error, because in half the cases the problem isn't on the server side at all.

Frequently asked questions

How do I know my command inside tmux is still running?

With tmux ls you see the list of live sessions, and with tmux attach -t name you enter it and see the live output. If the session isn't in the list, it either wasn't detached and died when SSH disconnected, or the server has been rebooted.

Do tmux sessions come back after a server reboot?

No. tmux sessions live in the server's memory and are lost on reboot. If a task must continue after a reboot, you should define it as a systemd service, not a tmux session.

What's the difference between tmux and nohup?

nohup only detaches the process from the terminal disconnect signal, and after that you can no longer go inside it or give it input. tmux gives you a complete, returnable terminal that you can attach to at any moment, scroll through, and run new commands in.

Why does the screen look garbled after attaching?

This usually happens when the current terminal size differs from the size at the moment the session was created. With Ctrl+b and then : enter the tmux command line and run resize-window -A, or more simply resize the terminal window once smaller and larger so it adjusts itself.