Openfiles limit automatically decreases when passing 2^21, Ubuntu 16.04

Question

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).

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.

So:

# 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.