When one process starts consuming most of a CPU, capping that one PID can keep terminals, background jobs, and other services responsive long enough to finish the work or diagnose the spike.
The cpulimit tool attaches to an already running process and enforces an average CPU ceiling by repeatedly sending SIGSTOP and SIGCONT. Targeting the process by PID with -p is the safest path when more than one copy of the same executable might be running, because it avoids whichever matching process name happens to be found first.
The steps below assume cpulimit is already installed and use a temporary yes workload so the limiter can be tested without touching a real application. Because cpulimit pauses and resumes the target, sampled %CPU values can jump between refreshes and tools such as ps or top can briefly show the process in state T while the cap is active.
$ yes > /dev/null & echo $! 158
Use the real PID instead when the target process is already running. If the PID is not known yet, pgrep -a can list matching process names together with their PIDs.
$ ps -p 158 -o pid,pcpu,stat,comm
PID %CPU STAT COMMAND
158 98.0 R yes
$ cpulimit -p 158 -l 20 -v 10 CPUs detected. Process 158 detected %CPU work quantum sleep quantum active rate 16.47% 36503 us 63496 us 30.07% 23.92% 34113 us 65886 us 40.79% 20.09% 43355 us 56644 us 43.55% ##### snipped #####
Prefix the command with sudo when the target process belongs to another user. The first line reports how many CPU cores cpulimit detected on that host, and the --limit value is a CPU percentage, so values above 100 are valid on multi-core systems.
cpulimit enforces the ceiling by stopping and resuming the target process, so short checks can show the task as T or print job-control messages even when the limit is working normally.
The watched process keeps running after cpulimit exits because the limiter sends SIGCONT when it stops by default.
$ kill 158
Skip this cleanup step when you targeted a real application instead of the demo yes process.