Unix Exit Code Reference

Look up any Linux or Bash exit code and understand what it means. Covers the standard codes (0 success, 1 general error, 126, 127), the 128+signal convention that explains codes like 130 (Ctrl+C), 137 (OOM kill), and 139 (segfault), and includes a live code decoder — type any number and get an immediate explanation.

How to use the Unix Exit Code Reference

Use the Decode a code input at the top: type any exit code (0–255) and the tool immediately explains it — including decoding 128+n codes to their corresponding signal name (e.g. type 137 and see "killed by SIGKILL (9) — often OOM killer or explicit kill -9").

Below the decoder, the search box filters the full reference table by code number, meaning string, or any keyword in the description. Clearing the search shows all entries.

The reference table covers every meaningful exit code category: success (0), generic errors (1, 2), shell built-in misuse (2), permission/not-executable (126), command not found (127), invalid exit argument (128), and the full 128+n signal-death range with the most common specific values called out explicitly.

The 128+Signal Convention Explained

When a Unix process terminates due to a signal, the shell that launched it reports an exit code equal to 128 plus the signal number. This is a convention established in POSIX and implemented in bash, dash, zsh, and most other POSIX shells. The value 128 is chosen because it is above the range of normal application exit codes (0–125), making signal-death codes distinguishable from application-defined errors.

The most important specific values: 130 = 128+2 (SIGINT) — the user pressed Ctrl+C; 137 = 128+9 (SIGKILL) — the process was forcibly killed, most often by the Linux OOM killer when the system ran out of memory, or by kill -9; 139 = 128+11 (SIGSEGV) — the process crashed with a segmentation fault (invalid memory access); 143 = 128+15 (SIGTERM) — the process received a graceful shutdown request and did not install a handler for it.

Exit code 126 and 127 are often confused. 126 means the file was found but could not be executed — typically a permissions problem (the file is not marked executable: chmod +x fixes it). 127 means the command was not found at all — either a typo, or the binary is not in the shell's $PATH. Both are set by the shell itself, not by the program. Exit code 255 signals that a process called exit(-1) or another out-of-range value; since exit codes are unsigned 8-bit integers, -1 wraps to 255.

Common use cases

  • CI/CD debugging — a pipeline step exits 137 and you need to know whether it was OOM-killed or a deliberate kill before deciding whether to increase memory limits.
  • Script error handling — write correct if [ $? -eq 126 ]; then branches by looking up which codes mean permission vs not-found vs crashed.
  • Container debugging — docker inspect --format=\'{{.State.ExitCode}}\' container-name returns a number; decode it here to understand what happened.
  • Kubernetes pod crashes — exit code in kubectl describe pod output explains whether the container OOM-crashed (137), segfaulted (139), or exited cleanly with an app error (non-zero, non-128).
  • Shell scripting education — understand the range of exit codes a script can set and what values are reserved or conventionally meaningful.

Frequently asked questions

Can I use any exit code 1-125 in my own scripts?
Codes 1 and 2 are conventionally reserved (1 = generic error, 2 = misuse). Codes 3–125 are available for application-defined meanings. Many tools define specific codes (e.g. grep returns 1 when there are no matches, 2 on error). Document your codes if you use a non-zero, non-1 value.

Why does exit code 1 appear for so many different errors?
Exit code 1 is the default "something went wrong" code. Many programs, shells, and scripts use it as a catch-all when they detect an error but do not need to distinguish further. It is not meaningful without looking at the stderr output that accompanied it.

How do I check the exit code of the last command in Bash?
echo $? immediately after a command prints its exit code. In a script, capture it with status=$? right after the command, before any other command resets $?. The set -e option makes the script exit on any non-zero exit code automatically.

What causes exit code 137 specifically — OOM killer or kill -9?
Both produce 137 (128+SIGKILL). To distinguish: check dmesg | grep -i "killed process" for OOM killer messages, or check journalctl -k. The OOM killer logs the process name and memory stats. A manual kill -9 leaves no kernel log.

Why is exit code 255 special?
Exit codes are stored as unsigned 8-bit integers (0–255). If a process calls exit(-1), the value wraps around to 255. Some tools (like ssh) use 255 as their own "connection or protocol error" code, distinct from any remote exit code.