I am trying to raise the open file descriptor maximum for all users on an ubuntu machine.

This question is somewhat of a follow up to this question.

open file descriptor limits.conf setting isn't read by ulimit even when pam_limits.so is required

except that i've added the required "root" entries in limits.conf

Here are the entries

*               soft    nofile           100000
*               hard    nofile           100000
root            soft    nofile           100000
root            hard    nofile           100000

Lines related to pam_limits.so have been un-commented in all relevant files in /etc/pam.d/ and fs.file-max has been set correctly in /etc/sysctl.conf

However, I still see

abc@machine-2:/etc/pam.d$ ulimit -n

after reboot.

What could be the problem?

My default shell is /bin/sh and i can't use chsh to change my default shell since the my user on the machine is authenticated via some distributed authentication scheme.

  • strace -o loglimit su - abc and after that egrep "(limit|open)" loglimit, maybe your pam configuration are wrong
    – c4f4t0r
    Jan 23, 2014 at 11:02
  • @c4f4t0r, the - option to su only causes a new login when it's the last argument. I only know this because I was just reading that man page. Also, as a detail, a regular user cannot strace an suid root binary.
    – etherfish
    Jan 23, 2014 at 11:08
  • as root you need to use the command strace -o loglimit su - abc
    – c4f4t0r
    Jan 23, 2014 at 11:14
  • sorry for spam but i have this kind of issue unix.stackexchange.com/questions/200310/…
    – vladeli
    May 5, 2015 at 13:01

5 Answers 5


I had a similar problem, but with SSH logins only. Local logins (via console) respected the /etc/security/limits.conf.

As it turned out, when you set:

UsePrivilegeSeparation yes

in /etc/ssh/sshd_config file, then sshd forks an unprivileged child to set up the account's env. Because this child is unprivileged, then pam_limits.so setting upper limits had no effect.

As soon as I set

UsePrivilegeSeparation no

in /etc/ssh/sshd_config and bounced the SSH service, then the limits.conf file were respected with SSH logins.

  • 4
    In my case I changed sshd-config to UsePAM yes. (+1 for pointing me to sshd-config) Oct 2, 2017 at 17:57

On Redhat server logged as root


user01  -       nofile  2048

strace command logged as root

strace -o loglimit su - user01

with other shell open loglimit

grep "limit" loglimit
open("/lib64/security/pam_limits.so", O_RDONLY) = 6
 open("/etc/security/limits.conf", O_RDONLY) = 3
 read(3, "# /etc/security/limits.conf\n#\n#E"..., 4096) = 1823
 open("/etc/security/limits.d", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 3
 setrlimit(RLIMIT_NOFILE, {rlim_cur=2*1024, rlim_max=2*1024}) = 0

In this way I know that, pam_limits was loaded and limits.conf was readed, if your pam_limits was loaded but you still see other values using ulimit -n, check your shell profile as @etherfish told

  • 2
    I got the error: prlimit64(0, RLIMIT_NOFILE, {rlim_cur=10000000, rlim_max=10000000}, NULL) = -1 EPERM (Operation not permitted). This was because I had set the limit too high. Fixed by reducing the limit. Aug 24, 2020 at 23:01

I suspect the ulimit is being applied by a /etc/profile or a ~/.bashrc. The fact that your system has a complicated pam, I would confirm that something isn't going awry.

I'd also confirm that there isn't an errant file in /etc/security/limits.d/ being parsed as mentioned in pam_limits(8).

I'd add debug parameter to the session required pam_limits.conf line and then watch /var/log/auth.log as you log in.

If your soft limit is 1024, whats your hard limit?

su should get you a fresh, new log in with su using the -l argument.

su -l -s /bin/bash

Good Luck.

  • my hard limit is 4096 i.e ulimit -Hn Jan 23, 2014 at 11:23

I was with a issue like this, here what I did.

The strace command will print all interactions the process are doing with external libraries, so with it we can see if our config is loaded or not.

So, i do, like suggested above:

root:/etc/pam.d$ strace -o ~/loglimit su - glaudiston
glaudiston:~$ exit
root:/etc/pam.d$ cat ~/loglimit | grep limits.conf

In my issue, the strace log (strace -o log su - username) does not have any instance of limits text, so the file limits.conf was NOT loaded.

First I make sure the pam_limits.so looks for /etc/security/limits.conf

root:/etc/pam.d$ strings /lib/security/pam_limits.so | grep limits.conf

So, I make sure that the module pam_limits.so is loaded in auth operation in files located at /etc/pam.d ... for example, in /etc/pam.d/su, I added:

session   required    pam_limits.so

Now, I can make a "su" to my user and the limits will be loaded. You can redo the strace step to make it sure.

My linux is a LFS, so is my fault the absense of pam_limits.so in /etc/pam.d files. In other distros I don't think to be this exact issue.

But hope this helps.


In my case (Centos 6.10) strace showed that after limit was set from /etc/security/limits.conf later on in the login process it was reset from /etc/security/limits.d/90-nproc.conf for all non-root users:

*          soft    nproc     1024
root       soft    nproc     unlimited

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.