CI "cannot fork: Resource temporarily unavailable" - PID/ulimit Limit
A fork() failed with EAGAIN because the runner reached its process/thread count limit - ulimit -u for the user or pids.max for the cgroup. This is the count cap, distinct from running out of memory to fork.
What this error means
A command fails with cannot fork: Resource temporarily unavailable or Resource temporarily unavailable while plenty of memory is free. The cause is the number of processes/threads, not their size - something spawned more than the limit allows.
sh: cannot fork: Resource temporarily unavailable
# or, from a runtime:
java.lang.OutOfMemoryError: unable to create new native threadCommon causes
The per-user process limit (RLIMIT_NPROC) was reached
A build that spawns many threads/processes - or leaks them - hits ulimit -u. The kernel then refuses new forks with EAGAIN even though RAM is available.
The cgroup pids.max ceiling was hit
Inside a container, pids.max caps how many tasks the cgroup may hold. Exceeding it produces the same EAGAIN regardless of host process counts or free memory.
How to fix it
Inspect process counts and limits
Compare current task count against the user and cgroup limits.
ulimit -u # max user processes
cat /sys/fs/cgroup/pids.max # container pid ceiling
ps -eLf | wc -l # threads currently runningLower concurrency or raise the limit
- Cap the offending tool’s parallelism (workers,
-j, thread-pool size). - Raise
ulimit -ufor the step, or the containerpidslimit, if the work genuinely needs it. - Fix any thread/process leak that grows unboundedly.
How to prevent it
- Bound parallel workers and thread pools to the runner’s capacity.
- Set a sane
pidslimit and watch task counts in long jobs. - Reap leaked child processes and threads in long-running steps.