Background Jobs and nohup
Interactive shells track every command you launch as a 'job,' whether it's running in the foreground and holding your terminal or running in the background while you keep typing. Job control lets you juggle multiple tasks in a single terminal session, and understanding how jobs relate to the terminal's controlling process — and what happens to them when that terminal closes — is essential for running anything long-lived, from a data import script to a personal web server, without accidentally killing it the moment you log out.
Cricket analogy: A shell juggling jobs is like a captain managing both the striker at the crease (foreground) and a bowler warming up in the outfield (background) within the same session; if the stadium closes (terminal exits), both can be affected unless protected.
Foreground, background, and job control
Appending & to a command launches it in the background immediately, returning control of the shell to you while the command runs; the shell prints a job number and PID. The jobs builtin lists all jobs associated with the current shell session, showing their job number, state (Running, Stopped, Done), and command. fg %N brings job N to the foreground, and bg %N resumes a stopped job in the background. Pressing Ctrl+Z sends SIGTSTP to suspend the foreground job, after which bg can resume it without occupying the terminal. Job numbers (like %1) are shell-local shorthand for PIDs and only make sense within the shell session that created them.
Cricket analogy: Appending & is like sending a substitute fielder onto the ground without stopping play, immediately freeing the captain (shell) to give the next instruction; jobs lists everyone on the field with their status, fg/bg swap a player between active and reserve, and Ctrl+Z is like calling a player off mid-over to the sideline.
# Start a long-running task in the background
./backup_database.sh &
[1] 8842
# List jobs in this shell
jobs -l
# Bring job 1 back to the foreground
fg %1
# Suspend the foreground job (Ctrl+Z), then resume it in the background
# (press Ctrl+Z first)
bg %1
# Detach a job from the shell so it survives logout
disown %1
# Or start it already nohup'd and backgrounded, redirecting output
nohup ./backup_database.sh > backup.log 2>&1 &
# Confirm nohup honored SIGHUP (check nohup.out if you didn't redirect)
cat nohup.outWhy processes die on logout, and how nohup prevents it
When you close a terminal or SSH session, the shell typically sends SIGHUP to all jobs it started, and by default SIGHUP terminates a process. This is intentional: it stops orphaned background tasks from accumulating on shared systems. nohup works around this by explicitly telling the process to ignore SIGHUP, so it keeps running after the parent shell exits; it also redirects stdout/stderr to nohup.out if you don't redirect them yourself, since the original terminal (its stdout/stderr destination) will no longer exist. nohup alone doesn't background a process — you still need the trailing &. disown is a related but different shell builtin: it removes a job from the shell's job table so the shell won't send it SIGHUP at all, without changing the process's own signal handling.
Cricket analogy: Closing the terminal is like the stadium lights shutting off mid-match, sending SIGHUP to every player still on the field, which normally ends their innings; nohup is like a player with noise-cancelling focus who ignores the shutdown announcement and keeps batting, writing updates to a notebook (nohup.out) since the scoreboard is gone, but still needs & to be on the field; disown is like removing a player from the official roster so no shutdown notice is even sent.
For anything that needs to survive not just terminal closure but also transient network drops during a long SSH session, tools like tmux or screen are usually a better fit than nohup — they keep an entire persistent terminal session alive on the server that you can detach from and reattach to later, rather than just suppressing one signal for one command.
nohup command & without output redirection silently creates or appends to a nohup.out file in the current directory (or your home directory if that's not writable) every time you run it, which can quietly fill a disk over months of cron-triggered or ad hoc invocations. Always redirect explicitly: nohup command > /var/log/mycommand.log 2>&1 &.
command &backgrounds a job;jobs,fg %N, andbg %Nmanage jobs within the current shell session.- Closing a terminal sends SIGHUP to its jobs, which terminates them by default.
nohupmakes a process ignore SIGHUP so it survives logout; you still need&to background it.disownremoves a job from the shell's job table so no SIGHUP is sent to it at all, independent of the process's own signal handling.- nohup redirects output to nohup.out automatically unless you redirect stdout/stderr yourself — always redirect explicitly in production use.
tmux/screenprovide a more robust alternative for long sessions that must survive network interruptions, not just terminal closure.
Practice what you learned
1. What signal does a shell typically send to its background jobs when the terminal is closed?
2. Which command lists the jobs currently tracked by the active shell session?
3. What does `nohup ./script.sh &` actually do, in two parts?
4. What is the key difference between `disown` and `nohup`?
5. Why should you redirect output when using nohup, e.g. `nohup cmd > out.log 2>&1 &`?
Was this page helpful?
You May Also Like
Killing and Signaling Processes
Understand Unix signals and the kill, killall, and pkill commands to gracefully terminate or forcibly stop misbehaving processes.
Monitoring Processes with ps and top
Learn to inspect running processes with ps snapshots and the interactive top monitor, reading CPU, memory, and state columns to diagnose system load.
Understanding Processes
Learn what a process is in Linux, how it relates to programs and the kernel, key attributes like PID/PPID and process states, and the parent-child process tree.
Pipes and Redirection
Learn how the shell wires standard input, output, and error between commands and files using redirection operators and pipes to build powerful command chains.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics