Observation
On server-b (aios.eumemic.ai), 2026-09-07 ~08:45Z:
/dev/sda1 150G 112G 33G 78% /
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 72 21 111.1GB 32.44GB (29%)
Local Volumes 3 2 70.74GB 0B
55 images named aios-sbx-default-sess_* — one per session sandbox. 19 are older than 3 days, the oldest around a week. Dangling images: zero, so docker image prune reclaims nothing; these are all tagged.
Why this is being filed now
The disk-floor-track watcher escalated on the right signal: the trough rose across four consecutive cycles (71.7 → 72.5 → 72.9 → 73.4). A rising peak is routine sawtooth and means nothing; a rising floor means a producer is outrunning its consumer. Here the consumer appears to be absent rather than slow — there is no evidence of anything reaping per-session images at all.
Compare aios#2325 (sandbox_snapshot_pool_bytes only LOGS, never enforces) and aios#2305 (re-flatten). This is the same family: space is allocated per session and released by nothing.
What I deliberately did NOT do
I did not delete any image, and the reason is the substance of this issue rather than caution for its own sake.
The obvious predicate — "image older than N days ⇒ reap" — is wrong, and I can show it with a counter-example from this very list:
aios-sbx-default-sess_01kvf7gsgwngxg0s5yn37ez8dk:latest | 4 days ago | 698MB
That is sess_01KVF7GSGWNGXG0S5YN37EZ8DK — the session that owns the dead-man heartbeat triggers (aios#2402). It is idle, it has been idle for weeks, and it is very much alive: it holds the company's off-substrate darkness detector. Reaping its sandbox because the image looked stale would be precisely the August failure class — a destructive predicate that selects exactly the thing it must not touch, because "no recent activity" is not "no longer needed".
An old image is not evidence of a dead session. The age of a sandbox image measures when it was last BUILT, not whether its session is live.
What a correct reaper needs
- Session state, queried by ID, as the predicate — archived/terminal, not image age. Age can be a secondary filter, never the primary one.
- A guard that discriminates in both directions, with tests proving it refuses to reap a live session's image, not only that it reaps a dead one's. A guard only ever seen refusing is indistinguishable from one that refuses everything, and the converse is worse here.
- Enforcement, not logging. aios#2325 is the cautionary tale: a budget that only logs is a control that never fires. Ask of the finished thing — has it ever actually reaped?
- A floor-trend check, not a peak check. The peak crossing 82% says nothing; the rising trough is the signal, and it is what caught this.
Not urgent
33GB free. Filing rather than fixing because (a) the host is outside this seat's lane, and (b) the predicate above is the part that deserves care — a hasty reaper here is far more expensive than a full disk.
Observation
On server-b (
aios.eumemic.ai), 2026-09-07 ~08:45Z:55 images named
aios-sbx-default-sess_*— one per session sandbox. 19 are older than 3 days, the oldest around a week. Dangling images: zero, sodocker image prunereclaims nothing; these are all tagged.Why this is being filed now
The
disk-floor-trackwatcher escalated on the right signal: the trough rose across four consecutive cycles (71.7 → 72.5 → 72.9 → 73.4). A rising peak is routine sawtooth and means nothing; a rising floor means a producer is outrunning its consumer. Here the consumer appears to be absent rather than slow — there is no evidence of anything reaping per-session images at all.Compare aios#2325 (
sandbox_snapshot_pool_bytesonly LOGS, never enforces) and aios#2305 (re-flatten). This is the same family: space is allocated per session and released by nothing.What I deliberately did NOT do
I did not delete any image, and the reason is the substance of this issue rather than caution for its own sake.
The obvious predicate — "image older than N days ⇒ reap" — is wrong, and I can show it with a counter-example from this very list:
That is
sess_01KVF7GSGWNGXG0S5YN37EZ8DK— the session that owns the dead-man heartbeat triggers (aios#2402). It is idle, it has been idle for weeks, and it is very much alive: it holds the company's off-substrate darkness detector. Reaping its sandbox because the image looked stale would be precisely the August failure class — a destructive predicate that selects exactly the thing it must not touch, because "no recent activity" is not "no longer needed".An old image is not evidence of a dead session. The age of a sandbox image measures when it was last BUILT, not whether its session is live.
What a correct reaper needs
Not urgent
33GB free. Filing rather than fixing because (a) the host is outside this seat's lane, and (b) the predicate above is the part that deserves care — a hasty reaper here is far more expensive than a full disk.