Process Signals & Job Control

kill is a misleading name - it doesn't only kill things. It sends a signal, and different signals ask a process to do very different things. Understanding signals turns "kill -9 everything" from a reflex into an actual choice.

Signals: small messages, not just death

A signal is a tiny, asynchronous notification the kernel delivers to a process - "someone hung up," "please terminate," "stop running for now." The process can choose how to react to most of them (or ignore them entirely).

kill 1234          # sends SIGTERM (15) - "please shut down"
kill -9 1234        # sends SIGKILL - immediate, no cleanup, last resort
kill -HUP 1234      # sends SIGHUP - many daemons reload config on this instead of restarting

Why SIGTERM before SIGKILL

SIGTERM gives a process a chance to close files, flush buffers, and shut down its children cleanly. SIGKILL gives it no chance at all - the kernel just removes it, which can leave temp files, locks, or half-written data behind. The right habit: try plain kill (SIGTERM) first, and only reach for kill -9 when a process is well and truly stuck ignoring it.

Job control: foreground, background, and back again

Every command you run occupies your terminal until it finishes - unless you tell the shell otherwise:

sleep 30            # foreground: your prompt is blocked until this returns
sleep 30 &           # background: prompt comes back immediately
jobs                 # list jobs you've started with &, in this session
fg                   # bring the most recent background job to the foreground
fg %1                # bring job number 1 specifically to the foreground
bg %1                # resume a STOPPED job (e.g. after Ctrl-Z) in the background

jobs prints each background job with a number like [1]; that number is what %1 in fg/bg refers to. On a real terminal, Ctrl-Z suspends (stops, not kills) whatever's currently in the foreground, handing you back the prompt - bg then resumes it in the background, and fg resumes it in the foreground.

The practice terminal has no true concurrency, so a backgrounded command still runs to completion immediately rather than continuing alongside your next command - jobs will show it as already Done. The commands and their purpose are exactly what you'd use on a real system; only the timing is simplified.

nohup: surviving a closed terminal

A background job is still a child of your shell - close the terminal, and it normally gets SIGHUP and dies with it. nohup makes a command immune to that specific signal, which is why it's the standard way to start something that should outlive your SSH session:

nohup ./long-running-job.sh &

Output that would have gone to your terminal is redirected into a file called nohup.out instead, so you can check on it later even after logging out.

Try it

sleep 30 &
jobs
fg
kill -9 1234
kill -HUP 1234
nohup ping example.com

Further reading

• "How Linux Works" by Brian Ward (No Starch Press) - explains signals from the kernel's side: how they're delivered, queued, and why some can't be blocked.
• "The Linux Command Line" by William Shotts (No Starch Press) - its job control chapter covers fg/bg/jobs/Ctrl-Z with the exact terminal-driver mechanics behind them.