nofile limit cannot be increased, only decreased

Bug #327597 reported by Marc Schiffbauer
2
Affects Status Importance Assigned to Milestone
pam (Debian)
Fix Released
Unknown
pam (Ubuntu)
Invalid
High
Steve Langasek

Bug Description

Setting the maximum number of open files via pam's /etc/security/limits.conf (setting nofile) does only work for values less than 1024, not above

This seems to work on Gentoo, Red Hat and SuSE quite well so I started to look why it does not in ubuntu.

I found out that a patch applied durcing build is causing this:

in
  debian/patches-applied/027_pam_limits_better_init_allow_explicit_root

you find the following on line 59:

+ pl->limits[i].limit.rlim_max = 1024;

which seems to set the maximum for RLIMIT_NOFILE to 1024 which IMO is non-sense.

We have many servers that have it set to 65536 for big applications.
If I increase this rlim_max value, the default is still 1024 but I can rise it to limit.rlim_max -1

Please fix this by setting a reasonable value here. The kernel maximum is 2^20 = 1024*1024 = 1048576
(See "sysctl fs.nr_open" or "cat /proc/sys/fs/nr_open")

So I suggest setting it to 1024*1024 instead of 1024 value to not have a synthetic limit here

See attached patch for the patch which fixes it.

-Marc

Revision history for this message
Marc Schiffbauer (mschiff) wrote :
Revision history for this message
Marc Schiffbauer (mschiff) wrote :
Steve Langasek (vorlon)
Changed in pam:
assignee: nobody → vorlon
importance: Undecided → High
status: New → Confirmed
Revision history for this message
Steve Langasek (vorlon) wrote :

Thank you for taking the time to report this issue and help to improve Ubuntu.

After careful examination, I don't find any bug here. Setting limits via limits.conf works fine for me - and in fact, researching this shows that patch 027 was broken and was having no effect at all.

I think one of two things is happening here:

- you're setting a hard limit in limits.conf (ulimit -H -n) but are checking the soft limit (ulimit -n)
- you're trying to set a soft limit in limits.conf (user soft nofile...) without first raising the hard limit (user hard nofile...), so your soft limit change has no effect.

Lowering a hard limit will automatically lower the soft limit, but raising either limit will not automatically raise the other. I have no idea why any limit handling would work on other distros that doesn't work on Ubuntu unless there are differences in the in-kernel defaults.

Changed in pam:
status: Confirmed → Invalid
Changed in pam:
status: Unknown → Fix Released
Revision history for this message
Sebastien Estienne (sebest) wrote :

Maybe the confusion comes from the fact that '*' wildcard doesn't affect values for the root user.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.