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.

Related services

KVM VPS hosting

NVMe SSD and full root access, with Free Basic Managed Support.

Unmanaged dedicated servers

full root access and free IPMI KVM, with Free Basic Managed Support.

Linux server management

hardening, patching, monitoring and automation for Ubuntu, Debian, RHEL and AlmaLinux.

Was this answer helpful?

Still stuck? Open a ticket