Are there any standard exit status codes in Linux?

Part 1: Advanced Bash Scripting Guide

As always, the Advanced Bash Scripting Guide has great information: (This was linked in another answer, but to a non-canonical URL.)

1: Catchall for general errors
2: Misuse of shell builtins (according to Bash documentation)
126: Command invoked cannot execute
127: "command not found"
128: Invalid argument to exit
128+n: Fatal error signal "n"
255: Exit status out of range (exit takes only integer args in the range 0 - 255)

Part 2: sysexits.h

The ABSG references sysexits.h.

On Linux:

$ find /usr -name sysexits.h
/usr/include/sysexits.h
$ cat /usr/include/sysexits.h

/*
 * Copyright (c) 1987, 1993
 *  The Regents of the University of California.  All rights reserved.

 (A whole bunch of text left out.)

#define EX_OK           0       /* successful termination */
#define EX__BASE        64      /* base value for error messages */
#define EX_USAGE        64      /* command line usage error */
#define EX_DATAERR      65      /* data format error */
#define EX_NOINPUT      66      /* cannot open input */    
#define EX_NOUSER       67      /* addressee unknown */    
#define EX_NOHOST       68      /* host name unknown */
#define EX_UNAVAILABLE  69      /* service unavailable */
#define EX_SOFTWARE     70      /* internal software error */
#define EX_OSERR        71      /* system error (e.g., can't fork) */
#define EX_OSFILE       72      /* critical OS file missing */
#define EX_CANTCREAT    73      /* can't create (user) output file */
#define EX_IOERR        74      /* input/output error */
#define EX_TEMPFAIL     75      /* temp failure; user is invited to retry */
#define EX_PROTOCOL     76      /* remote error in protocol */
#define EX_NOPERM       77      /* permission denied */
#define EX_CONFIG       78      /* configuration error */

#define EX__MAX 78      /* maximum listed value */

None of the older answers describe exit status 2 correctly. Contrary to what they claim, status 2 is what your command line utilities actually return when called improperly. (Yes, an answer can be nine years old, have hundreds of upvotes, and still be wrong.)

Here is the real, long-standing exit status convention for normal termination, i.e. not by signal:

• Exit status 0: success
• Exit status 1: "failure", as defined by the program
• Exit status 2: command line usage error

For example, diff returns 0 if the files it compares are identical, and 1 if they differ. By long-standing convention, unix programs return exit status 2 when called incorrectly (unknown options, wrong number of arguments, etc.) For example, diff -N, grep -Y or diff a b c will all result in $? being set to 2. This is and has been the practice since the early days of Unix in the 1970s.

