Description of problem: The value of `ulimit -n` on Fedora 23 is 2048. This appears to have gone down as of Fedora 24 beta to 1024. This is stopping some of the more resource hungry applications I use (such as IBM Notes) from starting or working properly. How reproducible: Start a resource hungry application. Steps to Reproduce: 1. Install F24 beta 2. Install IBM Notes 9 3. Start the application Actual results: Application does not start and reports "too many open files" in the logs. Expected results: Application should start. Additional info: If I raise `ulimit -n` to 2048 (as per Fedora 23) then the application starts and works as expected.
default limit for `ulimit -n` is 1024 only on Fedora 23.
Siteshwar, not sure what your trying to say. On F23, I get this; $ ulimit -n 2048 While on F24 Beta, I get this; $ ulimit -n 1024 This is definitely a change. I do not know if it is intentional or a bug. If intentional, I would like to know why it was changed, and it certainly should be documented in the release notes.
Gnome-Music might break due to this: https://bugzilla.gnome.org/show_bug.cgi?id=770553 what might be the reason of this change? Not sure if 1024 open descriptors is in any way better than 2048, esp. on desktop systems.
Reassigning to pam package. This change should not be caused by bash. Most relevant commit I could find in pam repo is this http://pkgs.fedoraproject.org/cgit/rpms/pam.git/commit/?id=6818550d2ace764274d70bfc9a7c81b2a669e86f which might have caused this issue.
No, this change did not affect nofile limit at all. And your problem is most likely caused by the fact that user limits are now affected by systemd.
2 Graham White: Before this is solved (if it actually gets solved, because I think this might be some try to increase security inside Fedora), you can workaround this problem by following this guide: http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/ Best regards, Dee'Kej
Bumping the version field in this bug report to 26 to prevent automatic close at end-of-life as this remains a problem from F24 onwards.
This does indeed seem to be because of the move to systemd. The default kernel limits of 1024/4096 are applying to the user, when /etc/security/ulimits.conf has: * soft nofile 4096 * hard nofile 4096 So we should have moved those limits to the systemd version as part of that transition, which are in: /etc/systemd/system.conf /etc/systemd/user.conf And set by the line: DefaultLimitNOFILE=2048:4096 To return the behaviour to that of F23 I'd recommend adding that line to both of those config files for a default installation.
Different processes can have different ulimits in the system. There are two main ways to start a shell in recent gnome desktops: 1. gnome-terminal runs as a service under user, so that systemd limits for services apply (/etc/systemd/systemd.conf, /etc/systemd/user.conf, and possibly individual units, but by default there's none have LimitNOFILE configured that would apply here). 2. various applications like xterm run under session-N.scope, where the session is created using PAM, and /etc/security/limits.conf apply. So be careful: if you start a shell under gnome-terminal, you are likely to see a different set of limits than the usual X client. The proper way to check is to look at /proc/PID/limits where PID is the process you are interested in. Also, it's easy to use 'systemctl status PID' and 'systemctl --user status PID' to see which system and user units a process belongs to. I don't have a F23 machine anywhere, but it seems that in F24 and later, just the default kernel limit is used, and is not overridden by anything. Do you know what configuration in F23 bumped it?
A fresh install of F23 in KVM shows the output of ulimit -n to be 1024. That suggests to me that one of the package updates has caused the change during the life of F23 as the new installation I've done has pulled in all the latest updates too.
I don't think there's anything to fix here. Kernel defaults are 1024/4096. We have various mechanism to override this, in particular /etc/security/limits.d/ can be used for user sessions and anything that goes through PAM, and LimitNOFILE= can be used to override this in individual units. As a last resort, it is possible to set DefaultLimitNOFILE=, but that isn't very useful for a general-purpose distribution. The default PAM configuration in Fedora does not override this, and neither does the default systemd configuration. I think this is OK: most applications should not use thousands of file descriptors. Usually hitting the limit is a sign of some resource leakage, like in the gnome-music case. There _are_ some applications which legitimately need so many file descriptors, but they should simply bump the limit on their own. It's a trivial system function call to do that. Bumping the limit for everything, just because there's one special application that needs that is not a good solution. It seems that something overrode the limit in F23 at some point, but nobody knows what, so it seems to have been something of an accident rather than an intentional change. I'll close this bug. If you think that the default resource limits should be higher in Fedora, it'd be something to discuss on fedora-devel@. As a local workaround, doing something like: # /etc/security/limits.d/20-files.conf @users soft nofile 4096