Updated: 28 September 2026 · Applies to: systemd 252 to 259 and PAM limits on AlmaLinux and Rocky Linux 9 and 10, RHEL 9 and 10, Ubuntu 24.04 and 26.04, Debian 13
The nproc limit caps how many processes (and threads) one user may run. It protects a server from a runaway program or a fork bomb. When it is too low, busy applications such as Java servers, databases or build jobs fail with "Resource temporarily unavailable" or "fork: retry". On current systems three things set the effective limit, so check all of them. The old CentOS 6 and 7 file /etc/security/limits.d/20-nproc.conf (4096 processes per user) is no longer installed on AlmaLinux 9 or 10.
1. See the current limits
ulimit -u # nproc of your shell (soft) ulimit -Hu # hard limit cat /proc/$(pgrep -o java)/limits | grep -i processes # a running program cat /proc/sys/kernel/pid_max /proc/sys/kernel/threads-max
Without a configured limit, the default is half of kernel.threads-max, which depends on the RAM. On an AlmaLinux 9 server we checked, that is 254495, and kernel.pid_max is 4194304 on all current distributions.
2. Limits for login sessions (limits.conf)
For users who log in with SSH or on the console, set the limit in a file under /etc/security/limits.d/, for example /etc/security/limits.d/90-nproc.conf:
appuser soft nproc 16384 appuser hard nproc 32768 @devs soft nproc 8192
The user must log out and in again. * sets a default for all users; root is only affected when named explicitly.
3. Limits for services (systemd)
Services started by systemd do not read limits.conf. Set the limits in a drop-in with systemctl edit myapp:
[Service] LimitNPROC=32768 TasksMax=32768
Then run systemctl restart myapp. LimitNPROC is the classic per-user process limit; TasksMax is systemd's own cap on processes and threads in the service's control group. By default a service may use 80% of the kernel's task limit on AlmaLinux, Rocky Linux and RHEL, and 15% on Ubuntu and Debian (the DefaultTasksMax setting). Check a service with systemctl show myapp -p TasksMax -p TasksCurrent.
4. The per-user cap for login sessions (systemd)
All processes of one logged-in user share a control group (user-UID.slice) limited to 33% of the kernel's task limit. That is rarely reached, but if you hit it, raise it for one user with systemctl set-property user-1000.slice TasksMax=50000.
Common problems
- "fork: retry: Resource temporarily unavailable": compare the running process count (
ps -L -u appuser | wc -l, which counts threads) with the limits above. - limits.conf change has no effect on a service: use
LimitNPROCin the unit, as in step 3. - Java or Elasticsearch asks for a higher limit: follow the value in its own documentation and set it in the service unit.
Official documentation: systemd.resource-control (TasksMax) and limits.conf manual page.