Go context.WithTimeout无法终止exec.CommandContext启动的sudo命令

为什么版本1、2失效，版本3可以正常返回 #

核心原因是exec.CommandContext的默认终止逻辑，只能覆盖直接启动的第一层子进程，而sudo场景下的进程是多层级链路：Go进程 → /bin/bash → sudo → 目标执行命令，且sudo启动时默认会创建独立进程组，默认信号无法穿透整个进程树，加上Wait调用的阻塞逻辑问题，最终导致函数卡住。

版本1的具体问题 #

• 标准库CommandContext在context超时的时候，只会给直接启动的/bin/bash进程发送SIGKILL，既不会穿透到sudo进程，也不会碰sudo拉起的目标业务进程。
• bash被杀死后，sudo和它的子进程变成孤儿进程继续运行，cmd.Wait()会一直阻塞等待所有关联进程的退出状态回收，因为没有配置独立进程组，内核无法正确将sudo进程组的退出事件传递给Wait调用，函数就会一直卡住不返回。
• 不带sudo的sleep 1h测试能正常生效，是因为进程链路只有Go→bash→sleep三层，bash被杀死后sleep会收到SIGHUP跟着退出，Wait能正常拿到所有进程的退出状态，自然不会阻塞。

版本2的具体问题 #

• 首先存在硬编码错误：创建cmd时传入的context是未定义来源的rpiCtx，不是函数入参的ctx，context监听逻辑和命令实际绑定的context完全脱节，超时逻辑根本不会按预期触发。
• 就算修正这个变量名问题，逻辑依然有缺陷：主goroutine全程同步阻塞在cmd.Wait()调用上。虽然goroutine里能监听到ctx超时、给进程组发SIGKILL，但Go的os/exec包在处理sudo这类会新建会话的进程时，会因为进程退出顺序、会话leader状态回收的问题，导致Wait无法正确感知到进程已经被杀死，持续阻塞等待状态返回，函数依然卡着回不来。

版本3能正常工作的核心逻辑 #

• 启动命令前设置了Setpgid: true，让bash、sudo、目标命令全部归属到同一个独立进程组，超时的时候直接给负的进程组ID发SIGKILL，能一次性把整个进程树全部杀死，不会留孤儿进程。
• 没有把主逻辑阻塞在cmd.Wait()上，而是把Start和Wait逻辑放到独立goroutine里，通过select同时监听两个事件：要么命令正常执行完从errs通道拿到返回值，要么ctx触发超时立刻主动杀进程组然后返回错误，从根本上绕开了Wait在sudo场景下可能出现的无意义阻塞，有明确的超时退出路径。

版本3是不是正确的实现方案 #

版本3的核心思路是对的，但还存在几个小缺陷，不算完全严谨的生产可用实现，需要修正几个点：

• 超时分支杀完进程组之后，没有主动回收进程资源，长时间运行会产生僵尸进程。正确做法是发完Kill信号之后，一定要读取errs通道的返回值，等Wait完成进程资源回收再退出，避免goroutine泄漏和僵尸进程。
• 没有处理syscall.Kill的返回错误，比如命令提前退出导致进程组不存在的场景，Kill会返回无进程的错误，虽然不影响主逻辑，但最好加判断忽略这类预期内的错误。
• 目前的逻辑里如果ctx是被主动cancel而不是超时，不会触发进程杀除逻辑，需要根据实际业务需求判断要不要在所有ctx.Done()场景下都清理进程，而不是只处理超时场景。

修正后的核心select逻辑片段可以参考：

select {
case <-ctx.Done():
    // 不管是超时还是主动cancel，都清理整个进程组
    if err := syscall.Kill(-cmd.Process.Pid, syscall.SIGKILL); err != nil && err != syscall.ESRCH {
        // 仅记录非预期错误，进程不存在的错误直接忽略
        log.Printf("kill process group failed: %v", err)
    }
    // 必须等待Wait返回，回收进程资源，避免僵尸进程和goroutine泄漏
    <-errs
    return ctx.Err()
case err := <-errs:
    return err
}

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