limits.conf not applied

Bug #1627769 reported by Aurélien Leblond on 2016-09-26
This bug affects 16 people
Affects Status Importance Assigned to Milestone
jackd2 (Ubuntu)
lightdm (Ubuntu)
systemd (Ubuntu)

Bug Description

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

@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
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)

Aurélien Leblond (blablack) wrote :
Launchpad Janitor (janitor) wrote :

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

Changed in lightdm (Ubuntu):
status: New → Confirmed
Aurélien Leblond (blablack) wrote :

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

Ewan Leith (ewan-f) wrote :

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) wrote :

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


changes the ulimit for the graphical user sessions

Adam Dingle (adam-yorba) wrote :

Apparently Fedora has wrestled with this too:

The last comment there ( 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) wrote :

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
NOFILE max number of open files 4096 4096 files

Adam Dingle (adam-yorba) wrote :

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) wrote :

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) wrote :

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 will never be activated.

We need to put 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 otherwise. Since everything is already commented out by limits.conf per default it should be a straight-forward change.

Launchpad Janitor (janitor) wrote :

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

Changed in jackd2 (Ubuntu):
status: New → Confirmed
Changed in systemd (Ubuntu):
status: New → Confirmed
cuby (cuby) wrote :

Did absolutely everything...

Only setting this worked:

sudo vim /etc/systemd/system.conf

Let me tell you that this is an ugly mess.

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

Duplicates of this bug

Other bug subscribers

Remote bug watches

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