Go os/exec Cmd 怎样把取消信号传给子进程组

如果 Go 程序通过 exec.CommandContext 启动了一个会继续派生子进程的命令，取消上下文后看到的“主进程退出、后代还在运行”，通常不是 context 失效，而是取消范围只有一个 os.Process。要把取消信号传给整个进程组，Unix 下需要在启动时建立独立进程组，再用自定义 Cmd.Cancel 按组发送信号；Windows 则应使用控制台进程组或 Job Object 的平台实现。

这篇只解决取消传播、进程组和平台差异。复查时关注三个指标：取消后直接进程退出延迟、后代进程是否残留、Wait 是否被仍然打开的输出管道拖住。

核心做法是：CommandContext 负责触发取消，SysProcAttr.Setpgid 负责建立 Unix 进程组，Cancel 用负 PID 指向整个组，WaitDelay 负责最后的等待上限。

为什么 CommandContext 默认只终止直接子进程

CommandContext 会把上下文绑定到 Cmd。在上下文结束时，默认的 Cancel 调用的是命令对应的 Process.Kill，它的对象是直接子进程本身，不是这个进程创建出来的全部后代。于是命令内部再启动的 shell、编译器或辅助进程可能继续占用资源。

还有一个容易混淆的指标：即使直接子进程已经退出，Wait 也可能等待 stdout 或 stderr 的复制协程结束。若后代继承了这些管道描述符，管道没有 EOF，调用方就会误以为“取消没有生效”。所以取消范围和 I/O 收尾要分开设计。

Unix 下把取消信号扩展到整个进程组

Unix 方案分成两处：启动前用 SysProcAttr.Setpgid 把子进程放进独立组；上下文取消时，把自定义 Cancel 改成向负的进程组 ID 发送信号。下面的代码只展示 Linux、macOS 等 Unix 目标文件中的核心写法，注释说明了关键边界。

//go:build linux || darwin || freebsd || netbsd || openbsd || dragonfly || solaris

package runner

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

func runGroup(ctx context.Context, name string, args ...string) error {
    cmd := exec.CommandContext(ctx, name, args...)
    // 让子进程成为新进程组组长，后续信号才能按组发送。
    cmd.SysProcAttr = &syscall.SysProcAttr{Setpgid: true}
    // 给取消后的管道和迟迟不退出的子进程设置收尾上限。
    cmd.WaitDelay = 3 * time.Second
    cmd.Cancel = func() error {
        if cmd.Process == nil {
            return nil
        }
        // 负 PID 表示目标是进程组，而不是单个进程。
        if err := syscall.Kill(-cmd.Process.Pid, syscall.SIGTERM); err != nil {
            // 进程已经退出时不把正常收尾误判为业务失败。
            if errors.Is(err, os.ErrProcessDone) {
                return os.ErrProcessDone
            }
            return err
        }
        return nil
    }
    return cmd.Run()
}

这里的关键不是“把 Kill 换成另一个函数”，而是先让组边界存在。Setpgid: true 且没有指定 Pgid 时，子进程通常以自己的 PID 作为组 ID；syscall.Kill(-pid, SIGTERM) 使用负 PID 表示向该组发送信号。应用可以先发 SIGTERM 给清理机会，再让 WaitDelay 在超时后触发更强的收尾。

Cancel、WaitDelay 和 Wait 要分别负责什么

可以把三个职责拆开看：

因此，Cancel 不要自己调用 Wait；启动成功后仍由外层调用一次 Run 或 Start 加 Wait 完成回收。如果自定义取消返回普通错误，即使命令随后以成功状态退出，Wait 也可能返回这个取消错误。对已经退出的进程，可以按业务需要把等价于 os.ErrProcessDone 的情况视为正常收尾。

平台差异：Unix 进程组不应写进共享实现

syscall.SysProcAttr 是操作系统相关结构体，最佳实践是拆成 runner_unix.go 和 runner_windows.go，让公共层只依赖“启动、取消、等待”的接口。

• Unix：用 Setpgid 建立组，再向负 PID 发送信号；这是本文代码的适用范围。
• Windows：CREATE_NEW_PROCESS_GROUP 建立的是控制台进程组，组信号依赖控制台与控制事件；它不等价于 Unix 的负 PID 信号。
• Windows 若目标是可靠管理整个进程树，可把进程加入 Job Object，并在取消时对 Job 调用终止操作；这需要单独的 Windows API 封装。
• 跨平台公共代码不要假设 os.Process.Kill 会递归终止后代，也不要把 Unix 的 syscall.Kill 直接编译到 Windows。

用三个指标复查取消方案

不需要把“调用返回了 error”当成唯一判断。建议在适配层记录以下指标，并在 Unix、Windows 各自的实现中观察：

1. 退出延迟：从上下文结束到直接进程退出的时间，确认取消回调是否真的被触发。
2. 后代残留：命令派生辅助进程后，取消完成时检查进程组或 Job 中是否还留有成员。
3. Wait 延迟：区分进程没退出和管道未关闭，必要时设置合理的 WaitDelay，同时正确关闭自建的 Pipe。

如果第一个指标正常、第二个异常，问题在取消对象仍是单进程；如果前两个正常、第三个异常，重点检查 stdout/stderr 是否被后代继承。这个拆分比盲目加大超时更容易定位根因。

常见问题

只调用 cmd.Process.Kill 可以杀掉所有后代吗？

不能。它面向 Cmd 的直接进程；是否影响后代取决于平台机制和子进程自身行为，不能当作递归进程树终止。

设置 WaitDelay 后就不需要自定义 Cancel 了吗？

不需要混为一谈。WaitDelay 是等待上限，Unix 进程组的信号传播仍需要自定义取消逻辑；它更适合做最终兜底。