I noticed a weird behavior when trying to set both hard and soft limits of nofile regarding my user (which of course has sudo privileges).

My overall system bound is 2^22, and I tried to do the following even after setting it up to 2^23.

I managed to perfectly set both soft and hard limits up to 2^20, without any problems. (meaning that after I sample them using ulimit -Sn,and -Hn I get the values I just set).

When I set them to 2^21 or higher, after I relog the user (in order to apply the changes), the hard limit and soft limit are both decreased to 4096 and 1024 respectively .

I can't find anything online about it, and I suspect it has something to do with the types of the variables which are used to store these values (personally I'd expect it to be somewhere around 2^32 or even 2^33 if they are defined as uint, but it's definitely not the case).


1 Answer 1


There appear to be two system-wide limits, documented in Documentation/sysctl/fs.txt

  • fs.file-max is the maximum number of open files (filehandles) on the whole system.
  • fs.nr_open is the global upper limit for the per-process number of open files, and it limits the value of RLIMIT_NOFILE, which is what ulimit -n sets. Unsurprisingly, the default is 1024*1024, or 2^20.


# sysctl fs.nr_open
fs.nr_open = 1048576
# ulimit -Hn 1048577
-su: ulimit: open files: cannot modify limit: Operation not permitted
# sysctl fs.nr_open=$[ 2**22 ] 
fs.nr_open = 4194304
# ulimit -Hn 4000000            # now it can be set

But file-max doesn't seem to prevent setting the per-process limit, I had this set the whole time:

# sysctl fs.file-max
fs.file-max = 262144

So whatever is setting your limits (pam_limits.so?), it's probably getting and ignoring the error on the system call because of the limit set by the sysctl. Or perhaps it will log an error somewhere, check your logs.

  • I'll check out the fs.nr_open parameter. I have two question regarding your answer: 1) The behavior on my machine was simply an automatic decrease in both limits, instead of an error emit as you describe here after setting the limit higher than nr_open. 2) So what does file-max actually do if we can simply pass it with any user/proc-wise bound? Does it enforce any policy at all? Mar 15, 2017 at 6:18
  • @GoldenSpecOps, 1) Well, what is the original limit, if you don't try to set it at all? Is it left like that, or is the 1024 limit just an arbitrary one set by something? Hard to say, I don't know what you're using to set the limits. 2) According to the documentation, it's the maximum number of file handles the kernel will allocate. I'd assume it's more like a technical limit than a policy limit. But of course it will be hard to get new file handles if the kernel won't allocate any, regardless of the policy limits.
    – ilkkachu
    Mar 15, 2017 at 8:49
  • @ikkachu , 1) The original limits are defaults, 1024, 4096 for soft and hard links respectively. nr_open is 2**20 as you mentioned. Im setting the limits by editting the limits.conf file. In this question I only intrested in understanding why my system doesn't output a message saying its not allowed, and instead just resets the limits to the default values. 2) I had the same though regarding this question, I guess that the file-max limit is enforced only in runtime , but I can't find a documented verification for that guess. I guess I'll just test it on a VM. Mar 15, 2017 at 9:46
  • @GoldenSpecOps, like I said, check your logs. On my debian, pam_limits.so logs an error if it can't set the resource limit: Mar 15 12:21:11 xxx sshd[4178]: pam_limits(sshd:session): Could not set limit for 'nofile' to soft=1048577, hard=1048577: Operation not permitted; uid=0,euid=0
    – ilkkachu
    Mar 15, 2017 at 10:22
  • ... and of course, if setting the new limit fails, the old one will remain in effect.
    – ilkkachu
    Mar 15, 2017 at 11:55

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.