⚡ Process Signal Reference

🖥️ Platform

Signal names are portable, but signal numbers differ between Linux x86/x86_64 and BSD-family systems (macOS, FreeBSD).

🏷️ Category

Filter the signal list by default action.

🔍 Search

Matches signal name, short name (omit "SIG"), number, description, default action, or sender. A purely numeric query is matched exactly against the signal number.

📊 Status

{{ statusMessage }}

📤 Signals

Name # Default
{{ sig.name }} {{ sig.number }} {{ sig.default }}
No signals match the current filter. Try clearing the search box or switching the category to "All".

{{ selectedSignal.name }} ({{ selectedSignal.number }})

Default: {{ selectedSignal.default }}

{{ selectedSignal.description }}

Common senders
  • {{ s }}
What handlers usually do

{{ selectedSignal.traps }}

kill syntax
{{ selectedSignal.examples.kill }}
trap syntax (shell)
{{ selectedSignal.examples.trap }}
Notes

{{ selectedSignal.notes }}

Click any row above to see kill / trap syntax, common senders, and notes for that signal.
⚠️

ℹ️ About Process Signal Reference

What process signals are

A signal is the kernel's way of interrupting a running process to deliver a short, asynchronous notification — "your timer fired", "your child exited", "your terminal disconnected", "please shut down". The signal carries no payload beyond its number; the receiving process either uses the kernel's default action or installs a handler (via sigaction(2) in C, trap in shell, or signal.signal() in Python) that runs the next time it is safe to do so.

The signal table is part of POSIX.1-2017 (§10.17) and is implemented in roughly the same form by every Unix-like system: Linux, macOS, FreeBSD, OpenBSD, Solaris, AIX. The names are portable (SIGTERM, SIGKILL, SIGHUP …); the numbers mostly are not — macOS and FreeBSD, for example, use a different number for SIGUSR1 than Linux x86 does. Use the platform toggle below to switch between the architectures.

Three signals every developer should know

  • SIGTERM (15) — the polite "please shut down" signal. Sent by default by kill(1), pkill(1), systemctl stop, docker stop, and Kubernetes pre-stop. Trap it to flush buffers, close connections, save state, then exit(0).
  • SIGKILL (9) — the unconditional, uncatchable, unblockable terminator. The kernel reaps the process without giving it a chance to clean up. Use only after SIGTERM has been ignored. Cannot be trapped.
  • SIGHUP (1) — originally "the modem hung up". Today, most long-running daemons (nginx, postgres, syslog) re-read their config on SIGHUP so the operator can change settings without restarting the service.

The kill command

Despite the name, kill(1) sends arbitrary signals — not just termination. The basic forms are:

  • kill <pid> — send SIGTERM (signal 15), the default.
  • kill -TERM <pid> — same, explicit name form.
  • kill -15 <pid> — same, numeric form.
  • kill -9 <pid> — send SIGKILL.
  • kill -HUP <pid> — reload nginx, etc.
  • kill -0 <pid> — sends nothing, but returns 0 if the pid exists and can be signalled (probe trick).
  • kill -l — list every signal supported on this system.

pkill(1) and killall(1) match processes by name instead of pid; systemctl kill --signal=HUP <unit> routes a signal through systemd's cgroup membership so children of the service receive it too.

Trapping signals in shell scripts

trap(1) installs a shell-level handler that runs when the script receives a given signal: 

trap 'echo "received SIGTERM; cleaning up"; rm -f /tmp/lock; exit 0' TERM
trap 'echo "received SIGHUP; reloading config"; reload_config' HUP
trap 'echo "received SIGINT (Ctrl-C); exiting"; exit 130' INT
trap '' PIPE                       # ignore SIGPIPE entirely
trap - TERM                        # restore the default handler

Common idiom: trap EXIT (a bash pseudo-signal) for cleanup that should run regardless of how the script ends: 

tmpdir=$(mktemp -d)
trap 'rm -rf "$tmpdir"' EXIT

Three signals that cannot be caught

  • SIGKILL (9) — cannot be caught, blocked, or ignored. The kernel kills the process without delivering anything to it.
  • SIGSTOP (19 on Linux x86, 17 on macOS/FreeBSD) — cannot be caught. The kernel suspends the process until SIGCONT arrives.
  • A signal already configured as SIG_DFL after the kernel sets it for one of the fault signals (SIGSEGV, SIGBUS, SIGILL, SIGFPE) on the offending thread can be re-raised immediately, but cannot meaningfully be "blocked".

Default action vocabulary

  • Terminate — the process exits as if by _exit(128 + signum).
  • Terminate (core dump) — terminate, and write a core file if ulimit -c permits it (useful for SIGSEGV / SIGABRT).
  • Stop — the process is suspended; it stays in memory but is not scheduled.
  • Continue — a previously stopped process resumes.
  • Ignore — the kernel discards the signal (default for SIGCHLD, SIGURG, SIGWINCH).

Use cases for this reference

  • Writing a Dockerfile and need to know the exact signal SIGTERM-then-SIGKILL grace period your service should honor.
  • Implementing graceful shutdown in a HTTP server and verifying you trap all the relevant signals (TERM, INT, HUP).
  • Debugging a "process disappeared" bug by mapping the exit code (128 + N) back to the signal that delivered it.
  • Reading core dumps — figuring out whether SIGSEGV or SIGBUS landed and what the signal handler chain was doing.
  • Writing a seccomp sandbox and routing forbidden syscalls to SIGSYS for postmortem logging.

Source references

Notes and platform caveats

  • Signal numbers below 32 are the "standard" / "traditional" signals. Linux also supports "real-time signals" SIGRTMIN..SIGRTMAX (32-64); they are out of scope here.
  • POSIX leaves SIGPWR optional — Linux ships it (number 30 on x86/x86_64), macOS and FreeBSD do not.
  • SIGUSR1/SIGUSR2, SIGCHLD, SIGSTOP, SIGTSTP, SIGCONT, SIGURG, SIGIO, and SIGSYS use different numbers on macOS / FreeBSD than on Linux x86. Use the platform toggle above to view the correct number for the system you are targeting.
  • The lookup runs entirely in your browser. The same module is exposed by the API endpoint below for headless / scripted access.

API Usage Example:

POST /api/tools/linux/process-signal-reference
Content-Type: application/json

{
    "operation": "lookup",
    "query": "term",
    "platform": "linux",
    "category": "all"
}
Ready