Python中在启动线程内调用Fork()的子进程终止阻塞问题

首先明确：defunct（僵尸）进程本身就是已经正常终止的进程，它之所以残留，核心原因是父进程还未读取它的退出状态码——这正是你遇到的矛盾点：明明子进程已经终止，父进程却卡在os.waitpid(x, 0)无法推进。

结合你在线程内部fork子进程的特殊场景，我梳理了几个最可能的原因和对应的解决思路：

1. 父进程的SIGCHLD信号处理逻辑干扰了waitpid #

如果你的主进程（注意不是子进程）中设置了对SIGCHLD信号的自动忽略，比如：

import signal
signal.signal(signal.SIGCHLD, signal.SIG_IGN)

这种设置会让操作系统自动回收所有僵尸进程，此时你再手动调用os.waitpid(x, 0)就会因为目标进程的状态已被系统回收而无限阻塞——没有可读取的进程状态了。

解决方法：

• 检查代码中是否有全局的SIGCHLD信号处理设置，若有，要么移除该设置，要么改用非阻塞的waitpid调用（os.waitpid(x, os.WNOHANG)）轮询状态，同时兼容系统自动回收的情况。

2. 多线程环境下的waitpid竞争 #

当你在一个线程中调用fork()时，子进程只会继承当前调用fork的线程，父进程的其他线程会在子进程中直接终止。但父进程侧可能存在以下问题：

• 另一个线程正在调用os.waitpid(-1, 0)（等待任意子进程），已经取走了你目标子进程的退出状态，导致当前线程的os.waitpid(x, 0)因无对应状态而卡住。
• SIGCHLD信号被父进程中的某个线程捕获并处理，提前消耗了目标子进程的状态。

解决方法：

• 确保整个父进程中，对同一子进程的waitpid操作是唯一的——不要多个线程同时等待同一个pid。
• 如果需要在多线程中管理子进程，建议用一个专门的线程统一处理所有SIGCHLD信号和waitpid操作，避免竞争冲突。

3. 等待的pid存在有效性问题 #

虽然ps显示defunct进程的pid是你要等待的x，但可能存在：

• 该pid已被操作系统复用（长时间运行的程序中概率较高），但僵尸进程还未被清理。
• 你误将子进程pid和线程ID混淆（不过你提到已追踪确认，这个可能性较低）。

验证方法：

• 调用os.waitpid(-1, os.WNOHANG)尝试获取任意子进程的退出状态，如果能拿到状态，说明目标pid的状态已被处理或pid有误。
• 打印你要等待的pid，和ps输出的defunct进程pid对比，确认完全一致。

4. 子进程未真正完成退出（虽显示defunct） #

极少数情况下，子进程虽然调用了sys.exit()，但因资源无法释放（比如未关闭的文件锁、网络连接泄漏），导致内核无法完全回收进程资源，表现为僵尸进程，同时父进程的waitpid无法获取状态。

解决方法：

• 在子进程的sys.exit()之前，确保所有资源都被正确释放：关闭文件句柄、释放锁、终止网络连接等。
• 可以在子进程中用os._exit()代替sys.exit()——sys.exit()会触发Python的清理流程（比如atexit钩子），若清理过程出错可能导致进程无法正常退出；而os._exit()直接终止进程，跳过Python的清理，更适合fork后的子进程。

快速调试步骤 #

1. 在父进程中添加打印，确认调用waitpid的pid和ps显示的defunct进程pid完全一致。
2. 临时将os.waitpid(x, 0)改为os.waitpid(x, os.WNOHANG)并循环检查：返回(0, 0)说明进程未退出；返回(x, status)说明状态已获取；抛出异常说明pid不存在或状态已被处理。
3. 检查代码中是否有SIGCHLD信号处理逻辑，临时注释后再测试。

内容的提问来源于stack exchange，提问作者Rodrigo Formighieri