Bugzilla – Bug 1012494
pam: nproc limit too low
Last modified: 2017-11-15 15:35:00 UTC
After upgrading from 42.1 to 42.2 I've noticed randomly crashing processes. It turned out that the reason is pam-limit-nproc.patch in the pam package which limits nproc to 1200 in /etc/security/limits.conf by default. The ChangeLog says: "limit number of processes to harden against fork-bombs". But this limit is ridiculous low. It feel like a limit of 20 years old systems. My actual use case is a user who wants to run a common java program about 40 times in parallel. After 20 times he runs into the limit. I'm not a friend of such programs which runs dozens of threads, most of them are doing almost nothing, but that's how it is nowadays. So please remove that limit again or set it at least 20 times higher. I have never had any problems with kernel default nproc = threads-max / 2 which depends on the available memory at boot time.
Shortly after the package was built, the limits were raised to * hard nproc 4000 * soft nproc 3500 root hard nproc 3000 root soft nproc 1850 Could your customer live with these values? Would it be OK to wait for the next release? After all, these limits are there for protection and if the site has some special requirements, the config files can always be adapted to these needs.
(In reply to Josef Möllers from comment #1) > Shortly after the package was built, the limits were raised to > * hard nproc 4000 > * soft nproc 3500 > root hard nproc 3000 > root soft nproc 1850 > > Could your customer live with these values? For me it's too low. My average interactive users have about 500 processes/treads running all the time. I don't see why they should not have more than 7 times of that. Where do these numbers come from? Statistics, tests or just random numbers? I don't think it makes sense to limit all users by the same hardcoded limit regardless how big is the machine. Probably system users and interactive users should have different limits. Moreover why do we limit root, shouldn't root be able to do everything? I guess if root hits the limit then he will not be able to login again ... and hard reboot is required!?. Note SUID programs may be counted for root thus normal users could DOS attack the root user. > Would it be OK to wait for the next release? You mean the next Leap release? I think this change from 42.1 to 42.2 was too invasive and should be reverted as soon as possible. > After all, these limits are there for protection and if the site has some > special requirements, the config files can always be adapted to these needs. Running just a few thousand processes is not a special requirement. Non-advanced users will have really fun when running into this limit ... Advanced users could add their own limits if needed. BTW it's inconsistent to limit processes randomly by default but not memory nor disk space. At least you should make the hard limits much greater so that the user can adapt it without asking root. Maybe something like this could be reasonable: * soft nproc 4096 * hard nproc 16384 # no limit for root BTW probably /etc/systemd/system.conf should be edited too.
*** Bug 1013706 has been marked as a duplicate of this bug. ***
The limits are now set as per comment #2 (sr 444873)
Note that "*" also limits root.
Agreed. But I'll leave it at that as the new limits are above the old ones anyhow. If there is anyone who needs root to really have no limits, they can still add "root {hard,soft} nproc unlimited" (pseudo-code).
(In reply to Josef Möllers from comment #6) > Agreed. But I'll leave it at that as the new limits are above the old ones > anyhow. If there is anyone who needs root to really have no limits, they can > still add "root {hard,soft} nproc unlimited" (pseudo-code). FYI I've checked again. Looks like nproc limit (RLIMIT_NPROC) does not have any effect for user root at all. Maybe the kernel doesn't check that limit for root because this wouldn't make sense. BTW programs using setuid() are handled specially, see https://lwn.net/Articles/451985/
*** Bug 1041099 has been marked as a duplicate of this bug. ***
Please consider submitting a maintenance update for Leap 42.2 and 42.3 with the default increase to prevent uses from hitting the limit with Chromium in default installations.
openSUSE:Leap:42.2:Update: https://build.opensuse.org/request/show/535380 openSUSE:Leap:42.3:Update: https://build.opensuse.org/request/show/535381
openSUSE-RU-2017:2882-1: An update that has three recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1012494,1013706,1041099 CVE References: Sources used: openSUSE Leap 42.3 (src): pam-1.3.0-6.1 openSUSE Leap 42.2 (src): pam-1.3.0-2.5.1
Thanks for fixing this for Leap! But there is still the cosmetical issue for user root: 1. Why is the limit lower than for a normal user? Why is root limited at all? ... Root can do anything! 2. The nproc limit for root does not seem to have any effect at all. These lines look superfluous and confusing.
(In reply to Ruediger Meier from comment #12) > Thanks for fixing this for Leap! > > But there is still the cosmetical issue for user root: > > 1. Why is the limit lower than for a normal user? Why is root limited at > all? ... Root can do anything! > 2. The nproc limit for root does not seem to have any effect at all. These > lines look superfluous and confusing. I can't recall why they were re-introduced, I assume by copy-paste-ing. IMHO limiting nproc for root does have some merits: as you point out, root can do anything, so root can *really* crash the system by exceeding all limits, even some that are implicitly enforced in the kernel code. The limits were raised for non-privileged users as some applications, mainly GUI-based and also JAVA applications, tend to spawn an insanely high number of threads. Root usually does not run these applications. But I agree: they are superfluous and I'll remove them.
Reopenedto fix issued re comment #12
I have replaced root's limits by an entry specifying unlimited procs/threads for root as "*" includes root. https://build.opensuse.org/request/show/539224
This is an autogenerated message for OBS integration: This bug (1012494) was mentioned in https://build.opensuse.org/request/show/539350 42.2+42.3 / pam
Processed removal of root limits as an optional update.
(In reply to Ruediger Meier from comment #12) > But there is still the cosmetical issue for user root: > > 1. Why is the limit lower than for a normal user? Why is root limited at > all? ... Root can do anything! > 2. The nproc limit for root does not seem to have any effect at all. These > lines look superfluous and confusing. The limits for root were meant to be higher than the wildcard ones because those were system-wide limits, and if a user created too many processes, root could not get a shell to kill them anymore either. But it should be fine with the latest fix.
openSUSE-OU-2017:3021-1: An update that has one optional fix can now be installed. Category: optional (low) Bug References: 1012494 CVE References: Sources used: openSUSE Leap 42.3 (src): pam-1.3.0-10.1 openSUSE Leap 42.2 (src): pam-1.3.0-2.9.1