Linux – Setting the MemoryLimit of a user-created systemd scope using cgroups as user

cgroupdebianlinuxmemory usagesystemd

Related: LImiting overall memory usage for child processes

Is there a way for an unprivileged user, or for root to allow an unprivileged user, to create a systemd scope (or other control group managed by systemd) so that the memory usage of the scope is limited and that the limit is settable by the user?

Or, why does this not achieve the effect described above:

$ systemd-run --scope --user --unit=limit-test.scope bash
Running as unit limit-test.scope.
$ systemctl show --user limit-test.scope |grep Mem
MemoryAccounting=no
MemoryLimit=18446744073709551615
$ systemctl set-property --user limit-test.scope MemoryAccounting=yes
$ systemctl set-property --user limit-test.scope MemoryLimit=100M
$ systemctl show --user limit-test.scope |grep Mem
MemoryAccounting=yes
MemoryLimit=104857600
$ python
>>> a = [1]*1000000000    # happily eats 7.4G of RAM

I'm testing this on Debian unstable with systemd 215. The kernel is 3.18.2 and compiled with the required support, I believe:

$ zgrep -E 'CGROUP|MEMCG' /proc/config.gz 
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_MEMCG_SWAP_ENABLED=y
CONFIG_MEMCG_KMEM=y
# CONFIG_CGROUP_HUGETLB is not set
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_SCHED=y
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_NETFILTER_XT_MATCH_CGROUP=m
CONFIG_NET_CLS_CGROUP=y
CONFIG_CGROUP_NET_PRIO=y
CONFIG_CGROUP_NET_CLASSID=y

/etc/systemd.system.conf sets these parameters, but nothing else:

DefaultCPUAccounting=yes
DefaultBlockIOAccounting=yes
DefaultMemoryAccounting=yes

What I'm really trying to achieve is a way to RSS-limit, as an unprivileged user, a process (or a group of processes) without limiting the virtual memory, i.e. ulimit -v is out.

Best Answer

Ok, so the correct answer is that you cannot setup cgroup limits for user processes (at the time of writing this answer, anyway).

Ref from systemd-devel mailing list:

We simply do not support this right now. Unprivileged users do not get access to the cgroup properties of the various controllers right now, simply because this is unsafe.

We can open this up one day, bit by bit but this requires some kernel work, and an OK from Tejun that this is safe.

This was April, 2015, and I'm assuming nothing has changed since.