自己看吧，egg 的 cluster 模块底层的容错处理就靠它们

• https://github.com/node-modules/graceful
• https://github.com/node-modules/graceful-process

解决办法：

//改成master进程中监听子进程exit
worker.on(‘exit’,function () {
		console.log(worker.isDead())
})

原因

//摘自lib/internal/cluster/worker.js
Worker.prototype.isDead = function() {
  return this.process.exitCode != null || this.process.signalCode != null;
};

worker自愿退出后，主进程中对应的worker会先触发disconnect再触发exit事件。触发前者时，worker的process上还没有exitCode或signalCode属性。或者说两个事件的区别是，前者标志父子detach完成，后者标志子进程真正退出。

@soda-wy 谢谢

@atian25 谢谢

@soda-wy 请问大佬如果子进程被手动杀死，监听事件还是按顺序执行的吗。比如手动杀死子进程disconnect和exit事件还是按顺序触发吗 ，worker.isDead()在disconnect会变成了true吗。

@1316346949

为啥要手动杀？？？

为啥不自己动手试一试？？

我试了下kill -9子进程，父进程中还是会依次触发disconnect和exit, worker.isDead()在disconnect事件中没有变成true

@soda-wy 谢谢大佬的解答，因为我的linux基础薄弱，在window下测试也是worker.isDead()是false，但是在egg源码里看到他们处理了在disconnect函数触发情况下，worker.isDead()返回true的情况下，我也一直没搞清楚什么情况下worker.isDead()f返回true

@soda-wy 也就是可能在disconnect函数触发情况下子进程已经死亡了，是被什么东西杀死而不是自愿退出

@soda-wy 又或者某种情况下子进程退出并不是按顺序触发disconnect和exit，先触发exit，再触发disconnect

@1316346949 我在egg源码里没有找到disconnect事件下的worker.isDead()。 node源码里有一处，但我没能重现出如何才能走到那句。。

// lib/interal/cluster/master.js

worker.process.once('disconnect', () => {
    /*
     * Now is a good time to remove the handles
     * associated with this worker because it is
     * not connected to the master anymore.
     */
    removeHandlesForWorker(worker);

    /*
     * Remove the worker from the workers list only
     * if its process has exited. Otherwise, we might
     * still want to access it.
     */
    if (worker.isDead())
      removeWorker(worker);

    worker.exitedAfterDisconnect = !!worker.exitedAfterDisconnect;
    worker.state = 'disconnected';
    worker.emit('disconnect');
    cluster.emit('disconnect', worker);
  });

@soda-wy 嗯嗯，我也看到了，在egg的egg2.0\node_modules_cfork@1.7.1@cfork\index.js或者egg2.0\node_modules\egg\node_modules\egg-cluster\node_modules\cfork\index.js里cluster.on(‘disconnect’,function(){})