这次实验有一条结果看似矛盾：直接启动的命令返回0，Python却仍然等到超时。原因是命令已经退出，它启动的工作进程还持有输出管道。另一组中，只终止命令后，工作进程继续向文件追加记录。
如果你用Python调度转换、构建或批处理工具，需要验收的是整项工作的结束状态。本文提供五个可运行的本机对照，分别记录等待是否超时、直接进程的退出码、向哪个进程组发了信号，以及工作进程是否仍在执行。
下载完整超时清理实验：固定命令、五个场景与观察结果（ZIP）
先把等待对象和工作对象画清楚
解压进入process-timeout-lab-v1，运行python3 run_lab.py。需要Python 3.11+、POSIX会话与信号支持，以及系统的ps命令。本轮实测macOS、Python 3.14.4；没有在Linux或Windows上跑过，脚本会拒绝Windows。
run_lab.py（调用者）
└─ supervisor.py（Popen直接管理的命令）
└─ worker.py（实际工作进程）每个场景在新的临时目录运行。worker每50毫秒向自己的心跳文件追加一个点，并继承supervisor的输出管道。除正常结束场景外，工作循环最多持续约10秒；即使实验异常，也不会设计成无限运行。输入是固定的Python文件，不接收外部PID，不调用网络，不读写真实项目。
运行器先等就绪文件和第一个心跳，核对supervisor与worker确实属于本轮创建的同一个进程组，再开始250毫秒的等待。这样可以区分“进程尚未启动”与“工作已经开始但未按时完成”。这250毫秒不包含启动和就绪阶段，也不是全流程总时限。
只终止直接命令，心跳仍然增长
对照场景先调用communicate(timeout=0.25)，捕获超时后，仅执行p.kill()。本次supervisor的退出码变为-9，但随后带200毫秒时限的第二次communicate仍超时；再观察200毫秒，worker的心跳文件新增了4个点。
这不是预先写入的“子进程还活着”状态。测试读取的是工作进程实际追加的文件，且它尚未关闭继承的输出管道。对照观察结束后，脚本仍会清理自己创建的整个进程组，不会把实验工作进程留在后台。
Python官方文档对两个接口的约定不同：subprocess.run(timeout=...)超时后会终止并等待它直接启动的子进程；Popen.communicate(timeout=...)超时本身不会终止子进程。两者都不能被理解成对任意后代进程及其外部工作的一次性取消保证。本文对照实际测试的是后者加显式kill的路径。
在启动时划定信号范围
实验创建supervisor时使用参数列表和start_new_session=True。在本次POSIX运行中，它成为新会话和进程组的组长，worker保持在该组；就绪记录中的两个PGID都等于本次Popen返回的PID。
p = subprocess.Popen(
[sys.executable, '-B', supervisor_file, lab_directory, mode],
stdin=subprocess.DEVNULL,
stdout=subprocess.PIPE,
stderr=subprocess.PIPE,
start_new_session=True,
text=True,
)设置新会话的作用是给后续信号提供明确范围，不会自动启动超时计时器。实验的send_group()只接受本函数刚创建的Popen对象，用os.killpg(p.pid, signal)向该组发送信号；不会读取任务文件里的任意PID，也不会按进程名批量查杀。
普通慢任务先收到SIGTERM，然后继续收集管道；如果宽限期结束仍没有完成，就发送SIGKILL，并对最后一次communicate另设2秒时限。下面是包内流程的核心片段，完整实现还包括就绪核对、异常清理及结果检查：
try:
out, err = p.communicate(timeout=0.25)
except subprocess.TimeoutExpired:
timed_out = True
send_group(p, signal.SIGTERM, sent)
try:
out, err = p.communicate(timeout=0.25)
except subprocess.TimeoutExpired:
send_group(p, signal.SIGKILL, sent)
out, err = p.communicate(timeout=2)本次“stubborn”场景让supervisor和worker都忽略SIGTERM，因此真实走到了SIGKILL分支。只写上SIGTERM却没有宽限期和后续状态检查，不能证明取消完成。反过来，直接强制终止也不给程序保存临时状态的机会；宽限长度应由实际任务的清理需求决定，实验里的250毫秒只服务于短小对照。
退出码、超时和工作进程状态分别记录
以下为本次五个场景的结果。退出码属于supervisor；负数对应本次POSIX信号终止，不是跨平台通用错误码。
| 场景 | 等待超时 | 命令退出码 | 清理观察 |
|---|---|---|---|
| 正常完成 | 否 | 0 | 输出包含worker-done |
| 只kill命令的对照 | 是 | -9 | worker继续写；随后补做组清理 |
| 普通慢任务 | 是 | -15 | SIGTERM后输出管道结束 |
| 忽略SIGTERM | 是 | -9 | 升级到SIGKILL |
| 命令先退出 | 是 | 0 | worker持有管道；组清理后结束 |
最后一行最容易被漏掉。supervisor启动worker后立即退出0，worker仍在原组中继续执行。communicate还要等输出管道到达EOF，因此最终记录同时包含timeout_observed=true与supervisor_returncode=0。如果只按returncode生成“任务成功”，就会把这次超时漏掉。
同样，主命令已经退出时，不能只因为p.poll()不再是None就跳过后代清理。本例保存的是自己在启动时建立的进程组标识；在很久之后拿一个旧PID去猜组身份则是另一回事，存在PID复用等风险，不属于这份短生命周期实验的使用方式。
如何确认停止，而不只确认信号发出
清理之后，运行器再次读取心跳文件，等待250毫秒后确认大小不再增长；同时用ps检查已记录的worker PID。本次五组都观察到worker PID不存在，直接进程也已由communicate取得退出码，临时目录最终删除。
脚本也识别Z状态：僵尸进程已经不执行代码，但仍等待父进程或系统回收，不等于PID已经消失。若在另一环境看到Z，应保留这个区别，不能把“停止运行”写成“所有进程记录已回收”。心跳不增长也不能单独证明进程退出，所以这里还核对了进程状态。
如果就绪失败、清理后的communicate继续超时，或ps仍显示运行/睡眠中的工作进程，实验会报错，不输出成功报告。异常路径只针对本次创建的进程组；没有关闭系统服务或搜索其他用户的进程。本文没有模拟调用者被强制杀死、断电或操作系统卡死，finally不保证在这些情况下执行。
把实验迁到真实任务前，还缺哪些条件
这份包是可复现的诊断实验，不是接收任意命令的生产执行器。它的输出很小，因此使用PIPE和communicate；真实工具若持续输出大量内容，内存缓冲可能成为问题，应另做输出限额、日志轮转和读取策略。文件转换产生的半成品也需要业务层决定保留、清理还是原子替换，发信号不会自动回滚磁盘或远端副作用。
进程组并不等于完整进程树容器。后代如果自行创建新会话或改变进程组，就可能离开本例的信号范围；本文没有测试这种逃离路径，也没有为不可信程序提供隔离。Linux服务可结合任务所属的服务管理和资源控制机制，Windows应设计适合其平台的作业管理方式，不能直接照搬killpg。
实际验收应至少保留：启动范围、等待超时与否、直接进程退出状态、信号顺序、后代执行状态，以及输出文件是否完整。先用受控程序复现自己的失败分支，再替换为真实工具；不要仅把timeout参数加大就把问题记为解决。
完整包含运行器、supervisor、worker及本次观察JSON，MIT许可。SHA-256：7155884fa19e88bc3281722c093820d7f8f5d835dd2ff5bc89c901079d20d197。封面由AI生成，用时钟、停止符号和进程组边界表达主题，不是系统监控或实测终端截图；正文结果来自本次实际运行。
资料：Python subprocess：超时、输出管道与新会话；Python os.killpg：向进程组发送信号。前置阅读：subprocess参数列表与命令字符串、HTTP超时后如何避免重复写入、Git二分定位中的测试结果与退出状态。
资料查阅与编辑日期：2026年11月4日。作者：玖柒。
