4

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.

Community
  • 1
Sami Liedes
  • 185
  • 1
  • 5

2 Answers2

6

It seems to work if done this way:

$ systemd-run --scope --user --unit limit-test.scope -p MemoryAccounting=yes -p MemoryLimit='10M' bash

and then checking the status:

$ systemctl show --user limit-test.scope | grep Mem
MemoryCurrent=18446744073709551615
MemoryAccounting=yes
MemoryLimit=10485760

The key being to pass in the property with the -p flag. Also, note that for user-mode systemd, the relevant file for configuring defaults is actually /etc/systemd/user.conf, and not /etc/systemd/system.conf.

Nathan Williams
  • 63
  • 1
  • 6
  • While this does create the scope with the specified settings, it does not appear to create any matching cgroup (foo.scope only exists in the useless systemd-named-cgroup, which does not enforce any limits) or enforce the limits. This is on debian testing, with systemd 230. Any suggestions? – Jonas Schäfer Jul 29 '16 at 13:45
  • 1
    Hmm I don't know why this has been marked as the accepted answer, it doesn't work. Although it's true that the status shows the memory limit, the limit is not actually applied (AFAICT). – Chris Salzberg Sep 18 '16 at 08:26
  • 3
    According to [this bug report](https://github.com/systemd/systemd/issues/6895) the above should actually work, but requires systemd v235 or greater and a kernel with cgroup-v2 support. – mleu Jul 04 '18 at 14:37
  • Ubuntu 20.04 LTS has `systemd` version `245` but still fails to prevent too high memory usage: `systemd-run --user --pty -p MemoryMax=42M -p MemorySwapMax=50M -p CPUWeight=10 stress -t 10 --vm-keep --vm-bytes 10m -m 20` takes over 200 MB of RAM even though the limit is much less. According to https://github.com/systemd/systemd/issues/10581 using `cgroupsv2` would be the solution but I don't know any distro that actually accomplishes this. To me, `systemd` is just broken. – Mikko Rantalainen Sep 04 '21 at 14:15
  • It seems that Ubuntu 21.10 will be the first version where this could be fixed: https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-21.10-systemd-cgroup – Mikko Rantalainen Sep 04 '21 at 14:18
4

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.

Chris Salzberg
  • 156
  • 2
  • According to https://github.com/systemd/systemd/issues/10581 distros would need to use `cgroupsv2`. I don't know what it requires in practice. – Mikko Rantalainen Sep 04 '21 at 14:13