memlock is not set

[Matthew]

I discovered this in relation to jack, which installs /etc/security/limits.d/audio.conf, containing:

@audio - rtprio 95
@audio - memlock unlimited

For a user in the audio group:

$ulimit -l -r
max locked memory (kbytes, -l) 65536
real-time priority (-r) 95

So jack (run as user via qjackctl) reports:

ERROR: Cannot lock down 82280346 byte memory area (Cannot allocate memory)

but does not report that it cannot set real-time priority, which it does if run by a user not in the audio group.

I also tried putting the line in /etc/security/limits.conf, and trying a number rather than "unlimited", but it didn't help.

Also reported independently here: https://askubuntu.com/questions/1142943/ulimit-unlimited-cannot-set

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: libpam-modules:amd64 1.3.1-5ubuntu1
ProcVersionSignature: Ubuntu 5.0.0-20.21-lowlatency 5.0.8
Uname: Linux 5.0.0-20-lowlatency x86_64
ApportVersion: 2.20.10-0ubuntu27.1
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Jul 23 15:07:52 2019
InstallationDate: Installed on 2016-10-25 (1000 days ago)
InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
SourcePackage: pam
UpgradeStatus: Upgraded to disco on 2019-07-19 (3 days ago)

[Steve Langasek (vorlon)]

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

tl;dr it’s expected behavior since /etc/security/limits.* is not used by systemd, and further the behavior of pam_limits with group-based limits can’t be reproduced in systemd."

https://bugs.debian.org/919528#10

[Steve Langasek (vorlon)]

systemd user fighting PAM for limits is from my POV certainly a systemd bug.

[Matthew (gromituk)]

Thanks! Is something other than systemd setting the real-time priority? Because if I move audio.conf, rtprio is no longer set:

$ulimit -l -r
max locked memory (kbytes, -l) 65536
real-time priority (-r) 0

[Matthew (gromituk)]

I can REDUCE the memlock limit in /etc/systemd/system.conf, or by creating /etc/systemd/system.conf.d/ and a file in that, but cannot increase it beyond 65536kB. For instance:

[Manager]
DefaultLimitMEMLOCK=100M

does nothing, and neither does specifying "infinity".

[Mauro Panigada (shintakezou)]

The same happens to me, same distro, some infos are different (namely the kernel, 4.18.0-18-generic, since 5.0.0... frozes my machine - another issue to be investigated), but I don't think these differences are relevant. I've set

DefaultLimitMEMLOCK=infinity

in /etc/systemd/system.conf and also /etc/systemd/user.conf (also tried to put a file in newly created /etc/systemd/user.conf.d)

/etc/security/limits.d/audio.conf has

@audio - rtprio 95
@audio - memlock unlimited

As root I can ulimit -l to unlimited. As normal user (in the group audio of course) I can't go with more than 65536.

[Kain (kain-kain)]

Systemd 240 and newer introduced a clamp to RLIMIT_MEMLOCK in c8884aceefc85245b9bdfb626e2daf27521259bd. See https://github.com/systemd/systemd/issues/13331.

[Kain (kain-kain)]

Actually, its just systemd 240. Looks fixed in 241 and newer.

[Jeff Dileo (jtdileo)]

This is currently an issue in 19.10's systemd (version 242). By default, unless services are configured to set LimitMEMLOCK, they will have 64k as their memlock limit (though oddly, systemd bumped its own memlock limit higher than previous versions have used). The only processes not affected are those that increase their own memlock rlimits at runtime, such as `systemd --user`.

```
# for pid in $(ps --ppid 1 | awk 'NR!=1 {print $1}'); do echo -n "${pid}: "; cat "/proc/${pid}/limits" | grep locked ; done
400: Max locked memory 65536 65536 bytes
480: Max locked memory 65536 65536 bytes
514: Max locked memory 65536 65536 bytes
559: Max locked memory 65536 65536 bytes
561: Max locked memory 65536 65536 bytes
596: Max locked memory 65536 65536 bytes
657: Max locked memory 65536 65536 bytes
658: Max locked memory 65536 65536 bytes
659: Max locked memory 65536 65536 bytes
661: Max locked memory 65536 65536 bytes
662: Max locked memory 65536 65536 bytes
665: Max locked memory 65536 65536 bytes
681: Max locked memory 65536 65536 bytes
685: Max locked memory 65536 65536 bytes
688: Max locked memory 65536 65536 bytes
704: Max locked memory 65536 65536 bytes
710: Max locked memory 65536 65536 bytes
711: Max locked memory 65536 65536 bytes
732: Max locked memory 65536 65536 bytes
939: Max locked memory 65536 65536 bytes
6673: Max locked memory 67108864 67108864 bytes
7310: Max locked memory 65536 65536 bytes
# ps aux | grep 6673
root 6673 0.0 0.8 18132 8348 ? Ss 00:07 0:00 /lib/systemd/systemd --user
root 10442 0.0 0.0 8020 864 pts/2 S+ 03:32 0:00 grep --color=auto 6673
```

This includes sshd, but the forked (still `sshd`) children of sshd appear to have their memlock limit increased. This results in direct shell operations under sshd having realistic limits. However, processes "kicked off" by an ssh shell session, but not actually originally parented under them, will have the austere 64k memlock limit. This is the case with docker (the ubuntu docker.io package) containers, as containerd's systemd configuration (/lib/systemd/system/containerd.service) does not set LimitMEMLOCK. And it should not have to.

Per this thread (https://twitter.com/ChaosDatumz/status/1198075570921394177), this is causing problems for eBPF related functionality running under docker due to the fact that the memlock limit is used...

[Launchpad Janitor (janitor)]

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

[tomy (tom2507)]

try this :

modif : /etc/systemd/user.conf
           /etc/systemd/system.conf
with :
        DefaultlimitNOFILE=65535
        DefaultlimitMEMLOCK=5000000

modif : /etc/security/limits.conf

with :

        mkasberg hard nofile 65535
        mkasberg soft nofile 65535
        @sudo hard memlock 5000000
        @sudo soft memlock 5000000

reboot

ulimit -l

you will see :
5000000

[Dan Streetman (ddstreet)]

please reopen if this is still an issue