ch05/l01

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.

In the field

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
Anti-pattern

Do not start with `kill -9`, and do not kill by PID without confirming the command line.

Safer pattern

Confirm PID, owner, command, and impact. Send TERM first.

Knowledge check

A process ignores your kill -TERM and keeps running. What does that tell you, and what is the correct next move?

  • A TERM is broken on this kernel; only kill -9 ever actually works
  • B The process chose to ignore or is blocked handling TERM; escalate to kill -KILL as a last resort
  • C You used the wrong PID; TERM always stops a process that exists
  • D TERM only pauses the process; you must run kill -CONT to finish it
Show the answer

Correct: B. The process chose to ignore or is blocked handling TERM; escalate to kill -KILL as a last resort

Why

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

  1. Start a harmless `sleep 300` process.
  2. Find it with `ps` and `pgrep -a`.
  3. Terminate it with TERM.

Deliverable evidence

  • PID and command evidence.
  • Signal used and why.
Teaching diagramch05 · mental model
symptom -> evidence -> least-invasive action symptom slow / full / stuck which class? CPU mem disk inode uptime CPU / load free -h available mem df -h disk bytes df -hi inodes narrow it: du -sh, pgrep -a, ps aux name the busy process or constraint TERM before KILL, only after evidence no blind restart

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.

Memorize this

Commit these to memory, then drill them until recall is automatic.

ps auxpgrep -akill -TERMkill -KILL
Recall practice · Risky -> safer

cue You confirmed the PID and want to stop it the normal, cooperative way first

show recall target

kill -TERM <pid>