Unix Exit Codes Reference

Search Unix and Linux process exit codes with POSIX and bash meanings.

Reference for Unix process exit codes including POSIX conventions, bash special codes (126, 127, 128+N) and the sysexits.h values (64-78). Searchable and runs entirely in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What does exit code 0 mean?

Exit code 0 means success — the command completed without error. By Unix convention any non-zero value indicates failure, which is why shell tests like if command; then treat 0 as true.

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 codeSignalTypical cause
130SIGINT (2)User pressed Ctrl+C
137SIGKILL (9)Forced kill, often the Linux OOM killer
139SIGSEGV (11)Segmentation fault
143SIGTERM (15)Clean termination request (e.g. systemd stop)
129SIGHUP (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:

CodeNameMeaning
64EX_USAGECommand line usage error
65EX_DATAERRBad input data
66EX_NOINPUTCannot open input
67EX_NOUSERAddress unknown
68EX_NOHOSTHost name unknown
69EX_UNAVAILABLEService unavailable
70EX_SOFTWAREInternal software error
71EX_OSERRSystem error
73EX_CANTCREATCan’t create (user) output file
75EX_TEMPFAILTemp failure; user can retry
78EX_CONFIGConfiguration 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.