--oom-score-adj only decides WHO the kernel reaches for once the host is
already out of memory. It does not stop a container getting there, and on
2026-10-28 nothing did: an engine grew to 46.3 GB of a 54.8 GB host, pushed
20.4 GB into swap, and the OOM killer never fired at all (oomkill 0) -- the box
thrashed through 108 million page-ins until it was reset by hand. A livelock is
worse than a kill: a killed engine restarts, a thrashing host serves nobody and
cannot even be logged into.

--memory alone still permits swapping, which IS the thrash, so --memory-swap is
set to the same value: exceeding the limit becomes a kill rather than a slow
death. The default is the host's RAM less a reserve for everything that is not
coderai, with an 8 GB floor, because a limit under what one model needs would
fail every load -- a worse failure than the one this prevents. It sits ABOVE
coderai's own softer ceiling (offload.max_ram_gb, which drops caches and evicts
idle models at 90% of it), so the app tidies up first and this is only reached
when something is genuinely wrong. On the host that prompted it: evict at
38.7 GB, app ceiling 43 GB, container killed at 48 GB, 6 GB left for the OS.

The limit is applied only when the kernel can actually enforce it. A limit it
cannot is worse than none: it is discarded with a warning on every start while
an operator reading "memory limit: 48g" reasonably believes they are protected.
That host has no memory cgroup controller at all (cgroup v1, no `memory` in
/sys/fs/cgroup), which is also why its OOM killer stayed silent -- with no
accounting there is no limit to reach -- so it now says so, and says what to
boot with instead.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T3rZozi1Ehk96NG1WesgC