highIntermediateUSE#ulimit#fork#pid#max-procs#limits

Fork: Cannot allocate memory — max user processes exceeded

fork: Cannot allocate memory even though free RAM is available

Likely source:availabilityscaling

Focused incident mode — strips away everything but this runbook.

Symptoms

  • fork: Cannot allocate memory even though free RAM is available
  • Application cannot spawn new processes
  • ps shows the user has reached the nproc limit

The nproc limit is per-user, not per-process. A single user running multiple services will share the same limit, causing one service to starve another.

Evidence to grab

Collect these artifacts before you change anything — they prove (or rule out) each cause.

  • User process count vs limit

    ps -u <user> | wc -l && ulimit -u

  • PID max

    cat /proc/sys/kernel/pid_max

Diagnostic flow

Run the steps in order, marking each claim confirmed or refuted. The evidence you gather feeds the ranked causes below.

Guided decision tree is ready.

Steps with commands, expected output, and pass/fail branches.

Ranked root causes

Evidence checklist

  • ps count equals ulimit -u
  • limits.conf has a low nproc value for the user

Confirm before fixing

ulimit -u
READ

Check the current nproc limit

Fix

ulimit -u 65535
CHANGE

Raise the nproc limit (set in /etc/security/limits.conf or systemd unit)

Resolution runbook

Apply from top to bottom after the cause is confirmed. Review every command before running it — risk tags are shown on each.

1
ps -u <user> | wc -l && ulimit -u
READ

Compare process count to nproc limit

2
cat /proc/sys/kernel/pid_max
READ

Check system-wide PID limit

3
ulimit -u 65535
CHANGE

Raise the nproc limit for the current session

4
echo '<user> soft nproc 65535' >> /etc/security/limits.d/<user>.conf && echo '<user> hard nproc 65535' >> /etc/security/limits.d/<user>.conf
CHANGE

Set persistent nproc limits for the user

Prevention

  • Set explicit LimitNPROC= in every systemd unit file.
  • Use separate users for different services to isolate process limits.
  • Alert on per-user process count exceeding 80% of nproc limit.
  • Raise kernel.pid_max on systems expected to run >32768 processes.

Related runbooks

Same stack, same failure family — worth a skim.

Fork bomb — runaway process count exhausting PIDscritical

Cannot fork or Cannot allocate memory when trying to start new processes

LinuxIntermediateUSE2 causes
Open runbook
Too many open files — EMFILE error on processhigh

EMFILE: Too many open files error in application logs

LinuxIntermediateUSE3 causes
Open runbook
Cannot allocate memory — malloc fails despite free RAMhigh

Application fails with Cannot allocate memory

LinuxAdvancedUSE3 causes
Open runbook

Commands marked READ CHANGE DESTRUCTIVE — never run DESTRUCTIVE commands against production data you cannot restore. Copy → verify → execute.