The accepted answer explains what happens when a command is terminated by a signal. In brief, termination due to an uncaught signal results in exit status 128+[<signal number>. E.g., termination by SIGINT (signal 2) results in exit status 130.

Notes

1. Several answers define exit status 2 as "Misuse of bash builtins". This applies only when bash (or a bash script) exits with status 2. Consider it a special case of incorrect usage error.

2. In sysexits.h, mentioned in the most popular answer, exit status EX_USAGE ("command line usage error") is defined to be 64. But this does not reflect reality: I am not aware of any common Unix utility that returns 64 on incorrect invocation (examples welcome). Careful reading of the source code reveals that sysexits.h is aspirational, rather than a reflection of true usage:

    *    This include file attempts to categorize possible error
    *    exit statuses for system programs, notably delivermail
    *    and the Berkeley network.
   
    *    Error numbers begin at EX__BASE [64] to reduce the possibility of 
    *    clashing with oth­er exit statuses that random programs may 
    *    already return. 
   

   In other words, these definitions do not reflect the common practice at the time (1993) but were intentionally incompatible with it. More's the pity.

'1': Catch-all for general errors

'2': Misuse of shell builtins (according to Bash documentation)

'126': Command invoked cannot execute

'127': "command not found"

'128': Invalid argument to exit

'128+n': Fatal error signal "n"

'130': Script terminated by Ctrl + C

'255': Exit status out of range

This is for Bash. However, for other applications, there are different exit codes.

There are no standard exit codes, aside from 0 meaning success. Non-zero doesn't necessarily mean failure either.

Header file stdlib.h does define EXIT_FAILURE as 1 and EXIT_SUCCESS as 0, but that's about it.

The 11 on segmentation fault is interesting, as 11 is the signal number that the kernel uses to kill the process in the event of a segmentation fault. There is likely some mechanism, either in the kernel or in the shell, that translates that into the exit code.

Header file sysexits.h has a list of standard exit codes. It seems to date back to at least 1993 and some big projects like Postfix use it, so I imagine it's the way to go.

From the OpenBSD man page:

According to style(9), it is not good practice to call exit(3) with arbitrary values to indicate a failure condition when ending a program. Instead, the predefined exit codes from sysexits should be used, so the caller of the process can get a rough estimation about the failure class without looking up the source code.

To a first approximation, 0 is success, non-zero is failure, with 1 being general failure, and anything larger than one being a specific failure. Aside from the trivial exceptions of false and test, which are both designed to give 1 for success, there's a few other exceptions I found.

More realistically, 0 means success or maybe failure, 1 means general failure or maybe success, 2 means general failure if 1 and 0 are both used for success, but maybe success as well.

The diff command gives 0 if files compared are identical, 1 if they differ, and 2 if binaries are different. 2 also means failure. The less command gives 1 for failure unless you fail to supply an argument, in which case, it exits 0 despite failing.

The more command and the spell command give 1 for failure, unless the failure is a result of permission denied, nonexistent file, or attempt to read a directory. In any of these cases, they exit 0 despite failing.

Then the expr command gives 1 for success unless the output is the empty string or zero, in which case, 0 is success. 2 and 3 are failure.

Then there's cases where success or failure is ambiguous. When grep fails to find a pattern, it exits 1, but it exits 2 for a genuine failure (like permission denied). klist also exits 1 when it fails to find a ticket, although this isn't really any more of a failure than when grep doesn't find a pattern, or when you ls an empty directory.

So, unfortunately, the Unix powers that be don't seem to enforce any logical set of rules, even on very commonly used executables.

Programs return a 16 bit exit code. If the program was killed with a signal then the high order byte contains the signal used, otherwise the low order byte is the exit status returned by the programmer.

How that exit code is assigned to the status variable $? is then up to the shell. Bash keeps the lower 7 bits of the status and then uses 128 + (signal nr) for indicating a signal.

The only "standard" convention for programs is 0 for success, non-zero for error. Another convention used is to return errno on error.

Standard Unix exit codes are defined by sysexits.h, as David mentioned. The same exit codes are used by portable libraries such as Poco - here is a list of them:

Class Poco::Util::Application, ExitCode

A signal 11 is a SIGSEGV (segment violation) signal, which is different from a return code. This signal is generated by the kernel in response to a bad page access, which causes the program to terminate. A list of signals can be found in the signal man page (run "man signal").

Some are convention, but some other reserved ones are part of POSIX standard.

126 -- A file to be executed was found, but it was not an executable utility.

127 -- A utility to be executed was not found.

>128 -- A command was interrupted by a signal.

See the section RATIONALE of man 1p exit.

The termination status of a process is 16-bit wide:

• 8 bits for the exit code

• 1 bit to point out the generation of a core file

• 7 bits for the termination signal number

The above exit code and termination signal number are exclusive as a process ends either by an exit or by the receipt of an uncaught signal.

In C/C++ applications, the status of a terminated process can be obtained with services like wait() or waitpid(). And the status content can be analyzed with dedicated macros described in the latter manpage: WIFEXITED(), WIFSIGNALED(), ...

According to the preceding, the exit code being 8-bit wide, must have the values: 0 ≤ exit code ≤ 255. Moreover, the exit code 0 is used to report a successful execution and any other value is used to denote an error. Negative values are forbidden or at least would result in misleading status as only the 8 bits of the LSB byte would be used to fill the exit code part of the status. For example, a program calling exit with -255 would result with an exit code equal to 1 as -255 is coded 0xFFFFFF01 (in a 32-bit system).

There are some other considerations to take in account.

In the Bash shell source code, the internal shell.h header defines the following list of reserved exit codes for the interpreter itself or its built-ins:

/* Values that can be returned by execute_command (). */
#define EXECUTION_FAILURE 1c
#define EXECUTION_SUCCESS 0

/* Usage messages by builtins result in a return status of 2. */
#define EX_BADUSAGE 2

#define EX_MISCERROR    2

/* Special exit statuses used by the shell, internally and externally. */
#define EX_RETRYFAIL    124
#define EX_WEXPCOMSUB   125
#define EX_BINARY_FILE  126
#define EX_NOEXEC   126
#define EX_NOINPUT  126
#define EX_NOTFOUND 127

So, in projects mixing C or C++ code and shell scripts, it may be useful to differentiate exit codes from shell and from compiled code. Hence, the range of values [124,127] should not be used as exit codes in C or C++ applications.

In the shell, the status of a command (built-in or any program) is obtained with $? . The latter is set as follow

• If the command exited: $? = exit code

• If the command was interrupted by an uncaught signal: $? = 128+signal number

So, at status analysis time, if we want to discriminate exited commands from "interrupted by signal" commands, an exit code must not be bigger than 128.

As a summary, to have programs cohabit properly with shell, the exit code range should be:

• 0 ≤ exit code ≤ 123. The value 0 denotes a successful execution. Any other value denotes an error.

• The values 124 to 127 are used by the shell itself.

• The values bigger than 128 are used by the shell internals to point out a signal receipt (the received signal number being: $? - 128).

When Linux returns 0, it means success. Anything else means failure. Each program has its own exit codes, so it would been quite long to list them all...!

About the 11 error code, it's indeed the segmentation fault number, mostly meaning that the program accessed a memory location that was not assigned.