使用Python subprocess时，Ctrl-C与kill -2为何行为不同？

你观察到的差异核心原因在于：Ctrl-C和kill -2虽然都发送SIGINT信号，但它们的信号目标对象完全不同，终端的进程组机制是导致结果差异的关键。

1. Ctrl-C的信号传递逻辑 #

当你在终端按下Ctrl-C时，终端会把SIGINT信号发送给当前终端会话的整个前台进程组，而非仅仅Python主进程：

• Python主进程会收到SIGINT信号
• 由subprocess启动的子进程（默认会继承主进程的进程组）也会同步收到SIGINT
  所以主进程和子进程都会响应信号并终止。

2. kill -2的信号传递逻辑 #

当你执行kill -2 <python-pid>时，信号只会单独发送给指定的Python主进程，不会传递给它的子进程：

• Python主进程收到SIGINT后会终止，但子进程因为没收到任何终止信号，会继续运行（后续会变成孤儿进程，最终被init/systemd进程收养）

3. Python信号处理的额外影响 #

还有一个细节：Python默认会捕获SIGINT并抛出KeyboardInterrupt异常，正常退出时会做资源清理，但如果是用kill单独发送信号，主进程的退出逻辑不会主动去终止子进程（除非你在代码里显式处理了SIGINT，比如调用subprocess.Popen.terminate()）。而Ctrl-C的场景下，子进程自己收到SIGINT，会自行终止，不需要主进程额外干预。

验证小技巧 #

你可以用这个命令查看进程组ID（PGID），直观验证进程组的差异：

ps -o pgid,pid,cmd

• 用Ctrl-C触发终止时，Python主进程和子进程的PGID是相同的
• 用kill -2只终止主进程后，子进程的PGID还是原来的数值，但父进程ID会变成1（init/systemd）

补充：如果希望用kill -2时也能同步终止子进程，可以在Python代码中捕获SIGINT信号，手动遍历并终止所有子进程；或者确保启动subprocess时使用默认的start_new_session=False（让子进程继承主进程的进程组）。

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