19

We have a CentOS box that I'm trying to increase the max number of files that a user can have open. Currently when I run ulimit -Sn I get 1024 and ulimit -Hn gives 4096. I need that number up around 6000.

In /etc/sysctl.conf I've set fs.file-max = 100000. In /etc/security/limits.conf I have the following set:

username soft nofile 6000
username hard nofile 65535

I've logged out and logged back in as username but am still not seeing my changes. What do I need to get this value changed?

All I have in /etc/security/limits.d is 90-nproc.conf. I've also ensured that ulimit is not being called in my .bash_profile or .bashrc.

When I run sysctl -p it spits out the settings I want and it shows the value for fs.file-max that I want. But when I run ulimit -Sn, I get 1048. If I try to run sysctl --system I get error: Unknown parameter "--system".

nwalke
  • 643
  • 2
  • 12
  • 31

2 Answers2

15

To force /etc/sysctl.conf to be read again run sysctl -p.

File /etc/security/limits.conf is read by login shells and you should close active sessions windows if in GUI. For remote logins, it takes effect on relog.

Xavier Lucas
  • 12,815
  • 2
  • 44
  • 50
  • 1
    Ran that, still not seeing changes after a relog. – nwalke Oct 15 '14 at 19:55
  • @tubaguy50035 `fs.file-max` is the max number of open file on the system. It's a hard limit and it won't be reflected by `ulimit` calls in your case. – Xavier Lucas Oct 15 '14 at 20:00
  • Oh, okay. Should I not be running into too many files open anymore then? – nwalke Oct 15 '14 at 20:08
  • @tubaguy50035 Not related. It's the system hard limit that will override any number above in limits.conf. But limits.conf is still what's applied. Could you try to set the hard & soft limits with ulimit directly in a new session and see if you get same maximums? Something seems to override your configuration. – Xavier Lucas Oct 15 '14 at 20:10
  • It says operation is not permitted. Do I need to give the user access to something? I'd rather the web user not have root privileges. – nwalke Oct 15 '14 at 20:19
  • @tubaguy50035 Try to change the soft limit. You can't change the hard limit if you aren't root. – Xavier Lucas Oct 15 '14 at 20:24
  • Ah okay. I can change the soft limit. The hard limit is still lower than I'm setting at 4096. How can I change that for my user? – nwalke Oct 15 '14 at 20:35
  • @tubaguy50035 What's set with ulimit is only temporary, that was for testing purposes. It will get reset on relog. You likely have something overriding your configuration somewhere, try to find the value somewhere on the filesystem. – Xavier Lucas Oct 15 '14 at 20:43
  • I've run a grep on the entire file system. 4096 is not a unique value! But I don't see anywhere where it deals with this issue. There's a lot in the boot/config stuff, but it seems to all be dealing with allocation of memory limits. – nwalke Oct 15 '14 at 21:18
8

As another poster has said, you need to have sysctl set the value in the running kernel. There are several ways you can set the value without rebooting:

sysctl -p /etc/sysctl.conf
sysctl -w fs.file-max=100000
sysctl --system

IMHO the last method is the best, as it replicates the order that the settings would be applied during boot (and thus if you have a conflict it will become apparent).

Note: I'm not sure which version of CentOS you're using, but on 7 at least I have run into a problem where if dracut rebuilds the initramfs for any reason (such as when installing a new kernel module) it will copy over the contents of /etc/sysctl.* into the initramfs, which will then be executed by systemd-sysctl during that phase, even if you later delete those entries out of /etc/sysctl.conf.

In my environment I've edited the systemd dracut module to exclude /etc/sysctl.* from that environment (as those settings will get set once the rootfs is mounted and systemd-sysctl runs again). It's just a gotcha that you might run into.

Boscoe
  • 564
  • 3
  • 6