From 66a220dcddce12e44a1d959065aefc3eaaaace28 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Mon, 24 Aug 2026 09:19:46 +0000 Subject: [PATCH] docs: a third SIGKILL, traced live, refutes the memory explanation Run 9 died the same way at t=486s, and the watcher's sampler had been running throughout: at the kill the cgroup held 6.5 GB of its 7.0 GB limit, the host had 12 GB free, and oom_kill was 0. So the memory-pressure suspicion recorded earlier is refuted - three kills, no OOM record on any, and the one with a full trace shows headroom on both the cgroup and the host. Also checked and clean: no stray process of mine was running, and the kills do not fall on a clock (08:31, 09:00, 09:14 - gaps of ~29 and ~14 minutes). Recorded as a container-level blocker rather than chased further, because nothing in here can attribute a SIGKILL to its sender: no dmesg, no audit, and ptrace_scope=1 limits strace to my own descendants. The practical response is to stop designing experiments that need a long run - the counter transitions the OB work needs all happen in the first minutes of flight. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE --- docs/re/mission-freeze-resume-spin.md | 32 +++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/docs/re/mission-freeze-resume-spin.md b/docs/re/mission-freeze-resume-spin.md index fcee0d11..c3ed1286 100644 --- a/docs/re/mission-freeze-resume-spin.md +++ b/docs/re/mission-freeze-resume-spin.md @@ -551,3 +551,35 @@ usual single pair (`BE56BB5C`) and nothing else. **Run tally since v2: three runs, no frozen sample** — GAME OVER at ~22 min (run 5), `EMULATOR GONE` at 810 s (run 6), and no freeze in 1 100 s (run 7). + + +### 🔴 A third kill, with a contemporaneous trace — and it REFUTES memory pressure + +Run 9 died the same way at t=486 s, and this time the watcher's own sampler had +been running the whole time: + +``` +EMULATOR GONE at 486s +t=344s host_avail=12159MiB cgroup=6388MiB oom_kill=0 +t=382s host_avail=12061MiB cgroup=6490MiB oom_kill=0 +t=411s host_avail=12001MiB cgroup=6533MiB oom_kill=0 +t=453s host_avail=12066MiB cgroup=6489MiB oom_kill=0 +t=486s host_avail=13163MiB cgroup=5375MiB oom_kill=0 <- after the kill +``` + +At the moment of death the cgroup held **6.5 GB of its 7.0 GB** — not at the +limit — the host had **12 GB free**, and `oom_kill` was **0**. 🔴 So the memory +suspicion recorded above is **refuted**: three kills, no OOM record on any of +them, and the one with a full trace shows headroom on both the cgroup and the +host. + +**What was also checked and found clean:** no stray process of mine was running +(only the pilot), and the kills do not fall on a clock — 08:31, 09:00, 09:14, so +gaps of ~29 and ~14 minutes rather than a period. + +**Stated as a container-level blocker rather than chased further:** something +outside the emulator SIGKILLs it, roughly one run in three, and nothing available +in here attributes a SIGKILL to its sender (no `dmesg`, no audit, and +`ptrace_scope=1` limits `strace` to my own descendants). The practical response +is to stop designing experiments that need a *long* run: the counter transitions +the OB work needs all happen in the first minutes of flight.