Gibt es eine UNIX-Variante, bei der ein untergeordneter Prozess mit seinem übergeordneten Prozess abstirbt?

Ich habe das Verhalten des Linux-Kernels schon seit einiger Zeit untersucht, und mir war immer klar, dass:

Wenn ein Prozess stirbt, werden alle seine Kinder an den initProzess (PID 1) zurückgegeben, bis sie schließlich sterben.

Kürzlich hat mir jedoch jemand mit viel mehr Erfahrung als ich mit dem Kernel gesagt, dass:

Wenn ein Prozess beendet wird, sterben auch alle seine untergeordneten Elemente (es sei denn, Sie verwenden, NOHUPin welchem ​​Fall sie zurückkehren init).

Auch wenn ich das nicht glaube, habe ich dennoch ein einfaches Programm geschrieben, um sicherzugehen. Ich weiß, dass ich mich sleepbei Tests nicht auf time ( ) verlassen sollte , da alles von der Prozessplanung abhängt, aber für diesen einfachen Fall denke ich, dass das ausreichend ist.

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;
}

Hier ist die Ausgabe des Programms mit dem zugehörigen psErgebnis bei jedem printfGespräch:

$ ./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).

Nun, wie Sie sehen können, verhält sich dies so, wie ich es erwartet hätte. Der Waisenprozess (436) wird an init(1) zurückgegeben, bis er stirbt.

Gibt es jedoch ein UNIX-basiertes System, auf dem dieses Verhalten nicht standardmäßig angewendet wird? Gibt es ein System, bei dem der Tod eines Prozesses sofort den Tod aller seiner Kinder auslöst?

Wenn ein Prozess beendet wird, sterben auch alle seine untergeordneten Elemente (es sei denn, Sie verwenden NOHUP. In diesem Fall kehren sie zu init zurück).

Das ist falsch. Total falsch. Die Person, die das sagt, war entweder falsch oder hat eine bestimmte Situation mit dem allgemeinen Fall verwechselt.

Es gibt zwei Möglichkeiten, wie der Tod eines Prozesses indirekt den Tod seiner Kinder verursachen kann. Sie hängen damit zusammen, was passiert, wenn ein Terminal geschlossen wird. Wenn ein Terminal verschwindet (historisch , weil die serielle Leitung aufgrund eines Modems hangup geschnitten, heutzutage in der Regel , weil der Benutzer des Terminal - Emulator - Fenster geschlossen), ein SIGHUP - Signal gesendet wird, um den Steuerprozess in diesem Terminal läuft - in der Regel der erst Shell gestartet in diesem Terminal. Muscheln reagieren normalerweise darauf, indem sie beendet werden. Vor dem Beenden senden für die interaktive Verwendung bestimmte Shells HUP an jeden Job, den sie gestartet haben.

Das Starten eines Jobs von einer Shell aus nohupunterbricht diese zweite Quelle von HUP-Signalen, da der Job das Signal dann ignoriert und nicht angewiesen wird, zu sterben, wenn das Terminal verschwindet. Weitere Möglichkeiten, die Weitergabe von HUP-Signalen von der Shell an die Jobs zu disownunterbrechen, sind die Verwendung des integrierten Shell- Jobs (der Job wird aus der Jobliste der Shell entfernt) und das Double-Forking (die Shell startet ein untergeordnetes Objekt , das ein untergeordnetes Objekt startet) von selbst und geht sofort; die Muschel hat keine Kenntnis von ihrem Enkelkind).

Wiederum sterben die Jobs, die im Terminal gestartet wurden, nicht, weil ihr übergeordneter Prozess (die Shell) stirbt, sondern weil ihr übergeordneter Prozess entscheidet, sie zu töten, wenn ihm gesagt wird, dass er sie töten soll. Und die anfängliche Shell im Terminal stirbt nicht, weil ihr übergeordneter Prozess stirbt, sondern weil ihr Terminal verschwindet (was zufällig sein kann oder nicht, weil das Terminal von einem Terminalemulator bereitgestellt wird, der der übergeordnete Prozess der Shell ist).

Wenn ein Prozess beendet wird, sterben auch alle seine untergeordneten Elemente (es sei denn, Sie verwenden NOHUP. In diesem Fall kehren sie zu init zurück).

Dies ist korrekt, wenn der Prozess ein Sitzungsleiter ist. Wenn ein Sitzungsleiter stirbt, wird ein SIGHUP an alle Mitglieder dieser Sitzung gesendet. In der Praxis bedeutet das seine Kinder und ihre Nachkommen.

Ein Prozess macht sich selbst zum Sitzungsleiter, indem er aufruft setsid. Muscheln verwenden dies.

Was über den Plakaten steht, ist, dass die Kinder nicht sterben, die Eltern sie töten (oder ihnen ein Signal senden, bei dem sie terminieren). Sie können also das haben, wonach Sie fragen, wenn Sie den Elternteil so programmieren, dass er (1) alle seine Kinder aufzeichnet und (2) ein Signal an alle seine Kinder sendet.

Dies ist, was die Shell tut, und es sollte sein, was Ihr übergeordneter Prozess tut. Möglicherweise muss das HUP-Signal im übergeordneten Element abgefangen werden, damit Sie noch genügend Kontrolle haben, um die Kinder zu töten.

Ich vermisse ein bisschen in den Antworten, die etwas mit sterbenden Eltern zu tun haben: Wenn ein Prozess auf eine Pipe schreibt, für die es keinen Lesevorgang mehr gibt, erhält er eine SIGPIPE. Die Standardaktion für SIGPIPE ist die Beendigung.

Dies kann tatsächlich zum Absterben von Prozessen führen. Tatsächlich ist dies die Standardmethode, mit der das Programm yesstirbt.

Wenn ich ausführe

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

Auf meinem System lautet die Antwort

y
y
y
y
y
y
y
y
y
y
141

und 141 ist in der Tat 128 + SIGPIPE:

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

von man 7 signal.