runner: a sandboxed command terminated during its sandbox setup keeps running (Linux) #109

What happens

On Linux, terminate_process (or a timeout kill) of a sandboxed pipe process can leave its command running outside the Runner's reach, when the kill lands while bubblewrap is still setting up the sandbox.

bubblewrap's sandbox process sets its parent-death signal (--die-with-parent) only just before it runs the command. Killing the launcher inside that window leaves the sandbox running under PID 1. The command then runs to its end and keeps the Runner's output pipes open, so the Runner reports the exit only when the command ends on its own. The Runner has already reaped the launcher, so a second terminate does nothing.

How it was found

The P1R-C05 work on #108 traced a Linux CI failure of the P1R-C04 test mcp::independent_tests::an_independent_gateway_blocks_a_workspace_whose_records_and_runner_disagree to this window: the test terminates its sandboxed /bin/sleep 30 about 100 ms after the start. A process listing after a failing run showed the sandbox's inner stage with parent PID 1 and /bin/sleep 30 still running 20 s later. Details: #108 (comment)

The test is to wait for its command before terminating it. That fixes the test, not this behavior.

Fix direction

End the sandbox's PID namespace, not only the launcher: for example stop the launcher, kill its children, then kill the launcher. This changes termination, so it needs its own change and a test that a terminate issued during sandbox setup leaves no process behind.

Scope

The Linux sandbox (bubblewrap) only. Not part of the P1-RECOVERY units (#101) unless the owner adds it.