Right, let’s talk about process assassination. You’ve got a misbehaving program, a script that’s hung, or a service you need to tell to re-read its config files. You don’t just yank the power cord; you send a signal. That’s what kill, killall, and pkill are for. They’re your tools for sending polite (or… less polite) notes to other processes. Think of them as the difference between tapping a colleague on the shoulder and setting their desk on fire.

First, a crucial point everyone misses until it’s too late: kill isn’t named for murder; it’s named for sending signals. The most common signal just happens to be the one that tells a process to terminate. The name is a bit of Unix drama.

The Kill Basics: It’s All About the Signal

The basic syntax is kill [OPTION]... PID.... You specify a signal (using a number or a name) and at least one Process ID. The default signal if you don’t specify one? It’s SIGTERM (signal number 15). This is the polite request. It says, “Hey, could you please shut yourself down? Clean up your memory, close your files, you know the drill.”

But sometimes polite doesn’t cut it.

# The gentle nudge. Please stop.
kill 4242

# The exact same thing, but explicitly saying SIGTERM
kill -15 4242
kill -SIGTERM 4242

# The sledgehammer. Stop. Now.
kill -9 4242
kill -SIGKILL 4242

Ah, SIGKILL (9). The infamous “kill -9”. It doesn’t ask. It tells the operating system kernel to immediately destroy the process. The process never sees it coming. There’s no cleanup, no saving state, no running finally blocks. It’s just gone. This is why you use it as a last resort—it can leave temporary files lying around, corrupt data, or just generally be a messy way to end things. If your first instinct is always kill -9, you’re not solving the problem; you’re just hiding the body and hoping no one asks questions.

killall: Murder by Name

Typing kill and a PID is fine, but sometimes you want to kill all processes with a specific name. Maybe 15 different python processes have gone haywire. This is where killall shines. It does exactly what its slightly terrifying name suggests.

# Politely ask all 'nginx' worker processes to terminate
killall nginx

# Forcefully kill all processes named 'my_crappy_script.py'
killall -9 my_crappy_script.py

# Send the SIGHUP signal to all 'syslogd' processes
# (often used to tell daemons to reload their configuration)
killall -HUP syslogd

WARNING: killall on some older Unix systems (like HP-UX) would literally kill all processes. Thankfully, on Linux and modern BSD/macOS, it just kills processes matching that name. Still, double-check your typing. killall -9 bash when you meant killall -9 bash_script is a great way to have a really bad time.

pkill: The Precision Targeting Tool

This is the most powerful and therefore most dangerous of the trio. pkill uses pattern matching against the process name and other attributes, not just the exact name. It’s like killall got a PhD in finding things to kill.

# Kill any process whose name contains 'python'
pkill python

# Kill a process running as user 'jim' that has 'redis' in its name
pkill -u jim redis

# Kill a process based on the exact full command line, not just the process name
pkill -f "/usr/bin/python3 my_long_script.py"

The -f flag is a game-changer and a foot-gun. It matches against the entire command line used to launch the process, not just the short name. This is incredibly useful for targeting a specific script instance, but use it with care. Always test your pattern with pgrep -f first to see what it would kill before you unleash pkill.

# SAFETY FIRST: See what the pattern matches
pgrep -fl "python3"

# Now you can kill with confidence
pkill -f "python3 my_specific_script.py"

Best Practices and Pitfalls

  1. Try TERM First, KILL Last: Your default should always be kill <PID> or killall <name>. Only escalate to -9 if the process is ignoring the polite request. A process might be stuck in a cleanup operation, and giving it a second might prevent data loss.

  2. You Can Only Kill What You Own: As a regular user, you can’t just go around killing processes owned by root (and vice versa, thankfully). This is the system protecting itself from you. You’ll get an Operation not permitted error.

  3. Zombie Processes Are Already Dead: If you see a process with a state of Z (zombie), sending kill -9 to it is like trying to kill a ghost. It’s already dead. Its parent process just hasn’t acknowledged the death yet. You need to kill the parent process to clear the zombie.

  4. Signals Are a Language: SIGTERM and SIGKILL are just two of many signals. SIGHUP (hangup) often means “reload,” SIGUSR1 and SIGUSR2 are user-defined signals that a program can interpret however it wants (like telling nginx to reopen log files). The real pros know how to use the whole vocabulary. Check a program’s documentation to see what signals it listens for.

So there you have it. kill for precision, killall for broad strokes by name, and pkill for surgical strikes with pattern matching. Wield them wisely, and always know that with great power comes the great responsibility to not accidentally log yourself out.