我正在尝试解决同样的问题，但由于我的程序必须运行在OS X上，所以只运行linux的解决方案对我不起作用。

我得到了与本页其他人相同的结论——当父母去世时，没有一种与posix兼容的方式来通知孩子。所以我想出了次好的办法——让孩子投票。

当父进程(由于任何原因)终止时，子进程将变成进程1。如果子进程只是定期轮询，它可以检查父进程是否为1。如果是，子进程应该退出。

这不是很好，但它可以工作，并且比本文其他地方建议的TCP套接字/锁文件轮询解决方案更容易。

如果你无法修改子进程，你可以尝试以下方法:

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

这将在启用作业控制的shell进程中运行子进程。子进程在后台生成。shell等待换行符(或EOF)，然后终止子进程。

当父进程死亡时——不管是什么原因——它将关闭管道的一端。子shell将从read中获得一个EOF，并继续杀死后台的子进程。

以防它与任何人相关，当我从c++派生子进程中的JVM实例时，我可以让JVM实例在父进程完成后正确终止的唯一方法是执行以下操作。如果这不是最好的方法，希望有人能在评论中提供反馈。

1)在通过execv启动Java应用程序之前，在fork子进程上调用prctl(PR_SET_PDEATHSIG, SIGHUP)

2)在Java应用程序中添加一个shutdown钩子，轮询直到其父PID等于1，然后执行一个硬的Runtime.getRuntime().halt(0)。轮询是通过启动运行ps命令的单独shell来完成的(参见:如何在Linux上的Java或JRuby中找到我的PID ?)

130118年编辑:

这似乎不是一个可靠的解决方案。我仍然在努力理解发生的事情的细微差别，但在屏幕/SSH会话中运行这些应用程序时，有时仍然会遇到孤立的JVM进程。

Instead of polling for the PPID in the Java app, I simply had the shutdown hook perform cleanup followed by a hard halt as above. Then I made sure to invoke waitpid in the C++ parent app on the spawned child process when it was time to terminate everything. This seems to be a more robust solution, as the child process ensures that it terminates, while the parent uses existing references to make sure that its children terminate. Compare this to the previous solution which had the parent process terminate whenever it pleased, and had the children try to figure out if they had been orphaned before terminating.

Historically, from UNIX v7, the process system has detected orphanity of processes by checking a process' parent id. As I say, historically, the init(8) system process is a special process by only one reason: It cannot die. It cannot die because the kernel algorithm to deal with assigning a new parent process id, depends on this fact. when a process executes its exit(2) call (by means of a process system call or by external task as sending it a signal or the like) the kernel reassigns all children of this process the id of the init process as their parent process id. This leads to the most easy test, and most portable way of knowing if a process has got orphan. Just check the result of the getppid(2) system call and if it is the process id of the init(2) process then the process got orphan before the system call.

这种方法会产生两个问题:

first, we have the possibility of changing the init process to any user process, so How can we assure that the init process will always be parent of all orphan processes? Well, in the exit system call code there's a explicit check to see if the process executing the call is the init process (the process with pid equal to 1) and if that's the case, the kernel panics (It should not be able anymore to maintain the process hierarchy) so it is not permitted for the init process to do an exit(2) call. second, there's a race condition in the basic test exposed above. Init process' id is assumed historically to be 1, but that's not warranted by the POSIX approach, that states (as exposed in other response) that only a system's process id is reserved for that purpose. Almost no posix implementation does this, and you can assume in original unix derived systems that having 1 as response of getppid(2) system call is enough to assume the process is orphan. Another way to check is to make a getppid(2) just after the fork and compare that value with the result of a new call. This simply doesn't work in all cases, as both call are not atomic together, and the parent process can die after the fork(2) and before the first getppid(2) system call. The processparent id only changes once, when its parent does anexit(2)call, so this should be enough to check if thegetppid(2)result changed between calls to see that parent process has exit. This test is not valid for the actual children of the init process, because they are always children ofinit(8)`, but you can assume safely these processes as having no parent either (except when you substitute in a system the init process)

在POSIX中，exit()， _exit()和_exit()函数被定义为:

如果该进程是控制进程，则SIGHUP信号应发送给控制终端的前台进程组中属于呼叫进程的每个进程。

因此，如果您安排父进程作为其进程组的控制进程，那么当父进程退出时，子进程应该得到一个SIGHUP信号。我不确定当父节点崩溃时是否会发生这种情况，但我认为确实会发生。当然，对于非崩溃的情况，它应该可以正常工作。

请注意，您可能必须阅读大量的小字——包括基本定义(Definitions)部分，以及exit()和setsid()和setpgrp()的系统服务信息——才能了解完整的情况。(我也是!)

我找到了两个解，都不完美。

1.当收到SIGTERM信号时，通过Kill (-pid)杀死所有子结点。 显然，这个解决方案不能处理“kill -9”，但它确实适用于大多数情况，而且非常简单，因为它不需要记住所有的子进程。

    var childProc = require('child_process').spawn('tail', ['-f', '/dev/null'], {stdio:'ignore'});

    var counter=0;
    setInterval(function(){
      console.log('c  '+(++counter));
    },1000);

    if (process.platform.slice(0,3) != 'win') {
      function killMeAndChildren() {
        /*
        * On Linux/Unix(Include Mac OS X), kill (-pid) will kill process group, usually
        * the process itself and children.
        * On Windows, an JOB object has been applied to current process and children,
        * so all children will be terminated if current process dies by anyway.
        */
        console.log('kill process group');
        process.kill(-process.pid, 'SIGKILL');
      }

      /*
      * When you use "kill pid_of_this_process", this callback will be called
      */
      process.on('SIGTERM', function(err){
        console.log('SIGTERM');
        killMeAndChildren();
      });
    }

通过同样的方式，如果你调用process，你可以像上面那样安装'exit'处理程序。退出的地方。 注意:Ctrl+C和突然崩溃已经被操作系统自动处理来杀死进程组，这里不再赘述。

2.使用chjj/pty.js生成附加控制终端的进程。 当你以任何方式甚至kill -9终止当前进程时，所有的子进程也会被自动终止(由操作系统?)我猜是因为当前进程占用终端的另一侧，所以如果当前进程死亡，子进程将获得SIGPIPE，因此死亡。

    var pty = require('pty.js');

    //var term =
    pty.spawn('any_child_process', [/*any arguments*/], {
      name: 'xterm-color',
      cols: 80,
      rows: 30,
      cwd: process.cwd(),
      env: process.env
    });
    /*optionally you can install data handler
    term.on('data', function(data) {
      process.stdout.write(data);
    });
    term.write(.....);
    */