Unix signals list (most common to rare)

A signal is the OS sending an asynchronous “event” to a process.

If you build web apps, you still end up dealing with signals, because deploys, restarts, crashes, and “why did my process die?” all pass through this layer.

One important constraint up front: the exact list of signals can vary by OS (Linux vs macOS vs BSDs). This is a field guide to the common Unix/POSIX ones you’ll actually see, plus a few rarer ones that show up in incident writeups.

Quick index (most common → less common)

• SIGTERM, SIGKILL, SIGINT, SIGHUP, SIGQUIT
• SIGABRT, SIGSEGV, SIGPIPE, SIGCHLD
• SIGALRM, SIGUSR1, SIGUSR2
• SIGSTOP, SIGTSTP, SIGCONT, SIGTTIN, SIGTTOU
• SIGFPE, SIGILL, SIGBUS, SIGTRAP, SIGSYS
• SIGURG, SIGWINCH, SIGXCPU, SIGXFSZ, SIGVTALRM, SIGPROF, SIGPOLL / SIGIO

Two rules that explain 80% of behavior

1. Some signals can be handled (the process runs a handler) or ignored.
2. Some signals cannot be caught or ignored. The two that matter most: SIGKILL and SIGSTOP.

If you remember only that, you can already make sense of a lot of production logs.

SIGTERM

The “please shut down” signal. This is what supervisors and orchestrators prefer to send first.

By default it terminates the process, but well-behaved servers install a handler and treat it as a cue to do a graceful shutdown (stop accepting new work, drain, exit cleanly).

SIGKILL

The “stop right now” signal. Cannot be handled. Cannot be ignored.

If you see Killed with no stack trace, or a container/runtime reports the process was killed, SIGKILL is a common explanation. It’s also a common escalation step after a graceful shutdown timeout.

SIGINT

The “interrupt” signal. Most commonly from Ctrl+C in a terminal.

In production it’s less common, but it shows up when operators manually stop something, or when tooling behaves like an interactive interrupt.

SIGHUP

Historically “hang up” (terminal disconnected). Today it’s often used as “reload configuration” for daemons, but there’s no universal meaning.

If a process is tied to a terminal/session and that session ends, SIGHUP can be part of why it terminates (unless managed by a supervisor).

SIGQUIT

Like SIGINT, but “quit (and usually a diagnostic dump)”.

Many runtimes treat this as a request to exit and produce a more detailed diagnostic dump than SIGINT would.

SIGABRT

Abort. Often triggered by the process itself (e.g., calling abort()), typically because the program detected an unrecoverable condition.

In practice, SIGABRT often means “the program chose to crash rather than keep running incorrectly”.

SIGSEGV

Segmentation fault. Invalid memory access.

For application engineers this often shows up as “the process died, and it wasn’t a normal exception” (native code, a runtime bug, unsafe code, or a corrupted memory situation).

SIGPIPE

“Write to a pipe or network socket with no reader”.

Common scenario: your program writes to stdout/stderr (or a network socket) but the other side is gone, and the OS raises SIGPIPE. Some programs ignore SIGPIPE and instead handle a write error. Others die.

SIGCHLD

Child status changed.

If your process starts subprocesses, SIGCHLD is how the OS tells you “a child exited/stopped/continued”. Most applications don’t handle this directly. They rely on libraries, but it matters for process supervisors and anything that spawns workers.

SIGALRM

Alarm clock. Sent when a timer expires (classic alarm() APIs).

You might not see SIGALRM directly in modern app code, but it appears in legacy systems and some timeout implementations.

SIGUSR1

“User-defined” signal 1. Meaning is application-specific.

Common uses: reload, rotate logs, dump internal state, toggle debug.

SIGUSR2

“User-defined” signal 2. Same story as SIGUSR1: your system defines what it means.

SIGSTOP

Stop (pause) the process. Cannot be handled. Cannot be ignored.

This is like hitting a hard pause button: execution stops until a SIGCONT resumes it. Debuggers and job control use this kind of mechanism.

SIGTSTP

Terminal stop. This is what Ctrl+Z typically sends in a shell.

Unlike SIGSTOP, it can be handled, but in normal interactive use it suspends the process and returns you to the shell.

SIGCONT

Continue. Used to resume a stopped process (after SIGSTOP/SIGTSTP).

SIGTTIN

Background process tried to read from terminal.

This is mostly “shell job control” territory, but it explains why a background process might suddenly stop.

SIGTTOU

Background process tried to write to terminal (or change terminal settings).

Again: job control behavior that’s confusing if you’ve never seen it.

SIGFPE

Floating-point exception (e.g., division by zero) or related arithmetic fault.

In higher-level languages this is usually turned into an exception, but native code can still hit SIGFPE.

SIGILL

Illegal instruction.

This can mean “the CPU can’t execute this instruction”, often due to corrupted code, wrong binaries for the architecture, or executing data as code.

SIGBUS

Bus error.

Often related to invalid memory access patterns (alignment issues) or certain kinds of memory-mapped I/O failures. Rarer than SIGSEGV in most app-level work, but it exists in real incident reports.

SIGTRAP

Trap.

Used by debuggers and instrumentation. It also shows up for deliberate “breakpoint” behavior.

SIGSYS

Bad system call.

Usually means the process attempted a syscall that is invalid/blocked (for example by a sandbox/seccomp-like policy). Not common day-to-day, but useful to recognize.

SIGURG

Urgent condition on a network socket.

Rare in typical application work. Used for certain networking edge cases.

SIGWINCH

Window changed.

Sent to terminal applications when the terminal window size changes. You’ll see it in interactive programs (editors, TUI apps).

SIGXCPU

CPU time limit exceeded.

If the OS enforces CPU time limits on a process and it exceeds them, SIGXCPU can be the warning shot.

SIGXFSZ

File size limit exceeded.

Sent when a process exceeds a configured file size limit (ulimits). Not everyday, but it’s very diagnostic when it happens.

SIGVTALRM

Virtual timer alarm.

Timer based on the process’s CPU time (not wall-clock). Mostly seen with profilers and special timing setups.

SIGPROF

Profiling timer expired.

Also tends to show up in profiling/instrumentation contexts.

SIGPOLL / SIGIO

I/O possible (or pollable event).

Some systems use SIGIO for asynchronous I/O notifications. Many modern stacks prefer event loops and polling APIs instead of signals, so you may never see this unless you’re deep in systems/networking.

That’s it, may the force be with you!