limits.conf not applied

[Aurélien Leblond]

Since upgraded to 16.10 Yakkety, modifications in /etc/security/limits.conf are not taken into consideration when logging in the graphical interface.

/etc/security/limits.conf:
@audio - rtprio 99
@audio - memlock unlimited

I tried the same settings in /etc/security/limits.d/audio.conf, to the same results.

After logging in Unity, opening a console, the limits are not set:
blablack@ideaon:~$ ulimit -l -r
max locked memory (kbytes, -l) 64
real-time priority (-r) 0

Reloging to my user via bash DOES apply the limits:
blablack@ideaon:~$ ulimit -l -r
max locked memory (kbytes, -l) 64
real-time priority (-r) 0
blablack@ideaon:~$ su blablack
Password:
blablack@ideaon:~$ ulimit -l -r
max locked memory (kbytes, -l) unlimited
real-time priority (-r) 95

Switching to a console (ctrl+alt+f1) and logging in would apply the limits as well.

The exact same setup used to work fine on Xenial 16.04 before upgrade.

If you need any more information, please let me know.

ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: lightdm 1.19.4-0ubuntu1
ProcVersionSignature: Ubuntu 4.8.0-16.17-generic 4.8.0-rc7
Uname: Linux 4.8.0-16-generic x86_64
ApportVersion: 2.20.3-0ubuntu7
Architecture: amd64
CurrentDesktop: Unity
Date: Mon Sep 26 17:27:10 2016
SourcePackage: lightdm
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Aurélien Leblond (blablack)]

Issue seems to be fixed for me in the latest updates (1st of October).
Could someone confirm it as well?

[Ewan Leith (ewan-f)]

Still seems to be an issue for me, logging into the terminal I have the modified ulimit values, but not in a lightdm session

[Ewan Leith (ewan-f)]

I've found that editting /etc/systemd/user.conf and inserting lines such as

DefaultLimitNOFILE=40000

changes the ulimit for the graphical user sessions

[Adam Dingle (adam-yorba)]

Apparently Fedora has wrestled with this too:

https://bugzilla.redhat.com/show_bug.cgi?id=1364332

The last comment there (https://bugzilla.redhat.com/show_bug.cgi?id=1364332) seems to indicate that this has been fixed in Fedora 26, which has systemd 233.

I'm running Ubuntu 17.04 Zesty with systemd 232 and am still seeing this problem. Perhaps systemd 233 will solve the problem for Ubuntu as well?

[Adam Dingle (adam-yorba)]

On 17.04, even the workaround that Ewan posted in #5 above doesn't work for me. If I add DefaultLimitNOFILE=40000 to /etc/systemd/user.conf and log out and log in again, prlimit still shows this:

adam:~$ prlimit
RESOURCE DESCRIPTION SOFT HARD UNITS
...
NOFILE max number of open files 4096 4096 files
adam:~$

[Adam Dingle (adam-yorba)]

Artful (17.10) has systemd 233. I just ran the Artful daily build in VirtualBox and tried this there. I see the same problem in Artful: neither a change to /etc/security/limits.conf nor /etc/systemd/user.conf affects the limits I see when I run 'prlimit' in a terminal window.

[Adam Dingle (adam-yorba)]

OK - I was finally able to get this working in 17.04 after more experimentation, which revealed the following caveats:

- Ubuntu will respect limits you put in /etc/security/limits.conf (or /etc/security/limits.d/audio.conf), but **only after a reboot**. Logging out and back in are not sufficient to trigger a change. I suspect that rebooting only became necessary after the recent transition to systemd.

- Limits in /etc/systemd/user.conf are applied after logging out and in.

- I've only been able to change NOFILE (the max number of open files) by editing /etc/systemd/system.conf and then rebooting (logging out/in is not enough). Setting this value in user.conf or limits.conf seems to have no effect.

[Christopher Warner (cwarner)]

So i'm just going to add on here instead of opening a new bug report. The problem is that in most cases when you're setting the limits, you're doing so for a process/user that isn't going to login. So the default is to set it in login, cron, sshd, su etc. Unfortunately, for a process that isn't going to login via normal methods. Such as a server process or the like this will be ignored because pam_limits.so will never be activated.

We need to put pam_limits.so in /etc/pam.d/common-session and /etc/pam.d/common-session-noninteractive as required by default, or, update the documentation somewhere that notes that limits.conf will not be activated by pam_limits.so otherwise. Since everything is already commented out by limits.conf per default it should be a straight-forward change.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[cuby (cuby)]

Did absolutely everything...
/etc/sysctl.conf
/proc/sys/fs/file-max
/etc/security/limits.conf
/etc/pam.d/common-session-noninteractive
/etc/pam.d/common-session
/etc/systemd/user.conf

Only setting this worked:

sudo vim /etc/systemd/system.conf
....
DefaultLimitNOFILE=64000

Let me tell you that this is an ugly mess.

[Nick Rosbrook (enr0n)]

Please re-open if this is still an issue in newer releases.