[BUG] docker-buildx buildx dial-stdio --progress=plain processes leaks from integration tests when suite is interrupted

[invidian]

Expected Behavior

docker-buildx buildx dial-stdio --progress=plain to not accumulate over time when test suite gets interrupted.

Actual Behavior

When running go test right now and hitting CTRL+C while suite is running, orphan docker-buildx buildx dial-stdio --progress=plain process (es?) are left running and never gets cleaned up.

Steps To Reproduce

No response

Are you willing to submit PRs to contribute to this bug fix?

• Yes, I am willing to implement it.

Other

The following AI generated patch seems to be addressing this issue globally, so at least we don't have to make cleanup explicit. This should be robust enough when Go test binary gets SIGKILL'ed.

diff --git test/testenv/buildx.go test/testenv/buildx.go
index b099b61..5208731 100644
--- test/testenv/buildx.go
+++ test/testenv/buildx.go
@@ -13,6 +13,7 @@ import (
        "os/exec"
        "strings"
        "sync"
+       "syscall"
        "testing"
        "time"


@@ -105,6 +110,15 @@ func (b *BuildxEnv) dialStdio(ctx context.Context) error {
                // the buildx dial-stdio process from cleaning up its resources properly.
                cmd := exec.Command("docker", args...)
                cmd.Env = os.Environ()
+               cmd.SysProcAttr = &syscall.SysProcAttr{
+                       // Put the child in its own process group so we can kill the entire
+                       // group (docker + docker-buildx plugin) during cleanup.
+                       Setpgid: true,
+                       // Send SIGTERM to the child process when the parent (test process) dies.
+                       // This prevents dial-stdio processes from being orphaned when the test
+                       // suite is interrupted or crashes.
+                       Pdeathsig: syscall.SIGTERM,
+               }

[cpuguy83]

The one issue with pdeathsig is the process will get killed when the calling thread exits, which we don't really have control over in Go unless we use runtime.LockOSThread and then just never exit.

I think maybe what we need to do here is in the signal handler in main-test is make sure testEnv is shutdown rather than relying on context.
Likewise anywhere else we creete a test env (I think just one test does a separate one... which I have a PR to eliminate), that would also need to be shutdown.