很多人直觉上觉得，我父进程里 signal.signal(signal.SIGINT, handler)注册好了，fork出来的子进程自然也会用这个 handler。但实际跑起来你会发现各种诡异——要么信号根本没反应，要么直接默认终止了。

咱们一步步拆。

1. 最典型的翻车现场：subprocess.Popen启动的子进程

这是最常见的坑。你用 Popen启动一个子进程，然后在父进程里给它发信号：

import subprocess

import signal

import os

# 启动一个长时间运行的子进程

proc = subprocess.Popen(['sleep', '100'])

# 父进程里注册 SIGINT 处理器

def handler(signum, frame):

print("父进程收到信号，但不杀死子进程")

signal.signal(signal.SIGINT, handler)

# 模拟 Ctrl+C

os.kill(proc.pid, signal.SIGINT)

这里有个关键点：subprocess.Popen启动的子进程，它的信号处理机制跟你父进程完全隔离。sleep命令自己有默认的 SIGINT处理行为——直接退出。你父进程里怎么注册 handler 都影响不到它。

但这还算符合预期，毕竟人家是独立进程。

2. 真正诡异的：os.fork()后的信号处理

这才是让人挠头的地方。看这段代码：

import os

import signal

import time

def handler(signum, frame):

print(f"进程 {os.getpid()} 收到信号")

signal.signal(signal.SIGUSR1, handler)

pid = os.fork()

if pid == 0:

# 子进程

print(f"子进程 {os.getpid()} 开始运行")

time.sleep(10)

else:

# 父进程

print(f"父进程 {os.getpid()} 发送信号给子进程 {pid}")

os.kill(pid, signal.SIGUSR1)

os.wait()

大部分情况下这段代码能正常工作，子进程会打印出 "子进程 xxx 收到信号"。但如果你在 fork 之前做了某些操作，或者在某些特定版本的 Python 下跑，就会出现：

子进程根本没有执行 handler，而是直接默认终止了。

为什么？

3. 罪魁祸首：Python 信号处理的“延迟执行”机制

Python 的信号处理不是真正的 OS 信号处理。真正的 OS 信号处理器是一个极其精简的 C 函数，它只做一件事：设置一个标志位，然后立即返回。真正的 Python handler 是在主解释器循环的下一条字节码执行前才被调用。

这意味着什么？意味着 fork()那一瞬间，如果父进程正好有一个待处理的信号还没来得及执行 Python handler，子进程就会继承这个“挂起”的状态。

但更坑的是：fork()之后，子进程的 Python 解释器状态是不确定的。有些内部锁、内存状态可能处于中间态。这时候如果触发了信号处理流程，轻则 handler 不执行，重则直接 crash。

这就是为什么 Python 官方文档里有一句很隐晦的警告：

"尽管子进程会继承父进程的信号处理器，但在子进程中设置信号处理是不可靠的。"

翻译成人话：别指望 fork 后子进程里的信号处理能正常工作。

4. 更隐蔽的坑：threading+ fork+ signal

如果你在父进程里开了线程，再 fork，那就更热闹了。只有调用 fork()的那个线程会被复制到子进程里，其他线程直接消失。如果某个线程正持有解释器锁或者在处理信号相关的内部数据结构——

子进程一启动，这些数据结构的完整性就是薛定谔的状态。你这时候再注册信号处理器或者接收信号，什么奇怪的事情都可能发生：死锁、段错误、handler 被静默忽略……

5. 正确做法：子进程里重新注册

别偷懒，也别信继承。在子进程的入口处，老老实实重新注册一遍：

pid = os.fork()

if pid == 0:

# 子进程重新注册所有需要的信号处理器

signal.signal(signal.SIGUSR1, child_handler)

signal.signal(signal.SIGTERM, child_term_handler)

# ... 业务逻辑

如果你用的是 multiprocessing模块，它内部已经帮你处理了一部分，但也不是完全的。multiprocessing.Process启动的子进程会尽量重置信号状态，但如果你自定义了复杂的 handler，最好还是在子进程的 run()方法里显式设置。

总结

场景

行为

建议

subprocess.Popen

子进程独立，不继承 Python handler

正常，别多想

os.fork()后

理论上继承，实际上不可靠

子进程里重新注册

threading+ fork

极易出现竞态条件

尽量避免这种组合

multiprocessing

相对安全，但非绝对

复杂 handler 手动重设

一句话：别信任 fork 带来的信号处理器继承，子进程里自己动手重新绑一遍。这是最稳的做法。

ITPub博客

Python 在子进程中捕获信号的奇怪行为

最新文章