Есть ли вариант UNIX, в котором дочерний процесс умирает вместе со своим родителем?

Я уже довольно давно изучаю поведение ядра Linux, и мне всегда было ясно, что:

Когда процесс умирает, все его дочерние элементы возвращаются initпроцессу (PID 1) до тех пор, пока они в конечном итоге не умрут.

Однако недавно кто-то с большим опытом работы с ядром сказал мне, что:

Когда процесс завершается, все его дочерние элементы также умирают (если вы не используете, NOHUPв этом случае они возвращаются init).

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

int main(void){
    printf("Father process spawned (%d).\n", getpid());
    sleep(5);

    if(fork() == 0){
        printf("Child process spawned (%d => %d).\n", getppid(), getpid());
        sleep(15);
        printf("Child process exiting (%d => %d).\n", getppid(), getpid());
        exit(0);
    }

    sleep(5);
    printf(stdout, "Father process exiting (%d).\n", getpid());
    return EXIT_SUCCESS;
}

Вот вывод программы, с ассоциированным psрезультатом каждый раз, когда printfговорит:

$ ./test &
Father process spawned (435).

$ ps -ef | grep test
myuser    435    392   tty1    ./test

Child process spawned (435 => 436).

$ ps -ef | grep test
myuser    435    392   tty1    ./test
myuser    436    435   tty1    ./test

Father process exiting (435).

$ ps -ef | grep test
myuser    436    1     tty1    ./test

Child process exiting (436).

Теперь, как вы можете видеть, это ведет себя так, как я и ожидал. Сиротский процесс (436) возвращается к init(1), пока он не умрет.

Однако существует ли система на основе UNIX, к которой это поведение не применяется по умолчанию? Существует ли какая-либо система, в которой смерть процесса немедленно вызывает смерть всех его детей?

Когда процесс завершается, все его дочерние элементы также умирают (если вы не используете NOHUP, в этом случае они возвращаются к init).

Это не правильно. Смертельно неправильно. Человек, говорящий, что либо ошибся, либо перепутал конкретную ситуацию с общим делом.

Есть два способа, которыми смерть процесса может косвенно вызвать смерть его детей. Они связаны с тем, что происходит, когда терминал закрыт. Когда терминал исчезает (исторически , потому что последовательная линия была вырезана из - за модемом зависание, в настоящее время обычно потому , что пользователь закрыл окно терминала эмулятора), сигнал SIGHUP посылаются на контрольном процесс работает в том , что терминал - как правило, начальная оболочка начала в этом терминале. Снаряды обычно реагируют на это, выходя. Перед выходом оболочки, предназначенные для интерактивного использования, отправляют HUP на каждое задание, которое они начали.

Запуск задания из оболочки с nohupперебоями во втором источнике сигналов HUP, потому что задание будет тогда игнорировать сигнал и, следовательно, ему не будет приказано умереть при исчезновении терминала. Другие способы прервать распространение сигналов HUP от оболочки до заданий включают использование disownвстроенной функции оболочки, если она есть (задание удалено из списка заданий оболочки), и двойное разветвление (оболочка запускает дочерний элемент, который запускает дочерний элемент). своего собственного и немедленно выходит; оболочка не знает своего внука).

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

Когда процесс завершается, все его дочерние элементы также умирают (если вы не используете NOHUP, в этом случае они возвращаются к init).

Это правильно, если процесс является лидером сеанса. Когда лидер сеанса умирает, SIGHUP отправляется всем участникам этого сеанса. На практике это означает, что его дети и их потомки.

Процесс делает себя лидером сессии, вызывая setsid. Снаряды используют это.

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

Это то, что делает Shell, и это должно быть тем, что делает ваш родительский процесс. Может потребоваться перехватить сигнал HUP в родительском элементе, чтобы у вас все еще было достаточно контроля, чтобы убить дочерних элементов.

Я упускаю один бит в ответах, которые немного связаны с умирающими родителями: когда процесс пишет в канале, для которого больше нет процесса чтения, он получает SIGPIPE. Стандартное действие для SIGPIPE - завершение.

Это действительно может привести к смерти процессов. Фактически, это стандартный способ yesсмерти программы .

Если я выполню

(yes;echo $? >&2)|head -10

в моей системе ответ

y
y
y
y
y
y
y
y
y
y
141

и 141 действительно 128 + SIGPIPE:

   SIGPIPE      13       Term    Broken pipe: write to pipe with no
                                 readers

от man 7 signal.