limits.conf not applied

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

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

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

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

DefaultLimitNOFILE=40000

changes the ulimit for the graphical user sessions

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?

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:~$

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.

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.

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.

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

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.

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