libct: do not hang on a half-dead "runc init"

[kolyshkin]

Fixes #5087.

The problem

SCMP_ACT_KILL is SECCOMP_RET_KILL_THREAD: the kernel does do_exit(SIGSYS) on the thread that made the syscall, and on that thread only. runc init locks its main goroutine to the initial OS thread, which is the thread group leader, so a syscall blocked this way kills the leader while the rest of the Go runtime threads live on.

What is left is a process that looks dead and is not:

• the leader is a zombie, but release_task() for it is delayed until the last thread exits, so /proc/$pid/stat says Z;

• exit_files() drops only the leader's reference to the shared files_struct, so the child ends of the sync socket and of the exec fifo stay open — the parent never sees an EOF;

• exit_notify() defers do_notify_parent() until the thread group is empty, so there is no SIGCHLD, wait(2) does not return, and a pidfd never becomes readable — I checked the latter explicitly, with and without PIDFD_THREAD:

  leader state=Z
  flags=0x0   n=0 revents=0x0
  flags=0x80  n=0 revents=0x0   /* PIDFD_THREAD */
  

The parent therefore waits forever. Which wait it gets stuck in depends on where init dies; with write blocked and no --debug, init dies writing to the exec fifo (seccomp is applied just before that), and runc run hangs in waitForFifoReady. The reporter hit the same thing in ReadPacket on the sync socket.

This also means the pidfd fast path added for the fifo wait cannot detect this case at all — /proc/$pid/stat is the only signal that reports a zombie thread group leader.

The fix

Add waitForInitWrite(fd, pid): poll(2) with a 100 ms timeout, and on timeout check whether init went away via /proc. Use it for both places where the parent waits on init — reading the sync socket and waiting for the exec fifo — replacing the three fifo-specific wait helpers.

Two more things were needed to make the failure actually terminate:

• once a dead init is detected, kill its leftover threads. They keep the container's stdio descriptors open, and whoever inherited those (runc run's own IO copying goroutines, or bats) would then wait for an EOF just as long.
• drop the p.wait() in the setnsProcess.start error path — a half-dead child is never reaped, so that wait4(2) never returns. The deferred error handler terminates and reaps it anyway, and SIGKILL is group-wide.

Testing

Before, runc run with {"names": ["write"], "action": "SCMP_ACT_KILL"} hung indefinitely, leaving a zombie and a cgroup that could not be removed. After:

$ runc run test
ERRO[0000] runc run failed: wait for exec fifo: container init process died unexpectedly
real    0m0.136s

No leftover process, no leftover cgroup, runc list is empty. A container without the profile still runs in 28 ms, i.e. the poll timeout costs nothing on the healthy path (the first poll(2) returns immediately).

Two tests:

• a unit test that builds the exact kernel state — a helper process that starts a second thread and then exit(2)s its leader from init(), the only place where Go guarantees the main thread — and checks that we notice. It needs no root, no busybox and no seccomp, and runs in 0.1 s.
• an integration test in run.bats. It gives the container its own stdio rather than the one bats captures: should this regress, the leftover threads would keep bats' end open and the suite would hang instead of reporting a failure. Verified that it passes with the fix and fails (in 35 s, without hanging) without it.

https://claude.ai/code/session_01GtF433o8i3BrjqTZqT5xk7