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).
Openfiles limit automatically decreases when passing 2^21, Ubuntu 16.04
ubuntu;ulimit
There appear to be two system-wide limits, documented in Documentation/sysctl/fs.txtfs.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_openfs.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 setBut file-max doesn't seem to prevent setting the per-process limit, I had this set the whole time:# sysctl fs.file-maxfs.file-max = 262144So 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.