resource: release process slots on exit, not on wait

[congwang-mk]

Fixes #229.

Problem

The process limit took a slot when a fork was allowed, but freed it when a blocking wait4/waitid was entered, on the assumption that such a wait reaps exactly one child. Entering a wait is neither necessary nor sufficient for a process going away, so the count drifted in both directions.

Reproduced on main (0.8.8):

Case	Limit	Result
Children reaped with WNOHANG (the report)	50	fork 50 fails with EAGAIN
SIGCHLD set to SIG_IGN, kernel auto-reaps	10	fork 10 fails
Double fork, orphans reaped by init	10	fork fails after about 10 rounds
Blocking waitpid(1, 0) (ECHILD) before each fork	10	40 live children (bypass)
Raw fork(2) syscall on x86_64	5	30 live children (bypass)

The first three make the limit a lifetime fork budget, which is what the reporter hit with a long-lived agent. The last two let a sandbox run past the limit. Raw fork(2) was never counted because it was only notified when argv safety was required; glibc's fork() is clone(2), so ordinary programs never showed it.

Fix

Two commits:

1. Count bare fork(2). It is now notified unconditionally, so every process creation reserves a slot.
2. Release slots on exit, not on wait. The pidfd exit watcher frees the slot, exactly once per process, through a slot table in ProcessIndex keyed by PidKey. A pidfd turns readable however the process dies, so _exit, signals and the OOM killer are all covered. The slot belongs to the thread-group leader, so registering a thread also registers its leader.

Two gaps had to be closed for exit-based release to work:

• A child that forks and exits without any notified syscall was never registered. exit and exit_group are now notified, so it registers on its way out while pidfd_open still succeeds.
• The watcher runs asynchronously, so a parent that reaps a child and forks again at once could beat it. handle_fork polls the slot-holding pidfds before refusing a fork. The kernel marks the pidfd readable before the parent can observe the death, so this is deterministic.

handle_wait, its dispatch entry and the BPF carve-outs for non-blocking waits are removed. No ptrace, user namespace or cgroup is involved.

Known limits

• A child killed by a signal before it makes any notified syscall is never registered, so its slot leaks. The window is small (openat, close, socket, clone are always notified) and the leak only pushes the count up, so it cannot be used to get past the limit.
• A fork the kernel rejects after Continue (ENOMEM, host RLIMIT_NPROC) also leaks a slot, as it did before.
• Zombies no longer count against the limit, since the slot is freed at exit rather than at reap.

The issue also asks for a way to disable the limit. That is left out: with the accounting fixed, a large -P value is effectively unlimited, and treating 0 as unlimited would fail open for zeroed configs in the Go and C bindings.

Tests

• New integration tests in test_resource.rs, each forking more children in sequence than the limit allows at once: WNOHANG reaping, SIGCHLD auto-reap, orphaned grandchildren, concurrent short-lived children, the ECHILD wait loop (must stay at the limit), and raw fork(2). The WNOHANG, auto-reap, orphan and ECHILD tests failed before the fix.
• The existing blocking-wait test now runs with no headroom (max_processes=2), which exercises the at-limit pidfd poll.
• Locally: Rust lib (771) and integration (444) suites pass in release mode with one test thread; Python test_policy_fn.py and test_sandbox.py pass (97). The new process-limit tests passed 36 consecutive runs. The rest of the Python suite and the Go tests were not run locally.

🤖 Generated with Claude Code