Killing Processes

Sending signals to processes is the Linux mechanism for inter-process communication and control. "Killing" a process is really just sending it a termination signal. Understanding the difference between signals — especially why you should try SIGTERM before SIGKILL — helps you manage processes safely without causing data corruption or incomplete shutdown.

Linux signals explained

SignalNumberDefault actionCan be caught?Use for
SIGHUP1TerminateYesReload config (many daemons use it)
SIGINT2TerminateYesInterrupt from keyboard (Ctrl+C)
SIGTERM15TerminateYesPolite shutdown request (default for kill)
SIGKILL9TerminateNOForce kill — process cannot catch or ignore
SIGSTOP19StopNOPause a process (cannot be caught)
SIGCONT18ContinueYesResume a stopped process
SIGUSR1/210/12TerminateYesApplication-defined (e.g., log rotation)

The kill command

# List all available signals
kill -l

# Send SIGTERM (15) — polite request to terminate
kill PID
kill -15 PID
kill -SIGTERM PID    # Same thing, different formats

# Send SIGKILL (9) — force terminate immediately
kill -9 PID
kill -SIGKILL PID

# Send SIGHUP — commonly used to reload config
kill -1 PID
kill -HUP PID

# Send signal to all processes in a process group (negative PID = group)
kill -TERM -PGID   # Send to entire process group
kill -TERM -$(pgrep -g processname)

# Kill multiple PIDs
kill PID1 PID2 PID3

Killing by name

# killall: send signal to processes by name
killall nginx           # SIGTERM all nginx processes
killall -9 nginx        # SIGKILL all nginx processes
killall -HUP nginx      # SIGHUP all nginx processes (reload config)

# pkill: more flexible pattern matching
pkill nginx             # Match by name (partial match)
pkill -u irfan          # Kill all processes by user irfan
pkill -f "python.*myapp"  # Match against full command line

# pgrep: find PIDs without killing (test before killing)
pgrep nginx             # Show PIDs of nginx processes
pgrep -l nginx          # Show PID + name
pgrep -u mysql          # Show all PIDs for user mysql

# xargs pattern: find PIDs with pgrep, then kill
pgrep -f "my-old-worker" | xargs kill -9

Graceful shutdown vs force kill

# Best practice: try graceful shutdown first (SIGTERM)
kill -SIGTERM PID

# Wait a moment, then check if it's gone
sleep 5
kill -0 PID 2>/dev/null && echo "Still running" || echo "Process exited"

# If still running after reasonable wait: force kill
kill -9 PID

⚠️ WARNING: kill -9 does not allow the process to flush its write buffers, complete transactions, close files cleanly, or release locks. Databases killed with SIGKILL may need recovery on next start. Web servers killed with SIGKILL may drop in-flight requests. Always try kill -15 (SIGTERM) first and give the process a few seconds to exit cleanly. Only use kill -9 if the process does not respond to SIGTERM.

# Graceful database shutdown example:
sudo systemctl stop mysql    # Systemd handles SIGTERM + waits

# If systemctl stop hangs:
sudo systemctl kill --kill-who=main --signal=SIGTERM mysql
sleep 30
sudo systemctl kill --kill-who=all --signal=SIGKILL mysql   # Last resort

When kill -9 does not work

# If kill -9 has no effect, the process is in D state (uninterruptible sleep)
ps aux | grep PID | awk '{print $8}'    # Check state — D = uninterruptible

# A process in D state is waiting for I/O and cannot be killed
# Check what it's waiting for:
sudo cat /proc/PID/wchan

# Check for I/O issues:
dmesg | grep -E "error|timeout|I/O" | tail -10
iostat -xd 2

# Resolution:
# - If NFS mount: umount -l /mnt/nfs
# - If disk I/O: check disk health with smartctl
# - Last resort: reboot (D-state processes usually resolve on reboot)

Conclusion

The correct kill sequence is: SIGTERM first, wait, then SIGKILL if necessary. Sending SIGKILL immediately is like pulling the power plug — the process cannot clean up. Use killall or pkill to kill by name rather than PID, as PIDs change and you might accidentally target the wrong process. If kill -9 has no effect, the process is in D state (waiting for I/O) and cannot be killed without fixing the underlying I/O issue or rebooting.

FAQ

Is Killing Processes important for Ubuntu administrators?+

Yes. It supports practical Ubuntu administration because it connects directly to server reliability, security, troubleshooting, or daily operations.

Should I practice this on a live server?+

Use a lab VM first. After you understand the command output and rollback path, apply the workflow carefully on real systems.

What should I do after reading this article?+

Run the practice commands, write down what each one shows, and continue to the next article in the Ubuntu roadmap.

Need help with Ubuntu administration?

Work directly with Muhammad Irfan Aslam for Ubuntu Server, Linux, cloud, Docker, DevOps, CI/CD, or infrastructure troubleshooting support.

Hire Me for Support