Существуют ли стандартные коды состояния выхода в Linux?

Процесс считается завершенным правильно в Linux, если его состояние выхода было 0.

Я видел, что ошибки сегментации часто приводят к состоянию выхода 11, хотя я не знаю, является ли это просто соглашением, в котором я работаю (приложения, которые потерпели неудачу, как все, были внутренними) или стандартом.

Существуют ли стандартные коды выхода для процессов в Linux?

8 битов кода возврата и 8 битов номера сигнала убийства смешиваются в одно значение при возврате из wait(2)& co. ,

#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)
        exit(42);
    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" */
}

Как вы определяете статус выхода? Традиционно оболочка хранит только 8-битный код возврата, но устанавливает старший бит, если процесс был ненормально завершен.

$ sh -c 'выход 42'; echo $?
42
$ sh -c 'kill -SEGV $$'; echo $?
Ошибка сегментации
139
$ expr 139 - 128
11

Если вы видите что-то кроме этого, то, вероятно, программа имеет SIGSEGVобработчик сигнала, который затем вызывается exitнормально, так что сигнал фактически не убивает. (Программы могут выбрать обработку любых сигналов, кроме SIGKILLи SIGSTOP.)

Часть 1: Расширенное руководство по написанию сценариев Bash

Как всегда, в Advanced Bash Scripting Guide есть много полезной информации : (Это было связано с другим ответом, но с неканоническим URL).

1: Catchall для общих ошибок
2: Неправильное использование встроенных командных оболочек (согласно документации Bash)
126: Вызванная команда не может выполнить
127: «Команда не найдена»
128: Неверный аргумент для выхода
128 + n: Сигнал фатальной ошибки «n»
255: Выход состояние вне диапазона (выход принимает только целочисленные аргументы в диапазоне 0 - 255)

Часть 2: sysexits.h

Ссылки ABSG sysexits.h.

В 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 */

'1' >>> Catchall для общих ошибок

'2' >>> Неправильное использование встроенных командных оболочек (согласно документации Bash)

'126' >>> Вызванная команда не может быть выполнена

'127' >>> "Команда не найдена"

«128» >>> Недопустимый аргумент для выхода

'128 + n' >>> Сигнал фатальной ошибки "n"

'130' >>> Сценарий прекращен с помощью Control-C

'255' >>> Выход из состояния вне диапазона

Это для Баш. Однако для других приложений существуют разные коды выхода.

Ни один из старых ответов не описывает правильное состояние выхода 2. Вопреки тому, что они утверждают, статус 2 - это то, что утилиты командной строки фактически возвращают при неправильном вызове. (Да, ответ может быть девять лет, иметь сотни голосов, и все же быть неправильным.)

Вот реальное, давнее соглашение о статусе выхода для нормального завершения, то есть не по сигналу:

• Статус выхода 0: успех
• Состояние выхода 1: «сбой», как определено программой
• Состояние выхода 2: ошибка использования командной строки

Например, diffвозвращает 0, если сравниваемые файлы идентичны, и 1, если они различаются. В соответствии с давним соглашением, программы Unix возвращают состояние выхода 2 при неправильном вызове (неизвестные параметры, неправильное количество аргументов и т. Д.). Например diff -N, grep -Yили diff a b cвсе они приведут $?к установке на 2. Это и было практикой, так как Первые дни Unix в 1970-х.

