Stop trusting /proc in your containers: what the kernel actually sees

Container & Kubernetes Internals

Stop trusting /proc in your containers: what the kernel actually sees

Technical Briefing | 10/17/2026

You probably think your container’s /proc filesystem is a faithful representation of your process state. It isn’t. When you run a command like top or ps inside a container, they query /proc, but they are often hallucinating because the kernel hasn’t properly namespaced every single entry. I’ve seen monitoring agents report garbage utilization data because they were pulling stats from the host’s view of the world instead of the container’s isolated cgroup slice.

The ghost in the procfs machine

The issue usually stems from tools that read /proc/meminfo or /proc/uptime. Because these files are global and not fully namespaced, a containerized process sees the host’s total RAM, not the limit you defined in your Kubernetes resource manifest. If your Java heap settings rely on autodetecting available memory, you are going to get an OOMKilled event the second you hit half that limit. You can verify this mismatch yourself by comparing what the container thinks it has versus what the cgroup actually allows.

grep MemTotal /proc/meminfo; cat /sys/fs/cgroup/memory/memory.limit_in_bytes

  • Procfs entries like /proc/uptime and /proc/loadavg remain global across the entire host
  • Legacy applications expecting a view of the host machine will always miscalculate their thread pool sizes
  • The kernel hides invisible boundaries in /proc that standard tools are too lazy to parse correctly

Workarounds that aren’t just hacks

Don’t bake your runtime detection on /proc unless you are prepared to write a custom parser that checks /sys/fs/cgroup. Better yet, if you are stuck with legacy apps that ignore container limits, force their memory ceilings using environment variables rather than letting them guess. If you find your metrics collector is lying to you, stop using the default integration and switch to one that actually understands the cgroupv2 hierarchy.

Next time your container hits an OOM limit despite having plenty of free space reported by top, don’t waste an hour digging through kernel logs. Check if your binary is reading the global /proc values and stop trusting what the tools report at face value.

Linux Admin Automation  |  © www.ngelinux.com  |  10/17/2026

0 0 votes
Article Rating
Subscribe
Notify of
guest

0 Comments
Newest
Oldest Most Voted