还有类似的问题： Cgroups，限制每个用户的内存 ，但该解决scheme在“现代”系统中不起作用，其中cgroups层次由systemdpipe理。
直截了当的解决scheme – 模板user-UID.slice – 将不起作用，因为它不被支持，请参阅https://github.com/systemd/systemd/issues/2556 。
有没有办法达到预期的效果 – 以每个用户为基础pipe理CPU和/或内存资源？
UPD ：为了历史的缘故，我会保留我的解决scheme，但是应该在login时使用pam_exec来调用systemctl set-property ，请参阅https://github.com/hashbang/shell-etc/pull/183 。 在这种方法中，用户login和限制设置之间没有时间窗口。
我的解决scheme 接口org.freedesktop.login1.Manage of /org/freedesktop/login1对象发出UserNew(u uid, o object_path)信号。 我已经写了一个简单的守护进程来监听信号，每次发出时都设置CPUAccounting=true用于刚login的用户片。
UPD ：为了历史的缘故，我会保留我的解决scheme，但是应该在login时使用pam_exec来调用systemctl set-property ，请参阅https://github.com/hashbang/shell-etc/pull/183 。 在这种方法中，用户login和限制设置之间没有时间窗口。
旧解决scheme
这是一个非常简单的脚本来完成这项工作
#!/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
它可以很容易地扩展到支持每个用户的内存限制。
在具有2个CPU和2个用户的VM上进行testing。 第一个用户运行dd if=/dev/zero of=/dev/null | dd if=/dev/zero of=/dev/null dd if=/dev/zero of=/dev/null | dd if=/dev/zero of=/dev/null命令，第二个只运行dd一个实例。 如果没有这个脚本运行， dd每个实例使用大约70％的CPU。
然后，我开始了脚本，重新logging了用户，并重新命名了dd命令。 这次第一个用户的两个dd进程只占用了CPU的50％，第二个用户的进程占用了CPU的100％。 此外， systemd-cgtop显示/user.slice/user-UID1.slice和/user.slice/user-UID2.slice占用CPU时间的100％，但第一个片有6个任务，第二个片只有5个任务。
当我杀死第二个用户的dd任务时，第一个用户开始占用200％的CPU时间。 所以，我们有公平的资源分配，没有像“每个用户只能使用一个核心”这样的人为限制。