Linux Server / Performance, Capacity & Containers
Distinguish a cgroup memory kill from whole-host memory exhaustion
A container or service can be killed at its own memory limit even though free host memory remains. Inspect its actual cgroup path and events.
Environment and inputs: Linux server baseline · Ubuntu 24.04 LTS / RHEL 9-style systems. Use the specified distribution, init system and installed tool; service names, privileges and supported options can differ.
Start with this check
Confirm the host, shell and access role. Replace sample names, paths, domains and interfaces with approved targets. These are diagnostic commands; assess policy and workload impact before making changes.
systemctl show app.service -p ControlGroup
cat /sys/fs/cgroup/system.slice/app.service/memory.eventsRead the result
For a cgroup-v2 service at the illustrative path, memory.events reports counters such as limit and OOM activity. Use the actual ControlGroup path and supported kernel files.
Resolve and verify
Correlate counter deltas with service exits and configured limits. Fix memory growth or plan safe capacity in the correct cgroup and parent hierarchy.
Before changing production
Do not assume every exit code 137 is an OOM kill or raise limits beyond host headroom.