crun pid-file leak in /run/sprite-env/crun → tmpfs ENOSPC on long-lived Sprites

[heylife]

Hi wanted to report a bug where my sprites were unreachable. a restart fixed it, but seems like it will happen again for long live sprites?

Here what give me the LLM investigation :

• Sprites runtime 0.0.1-rc44, kernel 6.12.91-fly
• Example Sprite: heylife-pool-76ccec5a (sprite-81649d7c-b83b-4eff-8f59-1211ef739a87)
• Access pattern: our control plane does one crun exec … app per RPC via the @fly/sprites SDK (spawn/execFile WebSocket exec). Busy Sprites do ~400–600 execs/day.

Bug — pid-files accumulate and never get cleaned up
On every exec, crun writes a pid-file to the management-namespace tmpfs:

/run/sprite-env/crun/pid-<container-sha256>-<N>.pid

These are never removed, so climbs monotonically for the life of the container and the tmpfs eventually exhausts. Once full, every subsequent exec fails with:

write to `/run/sprite-env/crun/pid-<hash>-16496.pid`: No space left on device

We’ve hit this on 4 separate containers; the counter N at failure was consistently ~12,900–16,600:

container (sha256 prefix)   N range at ENOSPC   date
a4fd4e13…                   12,874 – 15,050     2026-05-25
90dc0550…                   13,468 – 13,624     2026-05-25
70a3c7f8…                   13,621              2026-05-25
ead3dee7…                   16,241 – 16,557     2026-07-11

A full machine restart clears the tmpfs and resets N to 0 — but the leak just starts over, so any actively-used Sprite refills in ~3–4 weeks. Nothing in the app container or the sprite-env CLI (info/services/checkpoints) exposes /run/sprite-env, so we have no way to monitor how close a Sprite is to the wall — it’s invisible until it fails.