Wie kann man einen untergeordneten Prozess sterben lassen, nachdem der übergeordnete Prozess beendet wurde?

Angenommen, ich habe einen Prozess, der genau einen untergeordneten Prozess hervorbringt. Wenn nun der übergeordnete Prozess aus irgendeinem Grund beendet wird (normal oder abnormal, durch kill, ^C, Assertion Failure oder irgendetwas anderes), möchte ich, dass der untergeordnete Prozess stirbt. Wie macht man das richtig?

Eine ähnliche Frage zu Stackoverflow:

• (früher gefragt) Wie kann ich bewirken, dass ein untergeordneter Prozess beendet wird, wenn der Elternprozess beendet wird?
• (später gefragt) Werden untergeordnete Prozesse, die mit fork() erstellt wurden, automatisch beendet, wenn der übergeordnete Prozess beendet wird?

Eine ähnliche Frage zu Stackoverflow for Windows:

• Wie zerstöre ich automatisch untergeordnete Prozesse in Windows?
• Untergeordneten Prozess beenden, wenn Elternprozess beendet wird

Das Kind kann den Kernel bitten, zu liefern SIGHUP (oder ein anderes Signal), wenn ein Elternteil stirbt, indem die Option angegeben wird PR_SET_PDEATHSIG in prctl() Systemaufruf wie folgt:

prctl(PR_SET_PDEATHSIG, SIGHUP);

Sehen man 2 prctl für Details.

Bearbeiten: Dies ist nur Linux

Ich versuche, das gleiche Problem zu lösen, und da mein Programm unter OS X laufen muss, hat die reine Linux-Lösung für mich nicht funktioniert.

Ich bin zu dem gleichen Schluss gekommen wie die anderen Leute auf dieser Seite – es gibt keine POSIX-kompatible Möglichkeit, ein Kind zu benachrichtigen, wenn ein Elternteil stirbt. Also habe ich mir das Nächstbeste ausgedacht – die Kinderumfrage.

Wenn ein Elternprozess stirbt (aus irgendeinem Grund), wird der Elternprozess des Kindes zu Prozess 1. Wenn das Kind einfach periodisch abfragt, kann es überprüfen, ob sein Elternprozess 1 ist. Wenn dies der Fall ist, sollte das Kind beendet werden.

Das ist nicht großartig, aber es funktioniert, und es ist einfacher als die TCP-Socket/Lockfile-Polling-Lösungen, die an anderer Stelle auf dieser Seite vorgeschlagen werden.

Ich habe dies in der Vergangenheit erreicht, indem ich den “Original”-Code im “Kind” und den “erzeugten” Code im “Eltern” ausgeführt habe (das heißt: Sie kehren den üblichen Sinn des Tests danach um fork()). Fangen Sie dann SIGCHLD im “erzeugten” Code ein …

In Ihrem Fall möglicherweise nicht möglich, aber nett, wenn es funktioniert.

Unter Linux können Sie ein Eltern-Todessignal im Kind installieren, z. B.:

#include <sys/prctl.h> // prctl(), PR_SET_PDEATHSIG
#include <signal.h> // signals
#include <unistd.h> // fork()
#include <stdio.h>  // perror()

// ...

