Table of Contents
What the Error Means
-bash: fork: Cannot allocate memoryThis message appears when the shell tries to create a new process — with fork() — and the kernel refuses the request by returning ENOMEM. It is one of the most alarming errors on a Linux server because once it starts, almost nothing works: you cannot run ls, ps, free, or even kill, since each of those requires forking a new process. The frustrating part is that the system is often not truly out of RAM. The word “memory” here is misleading. The failure usually comes from one of three underlying causes: genuine memory exhaustion, the kernel’s memory overcommit accounting refusing new allocations, or a per-user process limit (RLIMIT_NPROC) or systemd TasksMax cap being reached. Diagnosing which one applies is the entire task.
First: Get a Working Shell
Because every external command needs to fork, you may not be able to run any diagnostics at all. Before anything else, you need at least one usable shell. Bash has a number of built-in commands that do not require forking, and these will still work even when the system cannot create new processes. For example, echo, cd, jobs, kill, and ulimit are built into bash itself.
If you have an existing session, avoid closing it — it may be your only way in. If you can still act, the fastest way to relieve pressure without forking is to kill a runaway process using the bash built-in kill:
# 'kill' is a bash builtin — works without forking
kill -9 <pid>The challenge is finding a PID without running ps. You can read /proc directly using shell redirection, which the built-in handles without spawning a process:
# Reading files with the shell does not require a fork
while read -r line; do echo "$line"; done < /proc/loadavgIf you cannot recover the session at all, connect through an out-of-band console (IPMI, iLO, cloud serial console) rather than SSH, since even the login shell needs to fork.
Cause 1: Genuine Memory Exhaustion
The most straightforward cause is that the machine really has run out of usable memory and swap. When memory is fully consumed, the kernel cannot allocate the pages a new process needs, so every fork fails. Once you have a working shell, check the memory situation:
free -h
cat /proc/meminfo | grep -E 'MemFree|MemAvailable|SwapFree'If MemAvailable and SwapFree are both near zero, the system is under real pressure. Look at the kernel log for evidence that the out-of-memory killer has been active, which confirms the diagnosis:
dmesg -T | grep -Ei 'out of memory|oom|killed process' | tailIf the OOM killer has been firing, the answer is capacity or workload: identify the process consuming the memory, terminate it, and then address why it grew — a leak, an oversized cache, or simply too many concurrent workers for the available RAM. Adding swap space provides breathing room and often stops the fork failures immediately:
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfileCause 2: Memory Overcommit Accounting
This is the most commonly overlooked cause, and it produces the error even when free -h shows plenty of available memory. Linux decides whether to grant a fork() based on its overcommit policy. When vm.overcommit_memory is set to 2 (strict accounting), the kernel only permits allocations up to swap + RAM * overcommit_ratio / 100, and it refuses everything beyond that ceiling regardless of how much RAM is actually free. On a server with little or no swap and a conservative ratio, a busy system can hit this limit and reject every new process.
Check the current settings:
See also: Mastering the Linux Command Line — Your Complete Free Training Guide
cat /proc/sys/vm/overcommit_memory
cat /proc/sys/vm/overcommit_ratioIf overcommit_memory is 2 and you are hitting fork failures with free RAM available, the ratio is too low for the workload or the machine lacks swap. Raising the ratio or adding swap resolves it. To adjust temporarily:
sudo sysctl -w vm.overcommit_ratio=80To make it persistent across reboots:
echo 'vm.overcommit_ratio = 80' | sudo tee /etc/sysctl.d/99-overcommit.conf
sudo sysctl --systemOn hosts that were recently hardened by a security baseline, this value may have been changed to a stricter setting. If the error appeared right after a hardening playbook ran, the overcommit configuration is the first thing to compare against a known-good baseline.
Cause 3: Per-User or cgroup Process Limits
If the whole machine has memory to spare but only one user or one service cannot fork, the constraint is a process count limit rather than a memory shortage. Each user has a maximum number of processes (RLIMIT_NPROC), and reaching it produces exactly this error even though memory is fine. Check the limit and how many processes the user is currently running:
ulimit -u # max user processes (bash builtin, no fork)Because you may not be able to run ps, count the processes owned by the user by reading /proc through the shell. If the count is close to the ulimit -u value, the limit is the problem. A common trigger is a fork bomb or a leaking application that spawns processes without reaping them. On systemd-managed servers, the equivalent cap is TasksMax on the user slice or service, which enforces the limit through a cgroup:
systemctl show user-$(id -u).slice | grep TasksMaxTo raise the per-user process limit persistently, edit the limits configuration:
# /etc/security/limits.d/90-nproc.conf
myuser soft nproc 8192
myuser hard nproc 16384For a systemd service that keeps hitting its ceiling, add a drop-in override:
sudo systemctl edit myservice[Service]
TasksMax=infinity
LimitNPROC=infinityThen reload and restart the unit:
sudo systemctl daemon-reload
sudo systemctl restart myserviceCause 4: A Fork Bomb or Runaway Process
Sometimes the limits and memory settings are correct, but a single misbehaving program is spawning processes uncontrollably and consuming every available process slot faster than they can be cleaned up. The symptoms are identical — forks fail everywhere — but the fix is to stop the offending process rather than change any system setting. Look for a process with an unusually high child count or a rapidly climbing process table. Once identified, kill its process group with the bash built-in so you do not need to fork:
kill -9 -<pgid>If the process respawns immediately, it is likely managed by systemd or another supervisor; stop the managing unit first so it does not restart the offender.
A Practical Diagnostic Order
When you hit this error, work from the most recoverable step outward. First, preserve or obtain a working shell and rely on bash built-ins, since external commands may not run. Next, determine whether memory is genuinely exhausted by checking free -h and the kernel log for OOM activity — if the OOM killer has fired, the cause is real memory pressure and the fix is capacity or workload reduction. If memory looks fine, examine the overcommit settings (vm.overcommit_memory and vm.overcommit_ratio), which silently reject forks under strict accounting. Finally, if the machine as a whole is healthy but only a single user or service is affected, inspect the per-user process limit (ulimit -u) and any systemd TasksMax cap, and look for a runaway process or fork bomb consuming the process table. In most production cases the RAM turns out to be adequate, and the real remedy is loosening an overly strict overcommit policy, raising a process limit, or terminating the process that is spawning without restraint.
