Stopping the right process quickly can recover a frozen terminal, end a runaway job, or free CPU and memory before the rest of the system slows down. Process termination is also a common incident-response step when one task is stuck and a full reboot would be too disruptive.
Linux stops processes by sending signals. The default signal from kill and pkill is SIGTERM, which asks the target to exit cleanly, while SIGKILL ends the process immediately without giving it a chance to release locks, flush buffers, or remove temporary files.
Signals only work when the kernel can deliver them, so a task in uninterruptible sleep with state D may not disappear until the blocked I/O call returns. Root privileges are required to signal another user's processes, and processes started by systemd or another supervisor may restart right away unless the owning service is stopped or restarted separately.
$ pgrep -a -x sleep 139 sleep 600
-x requires an exact process-name match, and -a prints the full command line with the PID so similarly named processes are easier to distinguish. Prefix the command with sudo if the target belongs to another account and the current user cannot inspect it directly.
$ kill 139
kill sends SIGTERM by default, which is the safest first attempt for most user-space processes.
$ ps -p 139 -o pid=,stat=,cmd=
No output means the process has exited and the PID is no longer present in the process table.
$ ps -p 139 -o pid=,stat=,cmd=
139 S sh -c trap "" TERM; while :; do sleep 30; done
This example process ignores SIGTERM, so it remains in the process table after the first signal.
$ kill -KILL 139
SIGKILL cannot be caught or ignored, so the process cannot run cleanup handlers, flush application state, or remove its own lock files before exit.
$ pkill -e -x sleep sleep killed (pid 163)
This is useful when several short-lived instances share the same exact command name and all of them should receive the same signal.
$ pgrep -a -x sleep
No output means no exact-name sleep process is still running. If the same command appears again immediately, a service manager or supervisor probably started a replacement process.