Stop the OOM Killer from lying to your Kubernetes logs

Technical Briefing | 8/9/2026

You see a pod restart, check the events, and see the OOMKilled status. Everything looks standard, so you bump the memory request and hope for the best. But when you check the application logs, there is nothing there. No stack trace, no last-gasp crash log, just a silent death. This bit me back in 2019 when I spent half a day debugging a memory leak that turned out to be the kernel killing processes based on cgroup limits while the application runtime was completely unaware it had even been signaled.

Why the kernel leaves no trail for your app

When the kernel invokes the OOM killer on a cgroup, it sends a SIGKILL immediately. Your application never sees a SIGTERM or a SIGQUIT, so it never has a chance to flush buffers, write a final log entry, or perform any teardown logic. The process is wiped from the runqueue before it can even catch its breath. The logs you see are usually just what happened to be buffered in stdout or stderr before the kernel yanked the rug out from under the process.

cat /sys/fs/cgroup/memory/memory.oom_control

• Check memory.oom_control on your nodes to see if oom_kill_disable is toggled
• Monitor the OOM count inside the cgroup file to confirm the kernel is actually doing the killing
• Use kubectl get pod -o jsonpath='{.status.containerStatuses[*].lastState.terminated.reason}’ to verify if it was OOMKilled or just a regular exit
• Check /var/log/messages or dmesg on the host for the specific process that got hit

Finding the ghost in the machine

Most monitoring tools only show you the result, but checking the cgroup statistics directly gives you the reality. If you really need to capture state before the kill, you have to look into user-space OOM notifiers like earlyoom, but for most Kubernetes clusters, the right approach is to ensure your limits are tight enough to trigger warnings before the hard stop happens. If you aren’t logging the cgroup pressure signals, you’re flying blind until the process is already gone.

Next time a pod vanishes without a trace, stop digging through application code and start looking at the kernel ring buffer. The exit codes lie to you, but the dmesg logs never do.