pid_t ppid_before_fork = getpid();
pid_t pid = fork();
if (pid == -1) { perror(0); exit(1); }
if (pid) {
    ; // continue parent execution
} else {
    int r = prctl(PR_SET_PDEATHSIG, SIGTERM);
    if (r == -1) { perror(0); exit(1); }
    // test in case the original parent exited just
    // before the prctl() call
    if (getppid() != ppid_before_fork)
        exit(1);
    // continue child execution ...

Beachten Sie, dass die übergeordnete Prozess-ID vor dem Fork gespeichert und danach im untergeordneten Prozess getestet wird prctl() eliminiert eine Racebedingung zwischen prctl() und der Ausgang des Prozesses, der das Kind aufgerufen hat.

Beachten Sie auch, dass das Eltern-Todessignal des Kindes in neu erstellten eigenen Kindern gelöscht wird. Es wird nicht von einem beeinflusst execve().

Dieser Test kann vereinfacht werden, wenn wir sicher sind, dass der Systemprozess, der für die Annahme aller verantwortlich ist, verantwortlich ist Waisen hat PID 1:

pid_t pid = fork();
if (pid == -1) { perror(0); exit(1); }
if (pid) {
    ; // continue parent execution
} else {
    int r = prctl(PR_SET_PDEATHSIG, SIGTERM);
    if (r == -1) { perror(0); exit(1); }
    // test in case the original parent exited just
    // before the prctl() call
    if (getppid() == 1)
        exit(1);
    // continue child execution ...

Sich auf dieses Systemprozesswesen verlassen init und PID 1 zu haben, ist jedoch nicht portabel. POSIX.1-2008 spezifiziert:

Die Elternprozess-ID aller existierenden Kindprozesse und Zombie-Prozesse des aufrufenden Prozesses soll auf die Prozess-ID eines implementierungsdefinierten Systemprozesses gesetzt werden. Das heißt, diese Prozesse sollen von einem speziellen Systemprozess geerbt werden.

Traditionell ist der Systemprozess, der alle Waisen übernimmt, PID 1, dh init – der Vorfahre aller Prozesse.

Auf modernen Systemen wie Linux oder FreeBSD ein anderer Prozess könnte diese Rolle übernehmen. Unter Linux kann beispielsweise ein Prozess aufrufen prctl(PR_SET_CHILD_SUBREAPER, 1) sich selbst als Systemprozess zu etablieren, der alle Waisen seiner Nachkommen erbt (vgl. an Beispiel auf Fedora 25).

Wenn Sie den untergeordneten Prozess nicht ändern können, können Sie Folgendes versuchen:

int pipes[2];
pipe(pipes)
if (fork() == 0) {
    close(pipes[1]); /* Close the writer end in the child*/
    dup2(pipes[0], STDIN_FILENO); /* Use reader end as stdin (fixed per  maxschlepzig */
    exec("sh -c 'set -o monitor; child_process & read dummy; kill %1'")
}

close(pipes[0]); /* Close the reader end in the parent */

Dadurch wird das untergeordnete Element innerhalb eines Shell-Prozesses mit aktivierter Jobsteuerung ausgeführt. Der untergeordnete Prozess wird im Hintergrund gestartet. Die Shell wartet auf einen Zeilenumbruch (oder ein EOF) und beendet dann das Kind.

Wenn der Elternteil stirbt – egal aus welchem ​​Grund – wird er sein Ende der Pfeife schließen. Die Kind-Shell erhält ein EOF von dem Lesevorgang und fährt fort, den im Hintergrund befindlichen Kindprozess zu beenden.

Der Vollständigkeit halber. Unter macOS können Sie kqueue verwenden:

void noteProcDeath(
    CFFileDescriptorRef fdref, 
    CFOptionFlags callBackTypes, 
    void* info) 
{
    // LOG_DEBUG(@"noteProcDeath... ");

    struct kevent kev;
    int fd = CFFileDescriptorGetNativeDescriptor(fdref);
    kevent(fd, NULL, 0, &kev, 1, NULL);
    // take action on death of process here
    unsigned int dead_pid = (unsigned int)kev.ident;

    CFFileDescriptorInvalidate(fdref);
    CFRelease(fdref); // the CFFileDescriptorRef is no longer of any use in this example

    int our_pid = getpid();
    // when our parent dies we die as well.. 
    LOG_INFO(@"exit! parent process (pid %u) died. no need for us (pid %i) to stick around", dead_pid, our_pid);
    exit(EXIT_SUCCESS);
}


void suicide_if_we_become_a_zombie(int parent_pid) {
    // int parent_pid = getppid();
    // int our_pid = getpid();
    // LOG_ERROR(@"suicide_if_we_become_a_zombie(). parent process (pid %u) that we monitor. our pid %i", parent_pid, our_pid);

    int fd = kqueue();
    struct kevent kev;
    EV_SET(&kev, parent_pid, EVFILT_PROC, EV_ADD|EV_ENABLE, NOTE_EXIT, 0, NULL);
    kevent(fd, &kev, 1, NULL, 0, NULL);
    CFFileDescriptorRef fdref = CFFileDescriptorCreate(kCFAllocatorDefault, fd, true, noteProcDeath, NULL);
    CFFileDescriptorEnableCallBacks(fdref, kCFFileDescriptorReadCallBack);
    CFRunLoopSourceRef source = CFFileDescriptorCreateRunLoopSource(kCFAllocatorDefault, fdref, 0);
    CFRunLoopAddSource(CFRunLoopGetMain(), source, kCFRunLoopDefaultMode);
    CFRelease(source);
}

Hat der untergeordnete Prozess eine Pipe zum/vom übergeordneten Prozess? Wenn dies der Fall ist, erhalten Sie beim Schreiben ein SIGPIPE oder beim Lesen EOF – diese Bedingungen könnten erkannt werden.