Go exec.Cmd取消后子进程仍存活的进程组处理边界

我在 Go 服务里用 exec.CommandContext 跑外部命令时，最容易误判的一点是：父进程退出，并不等于它拉起的子进程树已经清理。CommandContext 默认把取消动作实现为对 cmd.Process 调用 Kill，它针对的是一个 PID；如果命令又启动了 shell、编译器或长期运行的孙进程，后者仍可能持有 stdout/stderr 管道，表现为任务已经超时但 Wait 迟迟不返回。

官方资料：https://pkg.go.dev/os/exec

为什么杀掉 cmd.Process 后子进程还在

操作系统把父进程和它创建的子进程视为多个独立 PID。Go 的 Cmd 只直接持有启动出来的那个进程，默认取消逻辑不会自动遍历进程树。尤其是通过 sh -c、脚本或构建工具启动命令时，真正的工作进程可能已经换成了另一个 PID。

还有一个容易混淆的因素：Wait 不只等待退出状态，也会等待非文件型的 stdin、stdout、stderr 复制协程。子进程继承了这些文件描述符时，即使父进程被杀，管道仍可能保持打开。于是“父进程没了”和“任务资源已经收干净”是两个结论。

直接取消Go标准库的`exec.Cmd`时，默认只会给进程组首进程发终止信号，它拉起的子进程会脱离父进程托管给init进程残留成僵尸进程，只有提前把命令绑定到独立进程组，取消时遍历杀死整个进程组所有PID，才能彻底清理全部衍生进程。

用 Setpgid 建立可整体取消的进程组

Unix 环境下可以在 Start 前设置 SysProcAttr.Setpgid。当它为 true 且未指定其他组号时，子进程会以自己的 PID 作为新进程组 ID。随后使用 syscall.Kill(-pgid, signal)，负号表示把信号发给这个进程组，而不是一个单独的 PID。

package main

import (
    "context"
    "fmt"
    "os"
    "os/exec"
    "syscall"
    "time"
)

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
    defer cancel()

    // shell 只是示例：它再启动一个工作进程，验证取消覆盖整个进程组。
    cmd := exec.CommandContext(ctx, "sh", "-c", "sleep 30 & wait")
    // 让命令成为新进程组组长，组 ID 默认等于启动后的 PID。
    cmd.SysProcAttr = &syscall.SysProcAttr{Setpgid: true}

    finished := make(chan struct{})
    cmd.Cancel = func() error {
        if cmd.Process == nil {
            return os.ErrProcessDone
        }
        pgid := cmd.Process.Pid
        // 先给整组发送可处理的退出信号，保留清理机会。
        if err := syscall.Kill(-pgid, syscall.SIGTERM); err != nil {
            return err
        }
        // 宽限期后仍未收口时，再强制结束同一进程组。
        go func() {
            timer := time.NewTimer(800 * time.Millisecond)
            defer timer.Stop()
            select {
            case 

这个示例的关键不是把 Kill 换成另一个函数，而是先建立明确的组边界，再用负 PGID 发信号。SIGTERM 让程序有机会关闭文件、删除临时目录；宽限期后再用 SIGKILL 收尾，避免“取消成功但后台任务还在跑”。生产代码还应把这段 Unix 实现放入带平台 build tag 的文件中。

WaitDelay、Cancel 与 Wait 各自负责什么

可以把三个字段分开看：Cancel 决定上下文结束时先采取什么动作；WaitDelay 是等待异常拖延的时间上限；Wait 负责回收命令的状态和 I/O 协程。默认的 WaitDelay 到期后，Go 仍然调用父进程的 Process.Kill，不会自动对负 PGID 再发一次信号。因此文章中的自定义升级动作不能省略。

如果业务只需要终止一个确定的可执行文件，直接使用默认取消逻辑更简单；如果命令会再派生脚本、编译器、播放器或 worker，就应该把“谁属于本次任务”定义为进程组，并记录组级信号的结果。不要并发调用两个 Wait，也不要在自定义 Cancel 内再调用 Wait。

上线前的三个边界检查

1. 平台：syscall.SysProcAttr.Setpgid 和负 PGID 信号是 Unix 思路。Windows 需要用 Job Object 等平台机制，不能把这段代码硬编译过去。
2. 进程归属：只有把任务独占到自己的进程组，组级 SIGKILL 才不会误伤同组的其他工作。不要复用外部传入的 PGID。
3. 退出解释：上下文超时、*exec.ExitError、ErrWaitDelay 和管道复制错误含义不同，日志里至少记录取消原因、信号和命令退出状态。

我更倾向于把“优雅终止—有限等待—同组强杀—Wait 回收”作为一个小型执行器封装，而不是在每个业务 handler 里手写几行 Process.Kill。这样任务取消的边界、平台限制和审计字段才不会随着调用方变化。

相关问题

CommandContext 能自动杀掉孙进程吗？

不能把它当作进程树管理器。默认取消针对 cmd.Process，需要整组清理时自行建立进程组并发送组级信号。

为什么 WaitDelay 结束后仍可能有后台进程？

它的强制动作针对 Cmd 对应的进程，主要解决退出和 I/O 管道等待，不负责遍历或杀掉所有后代。

发送 SIGTERM 后是否还要调用 Wait？

要。信号只发起终止，Wait 才负责取得退出状态并释放 Go 侧资源；生产代码还应设置有限宽限期。