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 LimitNPROC in 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.

Ucartz services for this topic

Was this answer helpful? 0 Users Found This Useful (0 Votes)