Общепринятый ответ объясняет , что происходит , когда команда прерывается сигналом. Вкратце, завершение из-за необработанного сигнала приводит к состоянию выхода 128+[<signal number>. Например, завершение SIGINT( сигнал 2 ) приводит к состоянию выхода 130.

Ноты

1. В нескольких ответах статус выхода 2 определяется как «Неправильное использование встроенных команд bash». Это применимо только тогда, когда bash (или скрипт bash) выходит со статусом 2. Считайте, что это особый случай неправильной ошибки использования.

2. В sysexits.hупомянутом в самом популярном ответе статус выхода EX_USAGE(«ошибка использования командной строки») определен как 64. Но это не отражает реальность: я не знаю ни одной распространенной утилиты Unix, которая возвращает 64 при неправильном вызове (примеры приветствуются ). Внимательное прочтение исходного кода показывает, что это sysexits.hявляется желательным, а не отражением истинного использования:

    *    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. 
   

   Другими словами, эти определения не отражают общепринятую практику того времени (1993 г.), но намеренно несовместимы с ней. Больше жалости.

Стандартных кодов выхода нет, кроме 0, означающего успех. Ненулевое также не обязательно означает неудачу.

stdlib.h определяет EXIT_FAILUREкак 1 и EXIT_SUCCESSкак 0, но это все.

11 на segfault интересен, так как 11 - это номер сигнала, который ядро ​​использует для уничтожения процесса в случае segfault. Вероятно, существует какой-то механизм, либо в ядре, либо в оболочке, который преобразует это в код выхода.

sysexits.h имеет список стандартных кодов выхода. Похоже, он датируется как минимум 1993 годом, и некоторые крупные проекты, такие как Postfix, используют его, так что я думаю, что это путь.

Со страницы руководства OpenBSD:

Согласно стилю (9), не рекомендуется вызывать exit (3) с произвольными значениями, чтобы указать состояние ошибки при завершении программы. Вместо этого следует использовать предопределенные коды выхода из sysexits, чтобы вызывающий процесс мог получить приблизительную оценку класса сбоев без поиска исходного кода.

В первом приближении 0 - это успех, ненулевое значение - сбой, 1 - общий сбой, а все, что больше, - конкретный сбой. Помимо тривиальных исключений false и test, которые предназначены для получения 1 за успех, есть еще несколько исключений, которые я обнаружил.

Более реалистично, 0 означает успех или, возможно, сбой, 1 означает общий отказ или, может быть, успех, 2 означает общий отказ, если 1 и 0 оба используются для успеха, но, возможно, также и успех.

Команда diff дает 0, если сравниваемые файлы идентичны, 1, если они различаются, и 2, если двоичные файлы различны. 2 также означает неудачу. Команда less выдает 1 за неудачу, если только вы не предоставите аргумент, в этом случае она выходит из 0, несмотря на неудачу.

Команда more и команда spell дают 1 для сбоя, если сбой не является результатом отказа в доступе, несуществующего файла или попытки прочитать каталог. В любом из этих случаев они выходят из 0, несмотря на неудачу.

Затем команда expr выдает 1 для sucess, если только вывод не является пустой строкой или нулем, в этом случае 0 является sucess. 2 и 3 провал.

Тогда есть случаи, когда успех или неудача неоднозначны. Когда grep не удается найти шаблон, он выходит из 1, но выходит из 2 для подлинного сбоя (например, отказано в разрешении). Klist также выходит из 1, когда не удается найти заявку, хотя на самом деле это не больше сбой, чем в случае, когда grep не находит шаблон, или когда вы используете пустой каталог.

Так что, к сожалению, unix-возможности, похоже, не реализуют какой-либо логический набор правил, даже для очень часто используемых исполняемых файлов.

Программы возвращают 16-битный код выхода. Если программа была прервана с помощью сигнала, то старший байт содержит используемый сигнал, в противном случае младший байт - это состояние выхода, возвращаемое программистом.

Как этот код выхода назначается переменной состояния $? затем до оболочки. Bash сохраняет младшие 7 бит состояния и затем использует 128 + (сигнал nr) для индикации сигнала.

Единственное «стандартное» соглашение для программ - 0 для успеха, ненулевое для ошибки. Другое используемое соглашение - возвращать errno в случае ошибки.

Стандартные коды выхода Unix определяются sysexits.h, как упоминалось в другом постере. Такие же коды выхода используются переносимыми библиотеками, такими как Poco - вот их список:

http://pocoproject.org/docs/Poco.Util.Application.html#16218

Сигнал 11 является сигналом SIGSEGV (нарушение сегмента), который отличается от кода возврата. Этот сигнал генерируется ядром в ответ на неправильный доступ к странице, что приводит к завершению программы. Список сигналов можно найти на странице справки по сигналам (запустите «сигнал человека»).

Когда Linux возвращает 0, это означает успех. Все остальное означает сбой, у каждой программы есть свои коды выхода, поэтому было бы довольно долго перечислять их все ...!

Что касается кода ошибки 11, это действительно номер ошибки сегментации, в основном это означает, что программа получила доступ к области памяти, которая не была назначена.