Python subprocess 超时后子进程还在跑：用进程组和收尾顺序彻底清理

报表导出接口跑外部命令到30秒超时后，Python抛出了 TimeoutExpired，监控上看父进程也消失了，但几分钟后服务器CPU占用还在不断上涨。真正偷偷留着的是命令启动的子进程，甚至是子进程后续派生出来的孙进程。只调用 process.kill()，通常只能干掉最外层那一个PID，根本清不干净后续派生的整个进程树。

故障现场：超时的PID没了，CPU占用却没降

假设服务收到一个导出请求，调用 render-report 生成PDF文件。这个命令内部又会拉起字体扫描、文件压缩两个子进程。Python代码里只存了最外层的 Popen.pid，超时后只执行 kill()，最外层的父命令虽然退出了，下面两层子进程还在继承管道资源，继续占用临时目录读写。

排查的时候别死盯着单个PID看，要直接看进程组信息：

ps -eo pid,ppid,pgid,stat,etime,cmd | grep -E 'render-report|font-scan|pdf-pack'

如果 PGID 的值完全相同，就说明这些进程属于同一个进程组。我们真正要清理的是这一整组进程，不是某一个早就已经退出的父进程。

启动阶段就建好独立进程组

在类Unix系统上，最简单稳妥的做法是给 subprocess.Popen 传入 start_new_session=True 参数。子命令会直接成为新会话的会话首进程，同时拥有完全独立的进程组。后续我们对负的PGID发送信号，信号就能直接覆盖组内所有进程，不用挨个找PID。

import os
import signal
import subprocess
import time


def start_report(command):
    return subprocess.Popen(
        command,
        stdout=subprocess.PIPE,
        stderr=subprocess.PIPE,
        text=True,
        start_new_session=True,
    )


def stop_process_group(process, grace_seconds=2.0):
    if process.poll() is not None:
        return "already-exited"

    group_id = os.getpgid(process.pid)
    try:
        os.killpg(group_id, signal.SIGTERM)
    except ProcessLookupError:
        return "group-already-gone"

    deadline = time.monotonic() + grace_seconds
    while process.poll() is None and time.monotonic() 

这里有个很容易漏掉的细节顺序：先调用 poll() 判断父进程是不是已经退出，再去获取它的PGID。如果父进程已经消失，os.getpgid() 可能直接抛出 ProcessLookupError。清理逻辑要把这种情况当成正常的幂等结果处理，不要直接判定成一次新的故障上报。

从TERM到KILL的收尾边界要写得明明白白

上来直接发SIGKILL看起来干脆利落，但外部命令根本来不及删除临时文件、关闭输出句柄，也没法写出最后一条错误日志。生产环境的代码更适合先发TERM信号，等2秒左右的缓冲时间，最后只对仍然存活的进程组发KILL兜底。

这个等待时间不是越长越好。报表类任务业务超时设成30秒的话，超时后的清理窗口设2秒就足够；如果业务任务需要写几十MB的结果文件，最好把「业务超时阈值」和「清理宽限期」分开记录，别让监控把两个数值混成一个指标，引发误告警。

try:
    stdout, stderr = process.communicate(timeout=30)
except subprocess.TimeoutExpired:
    cleanup_result = stop_process_group(process, grace_seconds=2)
    stdout, stderr = process.communicate()
    logger.warning(
        "report timeout cleanup=%s stdout_tail=%r stderr_tail=%r",
        cleanup_result,
        stdout[-500:],
        stderr[-500:],
    )

communicate() 的第二次调用非常关键，它负责把管道里剩下的输出内容全部读完，把父进程资源彻底回收。不然就算进程组里的所有进程都清干净了，Python主进程自己也可能因为管道生命周期没处理完留下资源泄露问题。

权限、平台和信号的适配细节不能省略

运行用户必须拥有向进程组发信号的权限

应用进程只能清理自己启动的子进程，不能随便拿到一个PGID就直接发信号。代码里要记录下 pid、pgid 和进程启动时间，执行清理前先确认目标进程仍然属于当前业务任务。如果出现 PermissionError，直接触发告警终止后续操作就行，别擅自把清理范围往更大的方向调整。

Windows环境不要直接照搬os.killpg逻辑

os.killpg 是Unix体系下的进程组专属接口。需要跨平台运行的程序，得把「创建独立任务组」和「结束整棵进程树」两个逻辑抽成不同平台的独立实现，Windows环境可以评估用Job Object能力实现；如果代码只部署在Linux服务器上，最好在配置项和启动自检逻辑里明确标注这个运行前提。

标准输入输出处理要避免管道堵塞

外部命令很可能持续往stderr输出大量日志。使用 stdout=PIPE 和 stderr=PIPE 重定向之后，必须由 communicate() 统一消费输出内容，不能在超时处理的路径里只等进程退出不读管道内容。如果是会产生大量日志的任务，还可以考虑把输出直接写到临时文件里，或者接入做了流量限制的日志通道。

上线前用进程树和资源结果做验收

验收别只盯着清理函数的返回值看。测试完成后手动执行一次 ps，确认 render-report、font-scan 和 pdf-pack 全部不存在，再观察一小段时间的CPU占用、打开文件句柄数和临时目录占用状态。只有这几个结果同时符合预期，才算真正把所有资源都回收干净。

常见问题：超时清理还要注意什么

为什么不直接调用process.kill就完事？

这个方法只会杀死Popen对象管理的那一个PID。外部命令后续派生出的子进程不会跟着一起退出，提前建立独立进程组才能让清理范围和单次业务任务完全对应，不会漏杀任何派生进程。

进程已经提前退出的情况下还需要发信号吗？

完全不需要。先用 poll() 做状态判断，同时打already-exited的诊断日志；如果后续获取PGID或者发信号的时候发现目标进程已经不存在，也按幂等成功逻辑处理，保留好相关诊断日志就可以。

清理宽限期设置成多长比较合适？

从1秒到3秒的区间开始压测验证就很贴合实际。这个时间只要能覆盖进程正常关闭资源的动作就够了，别用一个特别长的宽限期，去掩盖业务任务本身的超时设计问题。

总结：把一次外部命令调用当成一棵可完整回收的进程树

Python调用外部命令的超时清理治理，核心从来不是「把那个出错的PID杀掉」，而是从进程启动阶段就建立独立的进程组，再按TERM信号、等待缓冲、KILL兜底的固定顺序结束整组进程，最后用 communicate() 完成管道资源的回收。配合PID和PGID的全链路记录、发送信号前的权限校验，以及上线前的残留进程验收流程，报表导出这类任务就不会在接口返回超时之后，还在后台默默消耗服务器的计算资源。