嵌入式Python解释器中subprocess.Popen.send_signal(CTRL_C_EVENT)失效问题排查求助

我之前在嵌入式Python环境里碰到过几乎一模一样的问题，结合Windows控制台信号的工作原理，咱们来一步步拆解问题根源和解决办法：

为什么CTRL_C_EVENT会失效？ #

你猜的没错，父进程调用的SetConsoleCtrlHandler确实是核心问题：

• Windows的控制台信号（比如CTRL_C_EVENT）是发送给整个控制台会话的，当父进程注册了自定义的Ctrl Handler（或者设置为忽略信号），这个配置会影响到所有共享该控制台的进程——哪怕子进程用了CREATE_NEW_PROCESS_GROUP。
• 子进程默认会继承父进程的控制台信号处理策略，所以即使你发了CTRL_C_EVENT，子进程可能不会触发KeyboardInterrupt，而是直接忽略或者被父进程的处理逻辑拦截。
• 而CTRL_BREAK_EVENT之所以能终止子进程，是因为它默认不允许被忽略（除非显式调用SetConsoleCtrlHandler修改），但它会强制终止进程，跳过Python的异常处理链，自然就不会执行finally块的清理逻辑。

解决方案1：在子进程中恢复默认Ctrl处理逻辑 #

既然子进程继承了父进程的异常信号处理，那咱们就在子进程启动时显式恢复默认的CTRL_C处理，确保KeyboardInterrupt能被触发：

import ctypes
import time

class ScriptSubprocess:
    def __init__(self):
        self.stop = False

    def run(self):
        # 关键：恢复Windows默认的Ctrl+C信号处理
        # 第二个参数设为False，意味着移除所有自定义Handler，回到系统默认
        ctypes.windll.kernel32.SetConsoleCtrlHandler(None, False)
        
        try:
            while not self.stop:
                print("子进程运行中...")
                time.sleep(1)
                # 你的任务逻辑
        except KeyboardInterrupt:
            print("子进程收到中断信号！")
        finally:
            print("执行清理逻辑...")
            self.stop = True

这个方法的核心是让子进程重新响应CTRL_C_EVENT，触发Python的KeyboardInterrupt异常，进而走到finally块完成优雅退出。

解决方案2：改用管道通信实现优雅退出（更可靠） #

如果嵌入式环境的控制台信号机制本身就有问题，咱们可以彻底绕开信号，用管道通信让父进程主动通知子进程退出，这种方式完全不受控制台信号的限制：

父进程修改（Script类） #

import os
import sys
import subprocess
import time

class Script:
    def __init__(self):
        self.process = None
        # 创建匿名管道，用于父->子进程通信
        self.read_pipe, self.write_pipe = os.pipe()
        self.start()

    def __del__(self):
        if self.process and self.process.poll() is None:
            self.stop()
        # 关闭管道句柄
        os.close(self.read_pipe)
        os.close(self.write_pipe)

    def start(self):
        popen_kwargs = {
            'executable': sys.executable,
            'creationflags': subprocess.CREATE_NEW_PROCESS_GROUP,
            # 传递读管道的文件描述符给子进程
            'pass_fds': [self.read_pipe],
        }
        # 把读管道FD作为命令行参数传给子进程
        self.process = subprocess.Popen(
            ['python', os.path.realpath(__file__), str(self.read_pipe)],
            **popen_kwargs
        )

    def stop(self):
        if not self.process:
            return
        try:
            # 通过管道写入任意数据，通知子进程退出
            os.write(self.write_pipe, b'exit')
            self.process.wait()
            self.process = None
        except Exception as e:
            print(f"停止子进程时出错：{e}")

子进程修改（ScriptSubprocess类） #

import select
import os
import sys
import time

class ScriptSubprocess:
    def __init__(self, read_fd):
        self.stop = False
        # 将管道FD转为文件对象
        self.pipe = os.fdopen(read_fd, 'rb')

    def run(self):
        try:
            while not self.stop:
                # 非阻塞检查管道是否有数据（超时0.1秒，不影响主任务）
                ready, _, _ = select.select([self.pipe], [], [], 0.1)
                if ready:
                    # 收到父进程的退出指令
                    self.stop = True
                    break
                # 你的任务逻辑
                print("子进程运行中...")
                time.sleep(1)
        finally:
            print("执行清理逻辑...")
            self.pipe.close()
            self.stop = True

if __name__ == '__main__':
    if len(sys.argv) > 1:
        # 子进程模式：获取父进程传递的管道FD
        read_fd = int(sys.argv[1])
        p = ScriptSubprocess(read_fd)
        p.run()
    else:
        # 父进程模式：用于测试
        s = Script()
        time.sleep(5)
        s.stop()

这种方式完全依赖进程间通信，不需要依赖控制台信号，在嵌入式环境里稳定性更高。

排查步骤（帮你定位问题） #

如果上面的方案还没解决，你可以做以下验证：

1. 确认子进程在独立进程组：在子进程中打印os.getpid()和os.getppid()，然后用tasklist /FI "PID eq 子进程PID" /V查看进程组ID，确保和父进程不同。
2. 检查子进程的Ctrl Handler设置：用ctypes调用GetConsoleCtrlHandler，看是否被父进程修改了默认处理。
3. 临时禁用父进程的SetConsoleCtrlHandler：如果条件允许，暂时注释掉父进程中调用SetConsoleCtrlHandler的代码，测试CTRL_C_EVENT是否能正常工作，确认问题根源。

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