Linux Signal Reference

Complete Linux and POSIX signal reference — every signal with its number (x86/most architectures), default action (Term, Core, Ign, Stop, Cont), catchability, and a practical description. Explains the critical difference between SIGTERM (graceful shutdown) and SIGKILL (forced, uncatchable). Search by name, number, or keyword.

How to use the Linux Signal Reference

Type in the search box to filter signals by name (e.g. SIGTERM), number (e.g. 9), default action (e.g. Core), or any keyword in the description (e.g. broken pipe). The table updates instantly as you type — clear the search to see all signals.

Each row shows the signal name, its number on x86/x86-64 and most architectures (SPARC, MIPS, Alpha may differ), the default action taken if the signal is not caught (Term = terminate, Core = terminate + core dump, Ign = ignore, Stop = stop/suspend, Cont = resume), whether the signal can be caught by a signal handler, and a description of when it is typically sent.

SIGKILL (9) and SIGSTOP (19) are highlighted because they cannot be caught or ignored — the kernel always handles them directly. Every other signal can be caught with trap in Bash or signal()/sigaction() in C.

SIGTERM vs SIGKILL — and When to Use Each

Signals are the Unix IPC mechanism for asynchronous notification between processes. When you press Ctrl+C in a terminal, the kernel sends SIGINT (2) to the foreground process group. When a process calls exit(), the kernel sends SIGCHLD (17) to its parent. The kill command (despite its name) sends any signal to a named process — kill -15 PID sends SIGTERM, kill -9 PID sends SIGKILL.

SIGTERM (15) is the polite shutdown signal. Well-written daemons and services catch it, flush buffers, close database connections, write PID files, finish in-flight requests, and then exit cleanly. Docker's docker stop, systemd's systemctl stop, and Kubernetes pod termination all start with SIGTERM and wait a configurable grace period (default 30 s in both Docker and Kubernetes). If the process has not exited by then, they escalate to SIGKILL. Most production service crashes that leave "unclean shutdown" log entries are caused by being hit with SIGKILL before cleanup finished.

SIGKILL (9) is the unconditional kill. The kernel terminates the process immediately; no user-space code runs. The process cannot catch it, block it, or ignore it. Use SIGKILL only as a last resort: after SIGTERM has been sent and the process failed to exit within the grace period. Sending SIGKILL to a database without SIGTERM first can corrupt on-disk state if write-ahead logging or journaling was not flushed. Core-dumping signals (SIGQUIT, SIGILL, SIGSEGV, SIGFPE, SIGABRT, SIGBUS) generate a core file for post-mortem analysis with gdb — useful for debugging crashes in C/C++ programs.

Common use cases

• Container orchestration — understand why Kubernetes sends SIGTERM first and why your ENTRYPOINT must handle it to achieve graceful shutdown.
• Service debugging — look up which signal caused a process exit by checking exit codes (128+signal) in systemd journal or container logs.
• Shell scripting with trap — look up signal names to write correct trap cleanup SIGTERM SIGINT SIGQUIT EXIT handlers in scripts.
• Core dump analysis — identify whether a crash produced a core dump (SIGSEGV, SIGABRT, SIGFPE) vs a clean termination before starting gdb.
• Process supervision — reference signal semantics when configuring supervisord, runit, or s6 restart policies and kill sequences.