[dany74q]

When a step is cancelled, buildkit SIGKILLs only the process it started: runc kill for a run, the exec'd pid for an exec. Its subprocesses can survive and keep the IO open, so runc never returns and the solve hangs. Under --oci-worker-no-process-sandbox the container shares the host pid namespace, and rootless runc can't enumerate the survivors without cgroups (opencontainers/runc#4398). An exec leaks the same way with the sandbox, since its children stay in the container's pid namespace. See #4483 and #2855.

The fix SIGKILLs the process group, since runc makes the process a session leader. Exec always kills the group first, and signals the pid only when there is no group. Run does this under NoProcessSandbox, which now passes a pidfile to runc run, before the usual runc kill, then also kills every process left in the init's mount namespace, pinned as soon as runc writes the pidfile, so a process that called setsid goes too. A SIGKILL sent by the client takes the same path.

[Copilot]

🟡 Changes recommended

PID reuse can kill unrelated processes, failure paths can still hang indefinitely, and the regression test does not exercise rootless operation.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Adds process-group cleanup for hung containers using NoProcessSandbox.

Changes:

• Records run/exec process IDs and kills surviving process groups.
• Adds cancellation coverage for run and exec paths.

File summaries

File	Description
executor/runcexecutor/executor.go	Implements process-group termination.
executor/runcexecutor/executor_linux.go	Enables PID files in no-sandbox mode.
worker/runc/runc_test.go	Adds cancellation regression coverage.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 3
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[ZRHann]

Hi, is this still being worked on? It would be very useful to me. Happy to help if needed.

[jsternberg]

Would there be any negative if, instead of only doing this with NoProcessSandbox, we just always did it?

[dany74q]

Would there be any negative if, instead of only doing this with NoProcessSandbox, we just always did it?

none that i found, exec leaked the same way with the sandbox so it kills the group in both modes now. run already gets that from the pid namespace

[Copilot]

🟡 Changes recommended

Cancellation can still hang with detached output writers, and recycled process-group IDs can cause unrelated workloads to be killed.

3 open issues

• Reused pidfile ID can signal an unrelated process group · New
• Failed process kill causes unbounded wait on open output pipes · New
• This uses a pid read from a stale pidfile after the process has already received SIGKILL and after…

2 resolved since last review

• If reading or signaling the process group fails, this only logs the error and then waits…
• This regression test still constructs a rootful worker: newWorkerOpt hardcodes `rootless :=…

_{Review effort: Balanced}

[dany74q]

friendly ping @AkihiroSuda @jsternberg

[AkihiroSuda]

needs rebasing

[dany74q]

rebased

[dany74q]

pushed a fix for a race in the cleanup, could someone approve the ci runs on the new head?