ch05 · operator · 90-120 min

processes and resource triage

Inspect running work, signals, jobs, CPU, memory, disk, inodes, and first-pass bottlenecks.

You can name the busy process or resource constraint with evidence before restarting anything.

processessignalsperformancedffree
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.

Lessons in this chapter

  1. ch05/l01 Process identity and signals ps aux Map PIDs to command lines before sending signals.
  2. ch05/l02 Jobs and foreground control jobs Understand shell-managed background work before losing track of it.
  3. ch05/l03 CPU, memory, disk, and inode first pass df -hi Separate resource symptoms before choosing a fix.
capstone

resource pressure readout

Analyze a sample host snapshot and decide whether process, memory, disk bytes, inodes, or I/O is the first suspect.

Deliverable

A triage note with evidence and next least-invasive action.

Success criteria

  • You do not name a root cause without evidence.
  • You separate bytes from inodes.
  • You distinguish shell jobs from system processes.
Terminal Drill companion

Processes

After you can move from symptom to process/resource evidence without guessing.

Train after the lesson