Part 9 — Process management in practice

Part 2 explained what a process is in theory. This part is the hands-on counterpart — watching, controlling, and killing real processes on a real system, using the tools you'll actually reach for during an incident, not just to confirm you understand the concept.

Chapter 31 — Watching and controlling processes: `ps`, `top`, `htop`, `kill`

In one sentence

ps gives you a snapshot, top/htop give you a live, continuously-updating view, and kill sends signals (Chapter 20) — together they're how you actually SEE and ACT on Chapter 4's abstract "process" concept, in real time.

Why this matters

"The server is slow, what's going on" almost always starts with one of these three commands — they're the fastest way to turn a vague symptom into a specific, actionable diagnosis.

How it actually works

   ps aux                    # every process, classic BSD-style output
   ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | head   # customised,
                             # sorted by CPU usage -- often more useful
                             # than the default columns
   ps -ef                    # every process, System V-style output
                             # (slightly different columns/conventions)

   top                        # live, auto-refreshing view. Press:
                              #   'q' to quit
                              #   'M' to sort by memory
                              #   'P' to sort by CPU (often the default)
                              #   'k' to kill a process, interactively
   htop                        # a much friendlier, colour, scrollable,
                              # mouse-clickable version of top (not
                              # always pre-installed -- worth adding)

   kill PID                    # send SIGTERM (Chapter 20) -- the polite
                              # request
   kill -9 PID                 # send SIGKILL -- the forceful, un-
                              # ignorable last resort
   kill -l                     # list every signal name/number available
   pkill -f "pattern"           # kill by matching the COMMAND LINE
                              # against a pattern, instead of a PID
   killall processname          # kill every process with this EXACT
                              # name

Reading ps/top columns that confuse people at first:

   %CPU    can exceed 100% on a multi-core machine -- it's the
           percentage of ONE CORE's capacity, so a process using two
           full cores shows ~200%.
   VSZ      virtual memory size (Chapter 10) -- often huge, often
           mostly meaningless on its own.
   RSS      resident set size -- memory ACTUALLY in physical RAM right
           now. Usually the number you actually care about.
   STAT     the process state (Chapter 5: R/S/D/Z/T, plus modifiers
           like `+` for foreground process group, `l` for multi-threaded)

Real-world example

   A FORK BOMB is a genuine, well-documented, real demonstration of
   Chapter 4's "processes aren't free" lesson taken to its logical,
   destructive extreme -- a tiny piece of code (famously, in bash:
   `:(){ :|:& };:`) that defines a function which calls ITSELF TWICE,
   in the background, recursively, with no base case -- exponentially
   spawning new processes until the system's process table, memory, or
   CPU scheduling capacity is completely exhausted, typically making the
   machine unresponsive within seconds. This is widely documented across
   systems-security and Unix-history material as a classic, real
   denial-of-service technique (and a classic systems-administration
   cautionary tale) -- it's PRECISELY why real production systems set
   hard process-count limits per user (`ulimit -u`, Chapter 43) and why
   understanding tools like `ps`/`top`/`kill` -PRECISELY-, under
   pressure, matters: on a system actively being consumed by runaway
   process creation, you need to be able to IDENTIFY and KILL the
   right thing FAST, before the tools themselves become too starved of
   resources to even run.

   Dangerous: do NOT run a fork bomb outside a fully disposable,
   isolated VM you're prepared to hard-reboot. It can render a machine
   completely unresponsive, including to attempts to kill it.

Try it yourself

# Explore process info safely
ps aux | head -10
ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%mem | head -10

# Start something to practice killing
sleep 300 &
PID=$!
echo "started PID $PID"
ps -p $PID
kill $PID                       # SIGTERM
ps -p $PID 2>&1 || echo "gone"

# Practice pkill/killall (safe -- only affects OUR test processes)
sleep 300 & sleep 300 &
pkill -f "sleep 300"
jobs                             # should show them as Terminated

# Watch live process activity (press 'q' to exit)
top

Common mistakes

Reading %CPU as capped at 100%. On a multi-core machine, it's per-core — 300% means roughly three full cores' worth of work.
Reaching for kill -9 as the default. Try plain kill (SIGTERM) first, and give the process a moment to shut down cleanly (Chapter 20) — reserve -9 for processes that genuinely won't respond.
Using killall/pkill with an overly broad pattern. pkill -f sleep would match EVERY process with "sleep" anywhere in its command line, possibly including things you didn't intend — be as specific as possible.

Check yourself

What's the difference between ps and top, fundamentally?
Why can %CPU show a number greater than 100?
What is a fork bomb, and why does understanding process tools matter specifically WHILE one is running?