Process identity and signals
Map PIDs to command lines before sending signals.
ps aux
25 min read, 30 min lab
operator
A process ID is only useful after you know what command it represents, who owns it, and whether it has children. Signals ask or force processes to stop; `TERM` is the normal request, `KILL` is the last resort.
A runaway test process is consuming CPU in a lab shell.
Worked command
$ ps aux | grep '[s]leep'$ pgrep -a sleep$ kill -TERM 12345$ kill -KILL 12345
Do not start with `kill -9`, and do not kill by PID without confirming the command line.
Confirm PID, owner, command, and impact. Send TERM first.
A process ignores your kill -TERM and keeps running. What does that tell you, and what is the correct next move?
Show the answer
Correct: B. The process chose to ignore or is blocked handling TERM; escalate to kill -KILL as a last resort
TERM is a catchable request, so a process can trap it, be slow to clean up, or be stuck in uninterruptible state; KILL (9) is the uncatchable last resort. Reaching for -9 first is the misconception the chapter warns against — it denies the process any chance to shut down cleanly.
Practice checklist
- Start a harmless `sleep 300` process.
- Find it with `ps` and `pgrep -a`.
- Terminate it with TERM.
Deliverable evidence
- PID and command evidence.
- Signal used and why.
shows: The triage path: a symptom sorts into a resource class (CPU, memory, disk bytes, inodes), each with its own first command, then narrows to a named process or constraint before any TERM/KILL or restart.
does not prove: It shows the order of checks, not the verdict: running these commands gathers evidence but does not by itself prove which resource is the true bottleneck — you still have to read the numbers and reason about available vs free, bytes vs inodes.
Commit these to memory, then drill them until recall is automatic.
cue You confirmed the PID and want to stop it the normal, cooperative way first
show recall target
kill -TERM <pid>