有人告诉我，当你在 linux 中杀死一个父进程时，子进程会死。
但我对此表示怀疑。所以我写了两个bash脚本，father.sh会调用child.sh
这是我的脚本：
现在我运行bash father.sh，你可以检查它ps -alf
然后我被kill -9 24588杀死了father.sh，我猜想应该终止子进程但不幸的是我错了。
谁能解释为什么？
谢谢
【问题讨论】：
不，当你单独杀死一个进程时，它不会杀死子进程。
如果您希望给定组的所有进程都接收信号，则必须将信号发送到 进程组
例如，如果您的父进程 id 的代码为 1234，则您必须指定 parentpid，添加符号减号，后跟您的父进程 id：
kill -9 -1234
否则，孤儿将链接到init，如您的第三个屏幕截图所示（孩子的 PPID 已变为 1）。
【讨论】：
thepidhere通常是父进程的PID，但可以使用ps -eo "%p %r %c %a"确定。 +1。
PID 123 的进程并且我执行kill -9 -123 我有以下错误-bash: kill: (-123) - No such process。我在 Centos 6 上运行
kill -9 -27541 时像我一样kill: invalid option -- '2'，那就做kill -9 -- -27541
-bash: kill: (-123) - 没有这样的进程
在交互式 Terminal.app 会话中，当启用作业控制/监视模式时，前台进程组 ID 号和后台进程组 ID 号在设计上是不同的。换句话说，如果您在启用了作业控制的 Terminal.app 会话中后台执行命令，则后台进程的$! pid 实际上是一个新的进程组 ID 号 (pgid)。
但是，在没有启用作业控制的脚本中，情况可能并非如此！后台进程的pid可能不是新的pgid而是正常的pid！这就是导致错误消息-bash: kill: (-123) - No such process 的原因，它试图杀死一个进程组，但只为kill 命令指定一个正常的pid（而不是pgid）。
# 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
}
【讨论】：
pkill -TERM -P <ProcessID>
这会杀死父母和孩子
【讨论】：
ProcessID的进程？
通常杀死父母也会杀死孩子。
您看到孩子在杀死父亲后仍然活着的原因是因为孩子只有在它“选择”（内核选择）来处理 SIGKILL 事件后才会死。它不必马上处理。您的脚本正在运行 sleep() 命令（即在内核中），该命令在睡眠完成之前不会唤醒以处理任何事件。
为什么 PPID #1？父级已死，不再在进程表中。 child.sh 现在没有莫名其妙地链接到 init。它根本没有运行的父级。说它与 init 相关联会产生这样一种印象，即如果我们以某种方式离开 init，则 init 可以控制关闭进程。它还给人一种印象，即杀死父母将使祖父母成为孩子的主人。两者都不是真的。该子进程仍然存在于进程表中并且正在运行，但在处理 SIGKILL 之前，不会处理基于其进程 ID 的新事件。这意味着孩子是一个僵尸前，行尸走肉，有被贴上标签的危险。
在进程组中杀死是不同的，用于杀死兄弟，和父进程组#。同样重要的是要注意“杀死进程”本身并不是“杀死”，以人类的方式，您希望进程被销毁并且所有内存都返回，就好像它从来没有一样。它只是将一个特定事件（在许多事件中）发送到进程以供其处理。如果进程没有正确处理它，那么一段时间后操作系统会出现并强制“清理”它。
它（杀死）不会立即发生，因为孩子（甚至父母）可能已将某些内容写入磁盘并等待 I/O 完成或执行其他可能危及系统稳定性或文件的关键任务完整性。
【讨论】：