This is a searchable reference for Unix and Linux process exit codes — the single byte a program returns when it finishes. It combines the POSIX convention, the special codes bash assigns (126, 127, and the 128+N “killed by signal” range), and the BSD sysexits.h registry (64–78) so you can decode an exit status from any of these worlds.
How it works
An exit status is one byte, so it ranges from 0 to 255. The shell exposes it as $? after each command. Zero means success and every other value means failure. Three layers define the meanings: POSIX reserves 0 for success and treats non-zero as error; bash assigns 126 (found but not executable), 127 (command not found), and 128 + N (terminated by signal N); and sysexits.h proposes a structured set from EX_USAGE (64) to EX_CONFIG (78) for programs that want consistent, meaningful codes. Search by number, source or keyword to find the matching entry and its explanation.
Decoding signal deaths (128 + N)
When a process is killed by a signal, the shell reports 128 + signal. The most common ones you will encounter:
| Exit code | Signal | Typical cause |
|---|---|---|
| 130 | SIGINT (2) | User pressed Ctrl+C |
| 137 | SIGKILL (9) | Forced kill, often the Linux OOM killer |
| 139 | SIGSEGV (11) | Segmentation fault |
| 143 | SIGTERM (15) | Clean termination request (e.g. systemd stop) |
| 129 | SIGHUP (1) | Terminal disconnect |
To find the signal from any 128+ code: subtract 128. Then look up that signal number to understand what sent it. Exit 137 in a container environment almost always means the container ran out of memory and the OOM killer terminated the process — check your memory limits and the host’s dmesg.
The sysexits.h codes (64–78)
BSD’s sysexits.h header defines structured exit codes for programs to use instead of ad-hoc numbers. Common ones used by sendmail, ssh, and many Unix utilities:
| Code | Name | Meaning |
|---|---|---|
| 64 | EX_USAGE | Command line usage error |
| 65 | EX_DATAERR | Bad input data |
| 66 | EX_NOINPUT | Cannot open input |
| 67 | EX_NOUSER | Address unknown |
| 68 | EX_NOHOST | Host name unknown |
| 69 | EX_UNAVAILABLE | Service unavailable |
| 70 | EX_SOFTWARE | Internal software error |
| 71 | EX_OSERR | System error |
| 73 | EX_CANTCREAT | Can’t create (user) output file |
| 75 | EX_TEMPFAIL | Temp failure; user can retry |
| 78 | EX_CONFIG | Configuration error |
Practical debugging example
Reading $? after a failed command:
$ ./missing-binary
bash: ./missing-binary: No such file or directory
$ echo $?
127
Exit code 127 confirms the shell could not find the command — fix the path or install the binary.
$ cat protected-file.txt
cat: protected-file.txt: Permission denied
$ echo $?
1
Exit code 1 is a generic failure. It tells you the command ran but failed — cat itself does not use sysexits, so the full error message is what carries meaning here.
For CI/CD pipelines and shell scripts, always check $? or use set -e to abort on non-zero exits. In Docker and Kubernetes, the exit code of PID 1 becomes the container exit code and appears in kubectl describe pod or docker inspect.
Everything in this tool runs in your browser; nothing is uploaded.