为什么在父进程在Linux中被杀后为什么subprocess还活着？

不，当你独自杀死一个进程的时候，它不会杀死那些孩子。

如果您希望给定组的所有进程都接收信号，则必须将信号发送到进程组

 kill -9 -parentpid 

否则，孤儿将被链接到init ，如第三个屏幕截图所示（孩子的PPID变为1）。

-bash：kill：（-123） – 没有这个过程

在交互式的Terminal.app会话中，当启用作业控制/监视模式时，前台进程组ID号和后台进程组ID号是不同的。 换句话说，如果您在启用作业控制的Terminal.app会话中背景命令， $! 后台进程的pid实际上是一个新的进程组标识号（pgid）。

但是，在没有启用作业控制的脚本中，情况可能并非如此！ 后台进程的pid可能不是一个新的pgid，而是一个正常的pid！ 这是，什么导致错误消息-bash: kill: (-123) - No such process ，试图杀死一个进程组，但只是指定一个正常的pid（而不是一个pgid）到kill命令。

 # the following code works in Terminal.app because $! == $pgid { sleep 100 & IFS=" " read -r pgid <<EOF $(ps -p $! -o pgid=) EOF echo $$ $! $pgid sleep 10 kill -HUP -- -$! #kill -HUP -- -${pgid} # use in script } 

人们打算投票，但接受的答案是错误的 。 一般杀害父母也会杀死孩子。

杀死父亲后，你看到这个孩子还活着的原因是因为孩子在选择处理SIGKILL事件后才会死亡。 它不必马上处理。 你的脚本运行一个sleep（）命令，在睡眠完成之前，它不会被唤醒以处理任何事件。

为什么是PPID＃1？ 父母已经死亡，不再在进程表中。 现在，child.sh并不是莫名其妙地连接到init。 它根本没有运行的父母。 说它和init相关联会产生一个印象，如果我们不知何故离开init，那init就控制关闭这个进程。 这也造成了这样的印象：杀害父母会使祖父母成为一个孩子的主人。 两者都是不正确的。 该子进程仍然存在于进程表中并且正在运行，但是不会处理基于它的进程ID的新事件，直到它处理完SIGKILL。 这意味着孩子是一个僵尸前，走路死亡，有被贴上标签的危险。

杀死进程组是不同的，用来杀死兄弟姐妹 ，并且通过进程组＃来杀死父进程。 也许同样重要的一点是，“杀死一个进程”本身并不是以人类的方式“杀戮”，在那里你期望进程被摧毁，所有的记忆都会像以前一样回归。 它只是发送一个特定的事件，其中很多，它处理的过程。 如果这个过程没有正确处理，那么一段时间以后，操作系统会强行进行“清理”。

它（杀害）不会立即发生，因为孩子（甚至父母）可能已经写了一些东西到磁盘上，等待I / O完成或者做一些可能危及系统稳定性或文件完整性的其他关键任务。

 pkill -TERM -P <ProcessID> 

这将杀害父母以及孩子