Setting nproc in /etc/security/limits.conf has no effect in Red Hat Enterprise Linux.

Solution Verified - Updated

Environment

  • Red Hat Enterprise Linux (RHEL) 5, 6, 7

Issue

  • Setting nproc entry in /etc/security/limits.conf has no effect.
  • Raising nproc limit does not prevent fork() failures.
  • What order are the limits files in the /etc/security/limits.d directory read in?
  • What is the order in reading system limit entries?

Resolution

  1. Add the desired entry in /etc/security/limits.d/90-nproc.conf instead of /etc/security/limits.conf.

     # cat /etc/security/limits.d/90-nproc.conf
     *          soft    nproc     1024
     root       soft    nproc     unlimited
     user       -       nproc     2048
    
  2. Verify that the changes have taken effect.

     [root@rhel6 ~]# su - user
     [user@rhel6 ~]$ ulimit -u
     2048
    
    1. If ulimit -u doesn't show the updated limit, try to log out of the console and log back in. Then ulimit -u should show the expected values.

    2. In addition, check that no scripts are running in /etc/profile.d that could influence ulimits.

Root Cause

For limits, the PAM stack is moving to a modular configuration. This includes the introduction of /etc/security/limits.d/90-nproc.conf, which sets the maximum number of processes to 1024 for non-root users. This was done in part to prevent fork-bombs.

After reading /etc/security/limits.conf, individual files from the /etc/security/limits.d/ directory are read. Only files with *.conf extension will be read from this directory.

As per the pam_limits man page:

By default limits are taken from the /etc/security/limits.conf config file. Then individual *.conf files from the /etc/security/limits.d/ directory are read. The files are parsed one after another in the order of "C" locale. The effect of the individual files is the same as if all the files were concatenated together in the order of parsing. If a config file is explicitly specified with a module option then the files in the above directory are not parsed.

Diagnostic Steps

  • Change to the user in question and run ulimit -u to find the current maximum processes that can be run as that user.

      # su - user
      $ ulimit -u
      2048
    
  • Check the limits for an existing process associated with the user:

      # cat /proc/<pid>/limits
    
  • Look for other startup/profile scripts setting limits specifically:

      # find /etc -type f | xargs grep -il ulimit
    

Note: some 3rd software may be started from locations other than /etc.

Components
Category

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.