highFoundationUSE#cpu#runaway#top#process#performance

Runaway process pegging CPU — single process at 100%

top shows one process at 100% CPU

Likely source:performance

Focused incident mode — strips away everything but this runbook.

Symptoms

  • top shows one process at 100% CPU
  • System becomes slow and unresponsive
  • Fan spins up or thermal throttling kicks in

Always try SIGTERM before SIGKILL. A runaway process at 100% CPU is annoying but not dangerous; a SIGKILL may leave corrupt data.

Evidence to grab

Collect these artifacts before you change anything — they prove (or rule out) each cause.

  • Top CPU consumers

    top -bn1 -o %CPU | head -15

  • Process details

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

Diagnostic flow

Run the steps in order, marking each claim confirmed or refuted. The evidence you gather feeds the ranked causes below.

Guided decision tree is ready.

Steps with commands, expected output, and pass/fail branches.

Ranked root causes

Evidence checklist

  • Process consistently at 100% CPU with no I/O wait
  • No new child processes being spawned

Confirm before fixing

strace -cp <PID> -e trace=none 2>&1 | head -5
READ

Check if the process is doing syscall work or just burning CPU

Fix

kill -TERM <PID>
CHANGE

Gracefully terminate the runaway process

Resolution runbook

Apply from top to bottom after the cause is confirmed. Review every command before running it — risk tags are shown on each.

1
ps aux --sort=-%cpu | head -5
READ

Find the runaway process

2
kill -TERM <PID>
CHANGE

Gracefully stop it first

3
sleep 5 && kill -0 <PID> 2>/dev/null && kill -9 <PID>
DESTRUCTIVE

Force-kill only if SIGTERM is ignored after 5 seconds

Prevention

  • Use cgroup CPU limits to cap per-process CPU usage.
  • Set ulimit -t in the service unit file to limit CPU time.
  • Monitor per-process CPU via node_exporter and alert on sustained >90%.
  • Use nice/ionice for batch jobs so they do not starve interactive services.

Related runbooks

Same stack, same failure family — worth a skim.

Fork bomb — runaway process count exhausting PIDscritical

Cannot fork or Cannot allocate memory when trying to start new processes

LinuxIntermediateUSE2 causes
Open runbook
Load average high with low CPU utilization — D-state processeshigh

top shows load average well above CPU core count

LinuxAdvancedUSE3 causes
Open runbook

Commands marked READ CHANGE DESTRUCTIVE — never run DESTRUCTIVE commands against production data you cannot restore. Copy → verify → execute.