jerboa-prog-* temp artifacts leak on kill/crash (unbounded /tmp growth; ENOSPC incident) #76
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
jerboa-prog-XXXXXXtemporary artifacts accumulate without bound when jerboa-built programs are killed or crash before normal exit. On our Bot Commons validation host this filled the jail rootfs (125,834 artifacts / 61 GB between Sep 11–13, 2026), drove the filesystem to 109% capacity, and an unrelated production SQLite database was truncated to 0 bytes by the resulting ENOSPC.Creation sites (current master)
jerbuild.sswrite_program_tmpfile()(~line 2762):mkstemp("%s/jerboa-prog-XXXXXX")boot file;unlink(prog_path)only runs afterSscheme_programreturns normally (~line 2795).support/build-binary.sh(~line 420) andsupport/multicall-main.c(~line 721): same pattern.jerboa-prog-*directories for extracted library bundles (ensure_extracted()), held for the process lifetime.Why it leaks
Any supervisor that runs untrusted jerboa programs with a timeout (our validator kills submissions routinely) or any crash/SIGKILL skips the
unlink, leaving one artifact per run. Long-lived services running many short-lived programs make this unbounded. Observed leak rate on our host: ~2,100/day.Reproduction
jerbuild binaryany program; note it is a static multicall binary.timeout 1with a workload longer than 1s (orkill -9it).ls /tmp/jerboa-prog-*— the boot file remains.Suggested fixes (any one closes the operational risk)
Sscheme_programhas loaded it), rather than at process exit.jerboa-prog-*artifacts older than e.g. 24h in the same tmpdir (owner check).O_TMPFILEwhere available.Option 1 looks smallest: the boot file is fully read at heap-build time.
Environment
jerbuild binary --static-native.Happy to send a PR for option 1 if the approach sounds right.