Monitoring and Killing Processes

In one line

ps and top/htop show you what's running right now; kill sends SIGNALS to processes — and the specific signal you send matters far more than most people realize.

0/4 · 0%

Think of it like this

Real-life example: ps is like a single photograph of everyone in a building right now; top (or the friendlier htop) is a live, continuously updating security camera feed of the same thing, refreshing every second or two.

Key ideas

01
ps aux is the classic, universally-available way to list every process on the system: user, PID, CPU%, memory%, and the command itself. ps aux | grep <name> (Phase 2's grep, applied here) is the standard way to find a specific process by name.
02
top shows a live, auto-refreshing view sorted by resource usage (CPU by default) — press q to quit, M to sort by memory instead. htop is a more modern, considerably more readable alternative (colorized, scrollable, mouse-clickable) that isn't installed everywhere by default but is worth installing wherever you have the choice.
03
kill <pid> doesn't necessarily 'kill' anything by force — by default it sends SIGTERM (signal 15), a POLITE request asking the process to shut down gracefully, giving it a chance to close files, finish in-flight work, and clean up (Docker's own course covered this exact signal in the context of docker stop). Well-behaved programs listen for SIGTERM and shut down cleanly.
04
kill -9 <pid> sends SIGKILL, which the OS delivers by FORCE — the target process gets no chance to clean up anything at all, and cannot even choose to ignore it (unlike SIGTERM, which a program CAN choose to ignore or handle specially). SIGKILL should be a last resort, used only when SIGTERM has already been tried and the process still refuses to exit.
05
pkill <name> and killall <name> send a signal to every process matching a NAME instead of requiring you to look up a PID first — genuinely convenient, but correspondingly more dangerous, since a too-broad name pattern can match (and kill) more processes than you intended.
06
pgrep <name> lists matching PIDs without signalling anything, so run it first to preview exactly what pkill would hit. pgrep -a nginx shows the full command lines too.
07
PRIORITY: nice -n 10 ./backup.sh starts a process with a lower CPU priority (niceness ranges from -20, most favoured, to 19, least; the default is 0), and renice -n 15 -p <pid> changes it for a running process. Only root can raise priority (negative values). Use it for batch jobs like backups, reindexing, or compression so they don't slow down the service on the same box; ionice -c3 does the same for disk I/O. The NI column in top shows each process's niceness.

In your stack

→
A hung Spring Boot process is almost always dealt with as kill <pid> FIRST (giving the JVM's shutdown hooks — including Spring's own graceful-shutdown handling — a real chance to run) and kill -9 only as an escalation if it genuinely doesn't respond within a reasonable window, exactly matching Docker's docker stop vs docker kill distinction covered earlier.

Code & diagrams

monitor-and-kill.shmarkdown

Practice against a harmless background sleep process — nothing here risks anything real.

# Start something to practice on
sleep 600 &
PID=$!
echo "PID is $PID"

# List it explicitly
ps aux | grep sleep

# Watch live resource usage (press q to quit)
top
# or, if installed: htop

# Send a polite shutdown request first
kill $PID
sleep 1
ps -p $PID   # should show "no such process" if it exited cleanly

# If it had refused to exit, THEN escalate:
# kill -9 $PID

# Kill by name instead of PID (use carefully — matches ANY process with this name)
# pkill -f "sleep 600"

Explain it without notes

Why is kill -9 considered a last resort rather than the default way to stop a stuck process?

What's the practical risk of using pkill/killall by name instead of kill by a specific PID?

Practice

Start a background process, find it with ps, send it a normal kill, and confirm with ps -p <pid> that it's actually gone before ever reaching for -9.

Open top (or htop if installed) and identify the single process currently using the most memory on your system — read every column you don't immediately recognize.

Trade-offs

↔
Reaching straight for kill -9 out of impatience is tempting when a process seems stuck, but the time saved is rarely worth the risk of leaving corrupted state behind — the discipline of trying a graceful SIGTERM first, waiting a reasonable moment, and only THEN escalating is worth maintaining even under pressure during an incident.

Done when you can

I can find a running process's PID with ps and watch live resource usage with top.
I understand kill sends SIGTERM by default, a polite request, not a forced termination.
I know kill -9 (SIGKILL) is a last resort, not a first choice.

Command Palette