9.1 Identify and Kill CPU/Memory Intensive Processes

9.1 Identify and Kill CPU/Memory Intensive Processes

Quick Answer: Find hot processes with top, ps, and pgrep. Stop them with kill / pkill using the right signal—usually SIGTERM (15) first, SIGKILL (9) only if needed. Confirm with pgrep or ps that the process is gone. On EX200 you prove the end state, not that you memorized every ps flag.

Why this skill appears on EX200

Under Operate running systems, Red Hat expects you to identify CPU- and/or memory-intensive processes and kill processes. Typical lab wording looks like:

• “A process named runaway is consuming excessive CPU—stop it.”
• “Find the process using the most memory and terminate it.”
• “End all processes matching pattern X owned by user Y.”

You are graded on whether the process is no longer running (or no longer matching the problem description), not on which pretty TUI you preferred. Work fast, verify twice, and avoid killing critical system daemons unless the task clearly targets them.

Process identity basics

Every process has a PID (process ID). Child processes have a PPID (parent). You send signals to a PID (or to a process group). Tools that accept a name still resolve names to PIDs under the hood.

Useful views of the same truth:

On RHEL 10, ps, top, kill, pgrep, and pkill from procps-ng are the exam-safe toolkit. Prefer them over exotic tools that might not be installed.

Live overview with top

top
# Inside top (common keys):
#   P  sort by CPU%     M  sort by memory%
#   k  kill (prompts for PID and signal)
#   1  toggle per-CPU lines
#   q  quit

Header lines show load average, task counts, CPU breakdown, and memory/swap. The process table columns that matter most on the exam:

Exam tip: Sort by CPU (P) or memory (M), note the PID and COMMAND, then quit and use shell kill if you prefer a reproducible audit trail. Killing from inside top is valid if you are careful with the PID prompt.

Batch (scriptable) snapshot without interactive UI:

top -b -n 1 | head -n 20

Snapshots with ps

Classic BSD-style full list:

ps aux
ps aux --sort=-%cpu | head
ps aux --sort=-%mem | head

POSIX/System V style and custom formats:

ps -ef
ps -eLo pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm
ps -eo pid,user,pcpu,pmem,stat,comm --sort=-pcpu | head
ps -eo pid,user,pcpu,pmem,rss,comm --sort=-rss | head
ps -u student                 # processes for one user
ps -C httpd -o pid,user,cmd   # by command name

Zombies (Z): Already dead; parent has not wait()ed. You cannot “kill” a zombie usefully—fix or kill the parent if the task is about cleaning zombies. Most EX200 tasks target runaway live processes, not zombies.

D state: Uninterruptible sleep (often I/O). SIGKILL may not clear it until the underlying wait ends. Do not burn all exam time on a stuck D-state process if the task can be satisfied another way.

pgrep and pkill

When the task gives a name or pattern, these are faster than scrolling ps:

pgrep runaway
pgrep -a runaway              # PID + full command line
pgrep -u student stress
pgrep -f "python3 /opt/job.py"   # match full command line (-f)

pkill runaway                 # SIGTERM to matches
pkill -u student runaway
pkill -f "python3 /opt/job.py"
pkill -9 runaway              # SIGKILL by name—double-check pattern first

Danger: pkill -f patterns can match more than you intend (including your own shell history or scripts). Always pgrep -a the same pattern before pkill.

# Safe pattern
pgrep -a -f "/usr/local/bin/runaway"
# If the list is only the intended targets:
pkill -f "/usr/local/bin/runaway"

killall (from psmisc, often present) kills by process name:

killall runaway
killall -9 runaway

Prefer exact name awareness: killall bash is catastrophic on a multiuser system. On the exam, use the name the task specifies and verify with pgrep afterward.

kill and signals

kill PID
kill -15 PID                  # same as default: SIGTERM
kill -TERM PID
kill -9 PID                   # SIGKILL
kill -KILL PID
kill -1 PID                   # SIGHUP
kill -HUP PID
kill -SIGNAL PID1 PID2 ...    # multiple PIDs

List names and numbers:

kill -l

Practical signal strategy on EX200

1. Identify PID(s) with top / ps / pgrep -a.
2. Send SIGTERM: kill PID or pkill name.
3. Wait a second; re-check pgrep / ps -p PID.
4. If still alive and the task requires it gone: kill -9 PID.
5. Re-verify. Document nothing fancy—just leave the system correct.

Why not always -9? Well-written programs flush data and release locks on SIGTERM. SIGKILL skips cleanup. Graders usually only care that the process is gone, but good habit is TERM first unless the task says “force” or the process ignores TERM.

Permissions

You can signal your own processes. Signaling another user’s processes requires root (or appropriate capability). Exam tasks that target system-wide runaways imply root on the VM.

sudo kill 1234
sudo pkill -u alice stress-ng

/proc quick checks

ls /proc/1234
cat /proc/1234/cmdline | tr '\0' ' '; echo
cat /proc/1234/status | egrep '^(Name|State|Uid|VmRSS|Threads):'

If /proc/PID vanishes, the process already exited. Useful when kill returns “No such process.”

Memory vs CPU: what “intensive” means

• CPU intensive: High %CPU in top/ps, climbing TIME+, often state R.
• Memory intensive: High %MEM or RSS; system may use swap (free -h, si/so in vmstat).

free -h
ps aux --sort=-%mem | head -n 15

A process can be memory-heavy while mostly sleeping (S). Still a valid kill target if the task says “memory intensive.”

End-to-end exam scenarios

Scenario A — Named runaway on CPU

Task: Process burncpu is consuming CPU. Terminate it.

pgrep -a burncpu
# e.g. 44821 burncpu
sudo kill 44821
sleep 1
pgrep burncpu || echo "gone"
# if still present:
sudo kill -9 44821
pgrep burncpu || echo "gone"

Scenario B — Highest memory consumer

Task: Identify the non-kernel process using the most RAM and kill it (wording varies—read carefully if system processes are excluded).

ps -eo pid,user,pmem,rss,comm --sort=-rss | head -n 10
# Choose the PID the task intends (often a user job, not kthreadd)
sudo kill PID
ps -p PID || echo "terminated"

Scenario C — All matching jobs for a user

pgrep -a -u student jobworker
sudo pkill -u student jobworker
pgrep -u student jobworker || echo "none"

Scenario D — Service vs stray process

If httpd is “bad” only because of a task to stop the service, prefer systemctl stop httpd (later objectives) so unit state is clean. If the task literally says kill process evil.py, use kill/pkill—do not over-engineer.

Common traps

1. Killing the wrong PID after the process already exited and the PID was reused—re-run pgrep -a immediately before kill.
2. pkill java matching more JVMs than intended—use a full-path -f pattern after dry-run pgrep -a.
3. Assuming SIGKILL failed when the process is in D state—note it and move on if required work is done.
4. Killing PID 1 (systemd)—do not; you will destabilize the system.
5. Forgetting verification—always pgrep/ps after kill.
6. Treating kill as persistent config—if a enabled service respawns after reboot, that is a services problem, not solved by a one-time kill alone.

Persistence and scoring notes

Process death is immediate and does not need a reboot to “take effect.” Reboot may restart enabled services or @reboot jobs. For pure “kill this process now” tasks, success is: process absent before you leave the station. If a later task requires a service up, do not leave critical units dead.

Section checkpoint

You should open top or ps, sort or filter by CPU and memory, resolve names with pgrep -a, send SIGTERM then SIGKILL as needed with kill/pkill, avoid over-broad patterns, and verify the process is gone. That is the EX200 standard for identifying and killing intensive processes.