Skip to content

reap orphaned chromium/crashpad children to prevent zombie accumulation - #48

Open
tespio wants to merge 1 commit into
karust:mainfrom
tespio:fix/reap-zombie-children
Open

tespio wants to merge 1 commit into
karust:mainfrom
tespio:fix/reap-zombie-children

Conversation

@tespio

@tespio tespio commented Aug 25, 2026

Copy link
Copy Markdown

When a search request is aborted (CAPTCHA hang on a blacklisted IP, client timeout), the browser process group is SIGKILLed. The browser's crashpad / vassal children survive long enough to be reparented to this process — and in the shipped container this process is PID 1 with no external init, so unless it reaps them, nothing ever does.

Observed in production: ~4 zombie processes accumulated per aborted query (~120/day), unbounded until the container restarts, because rod only waits on its direct browser child (the crashpad orphans land on PID 1 and stay).

When a search request is aborted (captcha hang, client timeout) the browser
process group is SIGKILLed. The browser's crashpad/vassal children survive
long enough to be reparented to this process, which in the shipped container
is PID 1 with no external init, so nothing ever reaps them and the process
leaks zombies until the server exits (~4 per aborted query observed).

Rod already waits on its direct browser child; this reaper simply reclaims
whatever rod's Wait does not cover (races are harmless: the loser's wait
returns ECHILD and is ignored). Healthy searches are unaffected.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant