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?
