`nohup` Is Still the Command You Use When a Process Needs to Keep Running After Your Terminal Goes Away and You Do Not Need a Whole Supervisor Yet
A practical guide to `nohup` for keeping a command alive after logout when you need a quick background run without immediately setting up PM2, systemd, or another process manager.
Why this command matters: not every long-running task deserves a full process manager, but plenty of tasks do need to survive after your SSH session ends.
You SSH into a box, start a long script, close the terminal, and later discover the process died with your session. That is exactly the kind of small operational annoyance nohup still solves.
The command
nohup python3 long_job.py > long_job.log 2>&1 &This does three useful things:
- detaches the process from your session’s hangup signal
- sends output to a file instead of the dead terminal
- backgrounds the process
That is often enough for one-off tasks, long test runs, migrations, or temporary utilities.
Why output redirection matters
If you do not redirect output, nohup will usually write to nohup.out. That may be fine, but it is usually better to choose the file explicitly:
nohup ./sync-data.sh > sync-data.log 2>&1 &Now you know exactly where to inspect later with:
tail -f sync-data.logWhen nohup is the right tool
Use it when:
- the task is temporary
- you want it to survive disconnect
- you do not need restart policies or health checks
- setting up a full supervisor would be overkill
If the process is permanent infrastructure, use systemd, PM2, or another proper supervisor. nohup is a practical shortcut, not a replacement for service management.
Final recommendation
If a command needs to keep running after your terminal disappears and you do not need a full supervisor yet, nohup is still a perfectly good tool. Just remember to redirect output and treat it like a temporary operational convenience, not a forever deployment strategy.