1b2bd3b22b
Run 8 died 54 s into its boot and this time bash named it: "176880 Killed" on the run-canary line, which is SIGKILL. So the third failure mode is not an internal fault - something outside the process is killing it. And it is still not the OOM killer. Checked immediately after: oom_kill remained 0 and the allocation-stall counter did not move from 4421, so during run 8 the cgroup never reached its limit (5.35 GB of 7 GiB), and the host had 13.8 GB available. Two kills, no OOM evidence either time. Rather than keep guessing after the fact, freeze_watch.sh now samples host MemAvailable, cgroup memory.current and oom_kill on every poll and dumps the last five samples when the process disappears - so the next occurrence carries its own contemporaneous reading. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE