Coder Perfect

In Linux, are there any standard exit status codes?


In Linux, a process is regarded to have completed successfully if its exit status is 0.

I’ve seen that segmentation faults often result in an exit status of 11, though I don’t know if this is simply the convention where I work (the apps that failed like that have all been internal) or a standard.

In Linux, are there any standard exit codes for processes?

Asked by Nathan Fellman

Solution #1

As usual, the Advanced Bash Scripting Guide is jam-packed with useful information: (Another response linked to this, but it was a non-canonical URL.)

sysexits.h is mentioned in the ABSG.

On Linux:

$ find /usr -name 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 */

Answered by Schof

Solution #2

On the return from wait(2) & co., the return code and the number of the killing signal are combined into a single value.

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
#include <signal.h>

int main() {
    int status;

    pid_t child = fork();
    if (child <= 0)
    waitpid(child, &status, 0);
    if (WIFEXITED(status))
        printf("first child exited with %u\n", WEXITSTATUS(status));
    /* prints: "first child exited with 42" */

    child = fork();
    if (child <= 0)
        kill(getpid(), SIGSEGV);
    waitpid(child, &status, 0);
    if (WIFSIGNALED(status))
        printf("second child died with %u\n", WTERMSIG(status));
    /* prints: "second child died with 11" */

What method are you using to determine the exit status? Traditionally, the shell merely maintains an 8-bit return code, however if the process was terminated abnormally, the high bit is set.

$ sh -c 'exit 42'; echo $?
$ sh -c 'kill -SEGV $$'; echo $?
Segmentation fault
$ expr 139 - 128

If you see anything else, the program most likely contains a SIGSEGV signal handler, which subsequently calls exit normally, indicating that the signal isn’t actually killing it. (Apart from SIGKILL and SIGSTOP, programs can choose to handle any signal.)

Answered by ephemient

Solution #3

>>> ‘1’ This is a catch-all for all types of errors.

‘2’ >>> Inappropriate usage of shell builtins (according to Bash documentation)

‘126’>>> The command that was issued could not be carried out.

‘127’>>>”command not found”

‘128’>>> Exit argument is invalid.


‘130’>>> Control-C terminated the script.

‘255’>>> Exit status is no longer valid.

This is for the purpose of bash. Other programs, on the other hand, have distinct exit codes.

Answered by segfault

Solution #4

None of the previous responses accurately explain exit status 2. Status 2 is what your command line utilities truly return when called incorrectly, despite what they state. (Yes, even if an answer is nine years old and has hundreds of upvotes, it can still be incorrect.)

For natural termination, i.e. not via signal, this is the true, long-standing exit status convention:

If the files being compared are identical, diff returns 0; otherwise, it returns 1. When unix applications are called erroneously, they return exit status 2 as a long-standing convention (unknown options, wrong number of arguments, etc.) diff -N, grep -Y, and diff a b c, for example, all result in $? being set to 2. This has been the standard since the 1970s, when Unix was first introduced.

When a command is terminated by a signal, the approved answer specifies what happens. In a nutshell, uncaught signal termination results in exit status 128+[signal number>]. E.g., termination by SIGINT (signal 2) results in exit status 130.

Answered by alexis

Solution #5

Aside from 0 indicating success, there are no conventional exit codes. In addition, non-zero does not always imply failure.

EXIT FAILURE is defined as 1 and EXIT SUCCESS is defined as 0, but that’s about it in stdlib.h.

The 11 on segfault is significant since 11 is the signal number used by the kernel to end a process when it segfaults. There’s probably a mechanism somewhere, either in the kernel or in the shell, that converts that to an exit code.

Answered by Chris Arguin

Post is based on