systemd version the issue has been seen with

v239

Used distribution

Debian sid
Filed as downstream bug report at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903011
I reported the above issue to the Debian Bug Tracking System and Michael Biebl requested me to report it here.

Expected behaviour you didn't see

I can impose CGroup V2 memory limitation by systemd-run --user -t -p "MemoryHigh=1G" /bin/bash

Within the bash, I see

$ cat /sys/fs/cgroup/user.slice/user-1005.slice/user@1005.service/run-u0.service/memory.high 
1073741824

and the memory limitation seems working. It has been convenient for preventing memory-eating applications from eating all the physical memory.

I verified the above behavior in Ubuntu 18.04 LTS running in systemd-nspawn. Its systemd package version is 237-3ubuntu10. Host Linux is also Ubuntu 18.04 LTS.

Unexpected behaviour you saw

When I do the same in Debian Unstable (in a container), memory.high does not appear and the memory limitation does not seem working. Systemd version in Debian sid is 239.

Steps to reproduce the problem

The configuration of Debian Unstable is almost the same as Ubuntu 18.04 running in a container. Specifically,

• dbus-session-user package is chosen to enable systemd-run --user.

• /etc/systemd/system/user@.service.d/delegate.conf has the following

[Service]
Delegate=memory pids cpu io

• Host Linux has the following kernel command line to let systemd use CGroup V2. systemd.unified_cgroup_hierarchy=1

• Linux kernel package version is 4.15.0-24-generic