Long-running jobs
Every sysadmin learns this the same way: a four-hour job, a dropped wifi connection, and nothing to show for it.
The habit
Before starting anything that takes more than a minute:
tmux new -s werk
Run your job. Detach with Ctrl-b d. The session keeps running on the
server whether or not you are connected.
Come back later, from anywhere:
tmux attach -t werk
tmux ls to see what is running.
The handful of keys worth knowing
- Ctrl-b d
- Detach. The one that matters.
- Ctrl-b c
- New window.
- Ctrl-b n / p
- Next, previous window.
- Ctrl-b "
- Split horizontally;
%splits vertically. - Ctrl-b [
- Scroll back through output.
qto leave.
screen does the same job with Ctrl-a as its prefix. If it
is already installed and you know it, there is no reason to switch.
Where it genuinely saves you
- A distribution upgrade — a dropped connection mid-dpkg is how machines end up unbootable
- A large
rsyncor database import — see moving files around - An array rebuild you want to watch — software RAID
- Anything on a machine you are reaching over a flaky network
It is not a job scheduler
A tmux session is not restarted when the machine reboots and nothing alerts you when the job inside it dies. For anything that must run reliably or repeatedly, use a systemd service or timer instead — see running your application as a service and cron jobs and timers.
The pattern that catches people out: leaving a production service running in a tmux session. It works until the first reboot, and then nobody remembers it existed.
A cheap alternative for one command
nohup ./long-job.sh > job.log 2>&1 &
Survives a disconnect, writes to a file you can read later. No interactivity and no way back into it, but for a fire-and-forget job it is enough.
Either way, log the output somewhere. A job that ran for three hours and printed everything to a terminal that no longer exists has told you nothing — see logs.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base