What is the difference between SIGTERM and SIGKILL?

SIGTERM (15) is a polite termination request that a process can catch to clean up before exiting, and is what kill sends by default. SIGKILL (9) forces immediate termination and cannot be caught, blocked or ignored, so the process gets no chance to clean up.

Which signals cannot be caught?

Only two: SIGKILL (9) and SIGSTOP (19). They cannot be caught, blocked or ignored, which guarantees the kernel can always terminate or suspend a process regardless of its handlers.

How do exit codes relate to signals?

When a process is killed by a signal, the shell reports an exit code of 128 plus the signal number. So a process killed by SIGKILL (9) exits with 137, and one interrupted by SIGINT (2) exits with 130.

Are signal numbers the same on every system?

The low signals (SIGKILL 9, SIGTERM 15, SIGINT 2) are consistent, but some numbers differ across architectures and operating systems. Always refer to a signal by name in portable code rather than by its raw number.

Is anything I search uploaded?

No. The signal table and the search run entirely in your browser, so nothing you type is sent anywhere.

What is the Unix Signals Reference?

Complete reference for Unix and Linux signals — names, numbers, default actions (terminate, core, stop, continue, ignore) and whether each can be caught. Searchable, runs in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

Unix Signals Reference

Name: Unix Signals Reference
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

This is a searchable reference for Unix and Linux signals — the asynchronous notifications the kernel and processes use to communicate events like interrupts, faults and termination requests. Each entry gives the number, the symbolic name, the default disposition if no handler is installed, and whether the signal can be caught.

How it works

A signal is delivered to a process by number; the C library maps names like SIGTERM to those numbers. If the process has no handler, the kernel applies the default action: Terminate (end the process), Core dump (end and write a core file), Stop (suspend), Continue (resume a stopped process), or Ignore. A process can install a handler for most signals, but SIGKILL (9) and SIGSTOP (19) are special — they cannot be caught, blocked or ignored, so the kernel can always force termination or suspension. Search by number, by name (the SIG prefix is optional), by action or by keyword.

Common signals you send manually

Signal	Number	Default action	Catchable	Typical use
SIGHUP	1	Terminate	Yes	Reload daemon config
SIGINT	2	Terminate	Yes	Ctrl+C in terminal
SIGQUIT	3	Core dump	Yes	Ctrl+\ — quit with core
SIGKILL	9	Terminate	No	Force kill (no cleanup)
SIGTERM	15	Terminate	Yes	Polite kill (default for `kill`)
SIGTSTP	20	Stop	Yes	Ctrl+Z — suspend
SIGCONT	18	Continue	Yes	Resume a stopped process
SIGUSR1	10	Terminate	Yes	Application-defined
SIGUSR2	12	Terminate	Yes	Application-defined

Fault signals you see in crashes

Signal	Number	Cause
SIGSEGV	11	Segmentation fault — invalid memory access
SIGBUS	7	Bus error — misaligned memory access
SIGFPE	8	Floating-point exception (including integer divide-by-zero)
SIGABRT	6	Abort — process called `abort()` directly
SIGILL	4	Illegal instruction
SIGTRAP	5	Debugger breakpoint / trace trap

Shell examples and exit codes

A process terminated by a signal exits with code 128 + signal_number. This is how the shell distinguishes signal deaths from normal non-zero exits:

$ kill -TERM 4321     # ask process 4321 to shut down gracefully
$ kill -9 4321        # force kill if it ignores SIGTERM
$ echo $?             # a process killed by signal 9 exits 137 (128 + 9)
$ sleep 60 &          # start background process
$ kill -SIGTSTP $!    # suspend it (Ctrl+Z equivalent)
$ kill -CONT $!       # resume it

Using SIGHUP for config reloads

Many Unix daemons — nginx, OpenSSH sshd, syslog, Postfix — treat SIGHUP as a signal to reload their configuration without restarting. This avoids dropping active connections. Check your daemon’s documentation to confirm it handles SIGHUP this way; the default action is termination, so a daemon that has not registered a SIGHUP handler will simply die.

Always try SIGTERM first and wait a few seconds before escalating to SIGKILL. SIGKILL gives the process no chance to flush buffers, release locks, or remove temporary files.

Everything in this tool runs in your browser; nothing is uploaded.