Bug#838191: systemd user units do not honor resource limits set in /etc/security/limits.conf
Antonio Ospite
ao2 at ao2.it
Sun Sep 18 10:16:18 BST 2016
Package: systemd
Version: 231-6
Severity: normal
Dear Maintainer,
I wanted to set resource limits from a systemd _user_ unit, with:
LimitRTPRIO=96
LimitMEMLOCK=infinity
Raising resource limits with ulimit(3) or setrlimit(2) is a privileged
operation, however users are normally allowed to set resource limits
within the boundaries set by hard limits in /etc/security/limits.conf.
Currently this practice does not work with systemd user units.
For example, I have these settings in limits.conf:
-----------------------------------------------------------------------
* hard rtprio 96
* hard memlock unlimited
-----------------------------------------------------------------------
The output of running prlimit from a shell is as follows:
-----------------------------------------------------------------------
RESOURCE DESCRIPTION SOFT HARD UNITS
...
MEMLOCK max locked-in-memory address space 65536 unlimited bytes
...
RTPRIO max real-time priority 0 96
...
-----------------------------------------------------------------------
And users are able to change the soft limit with ulimit from the shell.
However "systemd --user" seems to ignore the hard limits, see the unit
below (copied to /usr/lib/systemd/user/prlimit_defaults.service):
-----------------------------------------------------------------------
[Unit]
Description=Test setting limits
[Service]
ExecStart=/usr/bin/prlimit
-----------------------------------------------------------------------
Starting the unit with "systemctl --user start prlimit_defaults.service"
results in this output:
-----------------------------------------------------------------------
Started Test setting limits.
RESOURCE DESCRIPTION SOFT HARD UNITS
...
MEMLOCK max locked-in-memory address space 65536 65536 bytes
...
RTPRIO max real-time priority 0 0
...
-----------------------------------------------------------------------
The limits are ignored and of course raising them does not work either:
-----------------------------------------------------------------------
[Unit]
Description=Test setting limits
[Service]
ExecStart=/usr/bin/prlimit
# These work fine when running the unit as a system service,
# but they don't have effect when using "systemctl --user"
LimitRTPRIO=96
LimitMEMLOCK=infinity
-----------------------------------------------------------------------
After a precious suggestion by Mantas Mikulėnas (grawity in
#debian-systemd) I verified that this is happening because
/etc/pam.d/systemd-user does not load pam_limits.so.
The following change fixes the issue:
-----------------------------------------------------------------------
--- /etc/pam.d/systemd-user.orig 2016-09-17 17:40:19.787522246 +0200
+++ /etc/pam.d/systemd-user 2016-09-17 15:13:17.035405264 +0200
@@ -7,5 +7,6 @@
session required pam_selinux.so close
session required pam_selinux.so nottys open
session required pam_loginuid.so
+session required pam_limits.so
@include common-session-noninteractive
session optional pam_systemd.so
-----------------------------------------------------------------------
After adding pam_limits and the settings in limits.conf, the units from
above have the expected behavior.
The mechanism explained in systemd-user.conf(5) to set default limits
for all user units also works now; before it didn't.
For instance these values in /etc/systemd/user.conf were completely
ignored without the changes from above:
-----------------------------------------------------------------------
DefaultLimitMEMLOCK=infinity
DefaultLimitRTPRIO=96
-----------------------------------------------------------------------
I guess that too was because user.conf limits are meant to be within
some system-wide limits (see the P.S. below).
I can send a patch for /etc/pam.d/systemd-user against the systemd
Debian package to address the issue, but I have a doubt: can this also
be considered a bug in the upstream src/login/systemd-user.m4?
If so I will send a standalone patch which applies _before_
debian/Adjust-systemd-user-pam-config-file-for-Debian.patch this way it
will be easier to have it merged upstream.
Thanks,
Antonio
P.S.
After I wrote the report above I found out that another way to solve the
problem is to set system-wide limits in /etc/systemd/system.conf (or
/lib/systemd/system.conf.d/nn_SOMETHING.conf), e.g.:
[Manager]
DefaultLimitMEMLOCK=65536:infinity
DefaultLimitRTPRIO=0:96
and these limits will also apply to "systemd --user" (and so
/etc/systemd/user.conf will work too within these limits); maybe this is
even the "official" systemd way to solve the problem, but it does not
give the ability to set per-user or per-group limits, so I still think
that the report above is valid.
-- Package-specific info:
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (900, 'unstable'), (500, 'unstable-debug')
Architecture: amd64 (x86_64)
Kernel: Linux 4.7.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages systemd depends on:
ii adduser 3.115
ii libacl1 2.2.52-3
ii libapparmor1 2.10.95-4
ii libaudit1 1:2.6.6-1
ii libblkid1 2.28.2-1
ii libc6 2.24-3
ii libcap2 1:2.25-1
ii libcap2-bin 1:2.25-1
ii libcryptsetup4 2:1.7.0-2
ii libgcrypt20 1.7.3-1
ii libgpg-error0 1.24-1
ii libidn11 1.33-1
ii libip4tc0 1.6.0-3
ii libkmod2 22-1.1
ii liblzma5 5.1.1alpha+20120614-2.1
ii libmount1 2.28.2-1
ii libpam0g 1.1.8-3.3
ii libseccomp2 2.3.1-2
ii libselinux1 2.5-3
ii libsystemd0 231-6
ii mount 2.28.2-1
ii util-linux 2.28.2-1
Versions of packages systemd recommends:
ii dbus 1.10.10-1
ii libpam-systemd 231-6
Versions of packages systemd suggests:
ii policykit-1 0.105-16
ii systemd-container 231-6
pn systemd-ui <none>
Versions of packages systemd is related to:
ii udev 231-6
-- no debconf information
--
Antonio Ospite
http://ao2.it
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
More information about the Pkg-systemd-maintainers
mailing list