Reap orphaned processes adopted by the wrapper

[Sayan-]

Summary

The wrapper is pid 1 in both the container (ENTRYPOINT) and the unikernel (Kraftfile cmd). That makes it the machine's reaper: any process whose parent exits before it does gets reparented onto the wrapper. Nothing waited on those, so every one stayed a zombie holding a pid slot until the instance died.

Chromium relaunches are the usual source, one crashpad handler each. An instance running normally never notices. One whose services crash-loop accumulates them without bound, and the cost is not local to the browser: every /proc walk on the host scales with the pid count, so anything else sharing that kernel gets slower too. A long-lived instance in a restart loop was observed holding roughly 147k zombie pids.

Why not wait4(-1)

The obvious reaper is a SIGCHLD handler calling wait4(-1, WNOHANG) in a loop, but that is unsafe here. os/exec waits on a specific pid; if the reaper collects one of our own children first, that Cmd.Wait fails with ECHILD and its exit status is lost. main blocks on supervisord's exit status to decide when the instance is done, so losing that race would change shutdown behavior.

Instead the wrapper records the commands it starts and only ever waits on a pid it does not own. Zombie children are found by scanning /proc, and the ownership lock is held across Start so a concurrent reap cannot observe a child in the window between fork and registration.

Ownership is keyed by command identity, not by a bare pid flag. Cmd.Wait reaps the process before waitOwned can take the lock, which frees the pid for reuse, so a release that lands late would otherwise evict a newer command's entry and expose it to the reaper. releaseOwned only deletes while the pid still maps to the same command.

This adds startOwned / waitOwned / runOwned and routes the wrapper's existing exec.Command call sites through them. No behavior change at those call sites.

An init process such as tini would also solve the pid-1 problem, but only on the ENTRYPOINT path. The unikernel boots /wrapper directly through the Kraftfile, so fixing it in the binary covers both without adding a new component to the VM boot path.

Testing

go build, go vet, gofmt and go test -race -count=3 pass on server/cmd/wrapper.

reap_test.go covers the three properties that matter:

• an unowned zombie child gets collected, which is the crashpad case
• an owned zombie child is left alone and its Wait still returns cleanly, which is the regression guard against the wait4(-1) approach above
• a stale release does not evict a later holder of the same pid

Each was checked against a deliberately broken implementation to confirm it fails when the property is violated, rather than passing vacuously.

Not yet exercised in a real image build. Worth a boot test on both profiles before this leaves draft.

Note for review

Stacked on #350, which fixes the one leak the wrapper causes directly rather than adopts. Both touch supervisord.go. Review that one first.

---

Note

Medium Risk
Changes pid-1 process lifecycle and supervisord wait paths; incorrect reaping could still break shutdown or leak zombies, though tests guard the main race cases.

Overview
Adds a pid-1 orphan reaper so adopted zombie children (e.g. Chromium crashpad handlers after relaunches) are collected instead of accumulating until instance death and slowing host /proc walks.

Reaping uses SIGCHLD plus a 30s ticker and scans /proc for zombie children, but only Wait4s pids not registered as “owned” — avoiding a global wait4(-1) that would race with os/exec and break supervisord shutdown semantics (ECHILD / lost exit status).

Introduces startOwned / waitOwned / runOwned with lock-protected registration at fork time and releaseOwned keyed by command identity so stale releases cannot drop a newer pid holder. main starts the reaper before any forks and routes supervisord lifecycle through waitOwned; supervisord.go routes log tail and runStream through the owned helpers.

reap_test.go covers unowned zombie collection, owned zombies left for Wait, and safe release when pids are reused.

^{Reviewed by Cursor Bugbot for commit 339f194. Bugbot is set up for automated code reviews on this repo. Configure here.}

[Sayan-]

seems overly complicated relative to problem statement. skipping for now