This means Linux couldn't start a new process — usually you're out of memory, or you've hit a process/thread limit (sometimes a fork bomb or a leaking app). Here is how to recover.
Quick answer
"fork: Cannot allocate memory" means Linux could not start a new process — either RAM and swap are exhausted, or you hit a process or thread limit. Check with free -m, stop the runaway process (or a fork bomb), add swap if memory is tight, and raise ulimit -u or the container's pids limit if that is the cap.
Check memory first
If RAM and swap are exhausted, fork() fails. Check usage:
free -h
# if 'available' is near zero, you're out of memoryFree memory by stopping a runaway process, or add swap — see the OOM killer guide.
Check process / thread limits
You can run out of process slots even with free RAM — a leaking app or a fork bomb spawning endlessly. Count processes and find the culprit:
ps -eLf | wc -l # total threads
ps -eo user,pid,nlwp,cmd --sort=-nlwp | head # top thread usersRecover when you can't even run commands
If the shell itself can't fork, you may need the VNC/console and to kill the offender. Raising ulimit -u / nproc limits helps legit workloads, but find the leak first.
A process spawning copies of itself exhausts the process table fast. Set sensible nproc limits per user so one runaway can't take the whole box down.
Can't fork = out of memory or out of process slots. Check free -h and the process count, kill the runaway, add swap or raise nproc.
Cause: no swap configured at all
Without any swap, a short memory spike that would otherwise be absorbed (slowly) by swap instead fails immediately with this error. Adding even a modest swap file gives the system a buffer for transient spikes, though it's not a substitute for fixing a real leak.
Cause: overcommit settings or cgroup/container memory limits
Inside a container or a cgroup-limited environment, common on VPS and shared hosting, you can hit "Cannot allocate memory" well before the host machine itself is full, because your slice has its own cap. Check any container/cgroup memory limit, not just the host's free -h.
How to prevent fork failures
- Size RAM to your actual workload with some headroom, not right at the edge.
- Add swap as a safety net even on a VPS with plenty of RAM.
- Set per-user nproc limits so a runaway script can't exhaust the whole process table.
- Monitor memory trends over time so a slow leak is caught before it becomes an outage.
Related errors
If processes are being killed rather than failing to start, that's the OOM killer, a related but different symptom. If the disk itself, not RAM, is the constraint, see no space left on device. To see what's actually consuming resources, use checking CPU/RAM/disk usage.