"Cannot Allocate Memory" at fork — With Free RAM: pids.max and overcommit

fork() fails EAGAIN when the process hits a limit that isn't RAM: the pids cgroup ceiling (common in containers) or overcommit accounting. The free-memory intuition is the wrong diagnostic here.

What you'll see

bash: fork: Cannot allocate memory / -bash: fork: retry: Resource temporarily unavailable
free -h shows plenty of available memory
Common in containers (cron, CI, databases spawning children) and long-running processes that never reap

Root causes

cgroup pids limit reached (containers/Kubernetes)

The PID count, not memory, is exhausted: docker --pids-limit, k8s podPidsLimit, or systemd TasksMax=... A process leak (zombie children never reaped) fills the budget. cat /sys/fs/cgroup/pids/pids.current vs pids.max shows it directly.

vm.max_map_count / overcommit accounting

Big-memory processes forking (Redis saves, JVMs, Postgres) trip commit accounting when vm.overcommit_memory=2. The kernel refuses the fork to stay within the committed total — even with free RAM.

Fix it

Check the pids cgroup first (most common case)

cat /sys/fs/cgroup/pids/pids.current /sys/fs/cgroup/pids/pids.max 2>/dev/null ; ps -eLf | wc -l

Find the process leaking tasks

ps -eLf | awk '{print $1,$2,$3}' | sort | uniq -c | sort -rn | head ; # zombie check: ps aux | awk '$8 ~ /Z/'

Raise the limit or fix the reaper

# docker: --pids-limit=512 ; k8s: pod spec shareProcessNamespace/podPidsLimit ; systemd: TasksMax=infinity — but fix the leak first

If it's commit accounting: tune overcommit deliberately

sudo sysctl vm.overcommit_memory=1   # classic Redis/JVM companion setting; understand the tradeoff before 2

Field note

A process that spawns children without waiting reaps nothing: threads/tasks accumulate. Docker restart policies then hide it until the cgroup fills. EAGAIN at fork is almost always a policy limit, not a hardware wall — check pids.max before buying RAM.

Common questions

Why 'Cannot allocate memory' when free shows GBs available?

fork() reserves accounting (PIDs, commit charge), not physical pages. Hit a cgroup pids limit or overcommit policy and the kernel returns ENOMEM/EAGAIN while RAM sits idle. Check /sys/fs/cgroup/pids first.

What's a healthy pids limit for containers?

Defaults (docker often unlimited, k8s commonly -1 or a few hundred) depend on the workload. Set an explicit ceiling you understand (e.g. 256 for app containers, higher for process-spawning ones) — the limit is a leak alarm, not just protection.

Ship it right the first time

Our most-documented failures, packaged as ready-to-ship starter kits: Docker, Kubernetes, and Terraform.

Browse the template store →

One-time. Yours to modify. Instant download from the NinjaOps template store.

"Cannot Allocate Memory" at fork — With Free RAM: pids.max and overcommit

What you'll see

Root causes

cgroup pids limit reached (containers/Kubernetes)

vm.max_map_count / overcommit accounting

Fix it

Field note

Common questions

Related fixes

Ship it right the first time

Get new fixes by email

Vultr — our lab-environment pick for this stack