Sprite is killed 60–190s into sustained heavy IO (pg_restore of an ~900MB dump): root overlay unmounts, all processes SIGKILLed #229

Symptom

Restoring an 884 MB pg_restore custom-format dump into on-sprite Postgres gets the sprite hard-killed 60–190 s in, every time: every process is SIGKILLed, the exec stream dies (local CLI exit 137, or websocket: close 1006 (abnormal closure)), and the guest's dmesg shows the root overlay being unmounted and remounted while VM uptime is preserved:

EXT4-fs warning (device loop1): ext4_convert_unwritten_extents_endio:...
EXT4-fs (loop1): unmounting filesystem <uuid>.
loop1: detected capacity change from 0 to 209715200
EXT4-fs (loop1): mounted filesystem <uuid> r/w with ordered data mode.

No guest OOM (8 GB total, several GB available throughout; cgroup memory.max = max). Reproduced 9/9 attempts across two different sprites, including a freshly created one. Org carl-fyffe-210, sprites ch-01 and www-01, 2026-08-24 00:30–02:15 UTC, if that helps you correlate platform logs.

Repro

1. sprite create test; sprite exec → apt install postgresql + postgresql-18-pgvector, trust local connections.
2. Put a ~900 MB pg_dump custom-format dump on the sprite (the S3 download itself is fine — 884 MB to /tmp in 15 s).
3. createdb x && pg_restore -d x --no-owner --no-acl /tmp/dump → killed 60–190 s in, per above.

The same dump restores cleanly on a laptop in 5:45, so the workload itself is ordinary — roughly 6 minutes of sustained mixed Postgres writes (heap + WAL, checkpoints every ~10 s at ~500 MB WAL distance).

Ruled out

Killed identically under: plain exec, exec --tty, nohup-detached (no exec session at all), a Tasks-API hold, fsync=off + synchronous_commit=off + full_page_writes=off, max_wal_size=8GB (no checkpoint storm), input throttled to 8 MB/s, and a sync && drop_caches sidecar. So it is not idle-pause, not an exec-session limit, and apparently not guest memory or raw write rate.

Controls that pass on the same sprites: 884 MB HTTP download to /tmp (15 s), a single 1.5 GB dd conv=fsync burst to the overlay at 154 MB/s, and 2.5 min of paced 64 MB dd conv=fsync chunks with sleeps. Only the sustained multi-minute restore pattern dies.

Working workaround

Chunking the restore — schema in one pass, then each TOC data item and each post-data item via pg_restore -L with settle sleeps between — completed with zero kills and a byte-equivalent result. It works, but it turns a 6-minute restore into hours, and the failure mode (silent SIGKILL of everything, half-restored database) is rough to discover.

Questions

1. Is there a documented limit on sustained overlay write load that kills the sprite? If deliberate, the lifecycle docs should state it — the current docs only describe idle-based pausing.
2. Two secondary observations from the same investigation, happy to split into separate issues: the Tasks API accepts a command field but never executes it (only the name+expire lease works), and after one of these kills a sprite's /tmp came back with EBADMSG corruption until destroyed.