Kill a process in Linux: kill, pkill and the right signal

Short answer: find the process ID with ps aux | grep NAME or pgrep NAME, then run kill PID. That sends SIGTERM, which asks the process to shut down cleanly. If it ignores that after a few seconds, follow up with kill -9 PID (SIGKILL), which the kernel removes at once and the process cannot block. To kill by name instead of PID, use pkill NAME or killall NAME.

pgrep -a NAME          # find the PID, with the full command line
kill PID               # SIGTERM: ask it to stop
kill -9 PID            # SIGKILL: force it

Every flag and signal name below was checked against the kill(1), pgrep(1)/pkill(1) and fuser(1) man pages on Debian 12 (procps-ng).

Find the process ID (PID)

ps aux columns worth knowing before you kill anything: PID is what kill takes, PPID (with ps -ef) is its parent, and STAT shows Z for a zombie — already dead, waiting only for its parent to read its exit status, and not something a signal can remove. ps aux, column by column covers the rest of the output.

Kill whatever is listening on a port

Address already in use when a service starts means another process already holds its port. Find and, if you are sure, kill it:

sudo ss -tlnp | grep ':8080'        # which PID has port 8080
sudo fuser 8080/tcp                 # just the PID(s), fuser's own notation
sudo kill $(sudo fuser 8080/tcp 2>/dev/null | awk '{print $1}')

fuser prints each PID followed by a letter for how it holds the file or socket — blank in the default display for an open file, a trailing c for the current directory. lsof -i :8080 is the equivalent if lsof is installed; it is not on a minimal Debian or Ubuntu install by default. Check what the process actually is before killing it — a port held by something you still need is not a bug to fix with kill -9. See Address already in use for the rest of that error.

Which signal: TERM, KILL, HUP and the rest

kill does not kill in the literal sense — it sends a signal, and the default signal, number 15, is SIGTERM. What the process does with it is up to the process.

Reach for SIGKILL only after SIGTERM had a few seconds and the process is still there. The cost of skipping straight to -9 is real: a database or anything else mid-write loses the chance to flush to disk or close a transaction cleanly, which is how a half-written file or a corrupt index happens. kill -l prints every signal name the system knows, and man 7 signal explains each one in full.

kill PID          # SIGTERM (15) — try this first
kill -15 PID      # the same, written out
kill -9 PID       # SIGKILL — last resort
kill -HUP PID     # ask a daemon to reload its config, without restarting it

pkill and killall: by name instead of PID

pkill and killall both take a process name and skip the PID lookup — useful when several processes share a name, or you do not know the PID yet. They are not the same command on every Unix (the BSD/macOS killall kills every process with that name with no name matching at all), but on Debian and Ubuntu both come from procps-ng and behave as shown here.

pkill node                 # SIGTERM to every process named "node"
pkill -9 -f "worker.py"    # SIGKILL, matched against the full command line, not just the name
killall -9 chrome          # same idea, killall's own syntax
pgrep -a node               # list matches before you kill anything — the safe first step

-f matches the whole command line instead of just the process name, which is what you want for a script run through an interpreter — pkill python3 would otherwise match every Python process on the box, not just yours. Always run the bare pgrep (no -SIGNAL) first to see exactly what will be hit; there is no undo once the signal goes out.

-u, -g and other filters

Narrow a match with pkill’s own filters rather than a looser pattern: -u USER limits it to one user’s processes, -g PGID to a process group, and -o/-n pick the oldest or newest match when several processes share a name. kill -- -PGID (with the leading dash) sends a signal to every process in a group at once — the way a shell kills an entire pipeline when you press Ctrl+C.

When kill -9 does not work

• A zombie (Z in ps). It is already dead; no signal removes it. Its parent has to call wait() on it, which usually happens on its own. If the parent itself is stuck, kill or restart the parent instead.
• Stuck in uninterruptible sleep (D in ps). The process is waiting on the kernel, usually for disk or network I/O (NFS is the classic case), and cannot respond to any signal, including SIGKILL, until that I/O returns. Check vmstat 1 for a stuck disk, or wait for the mount to recover.
• Not your process. Without sudo, kill only reaches processes your own user owns; it answers Operation not permitted on anyone else’s. Root can kill anything except PID 1 and other kernel threads.

If a runaway process is what pushed the load up in the first place, VPS high CPU usage covers finding it with top and vmstat before you reach for kill at all. If you are trying to free a port for a different service, the open port checker confirms from outside whether it is actually free afterwards.

Frequently asked