Container Basics On Linux (Namespaces/Cgroups)

Stop letting your cgroup v2 memory limits kill your database silently

🧩 The Challenge

You’ve set a memory limit on a container, but when the app hits it, the kernel just nukes the process without a word. I’ve wasted an entire afternoon staring at empty logs wondering why my Postgres instance kept vanishing into thin air.

💡 The Fix

You need to check the memory.oom_control file to see exactly how the OOM killer is behaving for that specific cgroup. It stops the mystery crashes by letting you see if the kernel is configured to panic or just kill your workload.

cat /sys/fs/cgroup/system.slice/your-container.service/memory.events
cat /sys/fs/cgroup/system.slice/your-container.service/memory.oom_control

⚙️ Why It Works

Reading these files tells you if the OOM killer triggered or if the process was throttled, which is the only way to know if you’re hitting hard limits instead of just having a memory leak. The kernel keeps these stats in plain text, but nobody remembers they exist until the production site is already down.

🚀 Pro-Tip: If you see ‘oom_kill’ increasing in memory.events, stop tweaking application configs and just give the container more headroom.

Linux Tips & Tricks | © ngelinux.com | 11/10/2026