Fix "Cannot allocate memory" and "fork: Cannot allocate memory"

free -h
ps aux --sort=-%mem | head -6

What the error means

"Cannot allocate memory" is the text for ENOMEM. A system call that needs memory, typically fork() (starting a process), mmap() or brk() (allocating memory), was refused by the kernel. Common forms:

-bash: fork: Cannot allocate memory
mmap failed: Cannot allocate memory
OSError: [Errno 12] Cannot allocate memory
java: error: Cannot allocate memory (errno=12)

This is different from the OOM killer. When memory runs out, Linux normally lets allocations succeed and later kills a process ("Out of memory: Killed process"). ENOMEM means the kernel refused up front, which points to either very heavy memory pressure or a limit that triggers before RAM is actually full.

Do not confuse it with fork: retry: Resource temporarily unavailable, which is a process-count limit (see the FAQ).

If the system is barely responding

When fork fails, you cannot start new programs, but shell builtins do not need to fork:

# builtins that still work
jobs -l
kill -9 12345
# replace this shell with one command (no fork needed; the shell is gone afterwards)
exec ps aux --sort=-%mem

If you do not know the PID, switch to a text console (Ctrl+Alt+F3) and log in there, or let the kernel pick a victim with the Magic SysRq key Alt+SysRq+F if your distro enables that function (cat /proc/sys/kernel/sysrq; Ubuntu and Fedora restrict it by default).

Cause 1: RAM and swap really are exhausted

free -h
swapon --show

Example output:

               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       3.7Gi        61Mi       12Mi        98Mi        42Mi
Swap:             0B          0B          0B

Look at the available column, not free; Linux uses idle RAM as cache, and that cache is given back on demand. If available is near zero and there is no swap, you are out of memory. Find the consumer:

ps aux --sort=-%mem | head -10
systemd-cgtop -m

systemd-cgtop groups usage by service and user session, which helps when the problem is many small processes (a browser, build jobs, a container). The process management cheat sheet covers killing and renicing, and finding what uses CPU and RAM lists the usual suspects.

Then give the system headroom:

• Add swap. Small VPS and cloud images often have none. A 2 to 4 GB swap file prevents most of these failures: see how to create a swap file. Fedora and some other distros use zram (compressed swap in RAM) by default; check with swapon --show.
• Limit the application: lower the JVM heap (-Xmx), database buffers, or parallel build jobs (make -j2 instead of -j$(nproc)).
• Add RAM or resize the VM if the workload genuinely needs more.

Cause 2: strict overcommit is enabled

The kernel's overcommit policy decides whether it promises more memory than exists:

cat /proc/sys/vm/overcommit_memory
grep -E 'CommitLimit|Committed_AS' /proc/meminfo

With mode 2 and the default ratio, a machine with 8 GB RAM and no swap can commit only about 4 GB, so large processes, and especially fork() from a big process (which must account for a full copy), fail while free still shows memory. Someone may have set this following a database tuning guide. Go back to the default:

sudo sysctl vm.overcommit_memory=0
grep -r overcommit /etc/sysctl.conf /etc/sysctl.d/ /usr/lib/sysctl.d/ 2>/dev/null

Remove or change the line the grep finds to make it permanent. If you need strict mode deliberately, raise vm.overcommit_ratio or add swap instead.

Cause 3: too many memory mappings (vm.max_map_count)

Each process may have at most vm.max_map_count separate memory mappings. Programs that map many regions (Elasticsearch/OpenSearch, some games under Wine/Proton, large Java or Node apps) hit this and get ENOMEM from mmap() with lots of free RAM.

sysctl vm.max_map_count
# count mappings of a suspect process
wc -l /proc/12345/maps

The traditional default is 65530; several current distros ship a much higher value. Raise it if the process is near the limit:

echo 'vm.max_map_count=1048576' | sudo tee /etc/sysctl.d/90-max-map-count.conf
sudo sysctl --system

Cause 4: per-process limits and 32-bit programs

• Virtual memory limit: ulimit -v prints unlimited normally. A number there (set in /etc/security/limits.conf, a systemd unit's LimitAS=, or a batch scheduler) caps the address space. Raise or remove it.
• systemd memory limits: MemoryMax= on a service or slice usually triggers the OOM killer, but strict limits combined with no swap can surface as allocation failures. Check with systemctl show myapp.service -p MemoryMax -p MemoryHigh.
• 32-bit processes can address only about 3 to 4 GB in total. A 32-bit program that needs more fails with ENOMEM no matter how much RAM the machine has; use a 64-bit build.
• Huge pages: a large vm.nr_hugepages reserves RAM that normal programs cannot use. Check grep -i huge /proc/meminfo.

Distro-specific notes

• Ubuntu, Debian, Mint: desktop installs create a swap file; server and cloud images often do not. systemd-oomd may also kill whole sessions under pressure on Ubuntu.
• Fedora: uses zram swap by default and systemd-oomd. Adjust zram size in /etc/systemd/zram-generator.conf.
• Arch: no swap unless you created it during install. zram-generator is available from the repositories.
• openSUSE: sysctl overrides go in /etc/sysctl.d/; check /usr/lib/sysctl.d/ for distro defaults before changing them.
• Containers: inside Docker or Podman, free shows the host's memory; the real limit is the container's cgroup (cat /sys/fs/cgroup/memory.max).

How to prevent it

• Always configure some swap or zram, even on servers with lots of RAM.
• Set memory limits per service (MemoryHigh=, JVM heap sizes) so one program cannot starve the rest.
• Monitor memory with free, vmstat 5 or your monitoring stack, and alert on low available.
• Do not copy sysctl tuning (overcommit, hugepages) without understanding it. If the error mentions open files rather than memory, see Too many open files.

Frequently asked questions