person Tute World Team schedule Updated April 28, 2026

Linux Signals

Signals are the simplest form of inter-process communication in Linux — a way for the kernel or another process to say "hey, something happened" to a process. The kill command is misleadingly named; it actually sends any signal, not just the killing kind.

What is a Signal?

A signal is an asynchronous notification sent to a process. When a signal arrives, the process's normal execution is interrupted and a signal handler runs. Signals are identified by number or name.

# List all signals
kill -l

# Send signal by number
kill -9 1234     # SIGKILL
kill -15 1234    # SIGTERM (default when you just run: kill 1234)

# Send signal by name
kill -SIGTERM 1234
kill -HUP 1234   # reload config

The Most Important Signals

Signal	Number	Default Action	Common Use
SIGTERM	15	Terminate gracefully	Normal shutdown — process can catch and clean up
SIGKILL	9	Terminate immediately	Force kill — cannot be caught, blocked, or ignored
SIGHUP	1	Terminate (or reload)	Tell daemon to reload config (nginx, sshd)
SIGINT	2	Terminate	Ctrl+C in terminal
SIGQUIT	3	Terminate + core dump	Ctrl+\\ — like SIGINT but dumps memory
SIGSTOP	19	Pause process	Uncatchable pause
SIGCONT	18	Resume process	Resume after SIGSTOP or SIGTSTP
SIGTSTP	20	Pause process	Ctrl+Z — catchable
SIGCHLD	17	Ignored	Child process state changed
SIGSEGV	11	Terminate + core dump	Segmentation fault — invalid memory access
SIGUSR1/2	10/12	Terminate	Application-defined (e.g., toggle debug logging)

Catching Signals in Shell Scripts

#!/bin/bash
# Catch SIGTERM and clean up before exiting
cleanup() {
    echo "Cleaning up..."
    rm -f /tmp/myapp.lock
    exit 0
}

trap cleanup SIGTERM SIGINT

echo "Running... PID=$$"
while true; do
    sleep 1
done

Why SIGKILL Cannot Be Caught

Why is SIGKILL special? SIGKILL is handled entirely by the kernel — it never reaches the process's signal handler. The kernel forcibly terminates the process and reclaims its resources. This is why a process stuck in D state (uninterruptible sleep) can't be killed even with SIGKILL — the kernel handles signals only when returning from kernel space, which a D-state process isn't doing.

Best practice: always try SIGTERM first and wait a few seconds. Only escalate to SIGKILL if the process doesn't respond.

# Graceful shutdown pattern
kill -TERM 1234
sleep 5
kill -0 1234 2>/dev/null && kill -KILL 1234  # force if still alive

Frequently Asked Questions

What will I learn here?

This page covers the core concepts and techniques you need to understand the topic and progress confidently to the next lesson.

How should I use this page?

Start with the overview, then follow the section links to deepen your understanding. Use the table of contents on the right to jump to specific sections.

What should I read next?

Use the navigation below to continue to the next lesson or explore related topics.