systemd, per-user cpu and/or memory limits

Question

There is similar question: Cgroups, limit memory per user, but the solution doesn't work in "modern" systems, where cgroups hierarchy is managed by systemd.

Straightforward solution — templating user-UID.slice — won't work, because it is not supported, see https://github.com/systemd/systemd/issues/2556.

Is there any way to achieve the desired effect — manage CPU and/or memory resources on a per-user basis?

UPD: I'll keep my solution for the sake of history, but systemctl set-property should be called at login time, using pam_exec, see https://github.com/hashbang/shell-etc/pull/183. In this approach, there is no time window between the user's login and setting of limits.

My solution. Interface org.freedesktop.login1.Manage of /org/freedesktop/login1 object emits UserNew(u uid, o object_path) signal. I've written a simple daemon which listens to the signal and every time it is emitted set CPUAccounting=true for just-logged-in-user's slice.

Answer 1

Starting with systemd v239, you can use drop-ins https://github.com/systemd/systemd/commit/5396624506e155c4bc10c0ee65b939600860ab67

# mkdir -p /etc/systemd/system/user-.slice.d
# cat > /etc/systemd/system/user-.slice.d/50-memory.conf << EOF
[Slice]
MemoryMax=1G
EOF
# systemctl daemon-reload

Answer 2

UPD: I'll keep my solution for the sake of history, but systemctl set-property should be called at login time, using pam_exec, see https://github.com/hashbang/shell-etc/pull/183. In this approach, there is no time window between the user's login and setting of limits.

Old solution

Here is a very simple script which does the job

#!/bin/bash

STATE=1 # 1 -- waiting for signal; 2 -- reading UID

dbus-monitor --system "interface=org.freedesktop.login1.Manager,member=UserNew" |
while read line
do
    case $STATE in
    1) [[ $line =~ member=UserNew ]] && STATE=2 ;;
    2) read dbus_type ID <<< $line
       systemctl set-property user-$ID.slice CPUAccounting=true
       STATE=1
    ;;
    esac
done

It can be easily extended to support per-user memory limits.

Tested it on a VM with 2 CPUs and 2 users. The first user run dd if=/dev/zero of=/dev/null | dd if=/dev/zero of=/dev/null command and the second one run only one instance of dd. Without this script running, each instance of dd used around 70% of CPU.

Then I started the script, relogged users, and starded dd commands again. This time two dd processes of the first user took only 50% of CPU each and the process of the second user took 100% of CPU. Also, systemd-cgtop showed, that /user.slice/user-UID1.slice and /user.slice/user-UID2.slice take 100% of CPU time each, but the first slice has 6 tasks and the second one only 5 tasks.

When I kill dd task of the second user, the first user starts consuming 200% of CPU time. So, we have fair resource allocation without artificial restrictions like "each user may use only one core".

Answer 3

The issue you mentioned is still open, but this works for me.

sudo systemctl edit --force user-1234.slice

Then type and save this:

[Slice]
CPUQuota=10%

I'm not sure why it works.

Answer 4

Another possibility of achieving CPU or memory limitations through cgroups is to use libpam-cgroup, which can select a profile at login from /etc/cgconfig.conf. A commonly seen example is the following:

group limited {
   cpu {
     cpu.cfs_period_us = "1000000";
     cpu.cfs_quota_us = "500000";
   }
   memory {
      memory.limit_in_bytes = "1G";
      memory.memsw.limit_in_bytes = "1G";
   }
}

This creates an interactive group limiting resources to 1 GB memory and 50% of a CPU core (500 ms per second of total CPU time). Then the /etc/cgrules.conf file can be set to put specific group or users under this group:

root       cpu,memory      /
@nolimits  cpu,memory      /
*          cpu,memory      /limited

In this case, root and everybody belonging to the nolimits group get the default (unlimited) cgroup, while all other users will be limited by the policy set above.

The first matching line is used, therefore it is possible to have a default unlimited policy while limiting a specific user or group like:

spam       cpu,memory      /limited
*          cpu,memory      /

In this case we are limiting the spam user, and no one else.

For this to work, pam_cgroup.so has to be enabled, for example in the /etc/pam.d/sshd PAM profile:

session    optional     pam_cgroup.so

Finally, the cgrules.conf file has to be parsed at boot. This can be achieved with a simple systemd service:

[Unit]
Description=Load cgroup profiles

[Service]
Type=oneshot
ExecStart=/usr/sbin/cgconfigparser -l /etc/cgconfig.conf

[Install]
WantedBy=multi-user.target

This can be saved for example to /etc/systemd/system/loadcg.service and then enabled with systemctl enable loadcg.

Answer 5

On Ubuntu I needed to increase the TasksMax for a single user, the CI service user (UID 2000) that runs all of my group's tests, from the default limit of 10813 to something higher. I checked the old limit with sudo systemctl status user-2000.slice, then set a new limit by typing sudo systemctl edit --force user-2000.slice and entering:

[Slice]
TasksMax=50000

That updates the limit and creates the file /etc/systemd/system/user-2000.slice.d/override.conf which contains the above settings. I added the file to my Ansible playbooks and now it gets deployed to all of our machines so the limit stays set even if we rebuild a server.