[systemd-devel] systemd-nspawn and cgroup hybrid mode

Lennart Poettering lennart at poettering.net
Mon May 13 08:42:15 UTC 2019


On So, 12.05.19 14:09, Antoine Pietri (antoine.pietri1 at gmail.com) wrote:

> Hi,
>
> I have a probably dumb question for which I couldn't find an answer in
> the docs. I'm trying to make a program that uses the cgroupv1 API run
> into a systemd-nspawn container. In the host, I know that I can just
> look at /proc/self/cgroup to see the path of my cgroup and write stuff
> there. The legacy cgroup tree is properly created on the host:
>
> $ systemd-run --pty find /sys/fs/cgroup/ | grep 'run-u[0-9]' | grep
> group/memory/
> /sys/fs/cgroup/memory/system.slice/run-u4161.service/cgroup.procs
> /sys/fs/cgroup/memory/system.slice/run-u4161.service/memory.use_hierarchy
> /sys/fs/cgroup/memory/system.slice/run-u4161.service/memory.kmem.tcp.usage_in_bytes
> /sys/fs/cgroup/memory/system.slice/run-u4161.service/memory.soft_limit_in_bytes
> [...]
>
> But when I'm in the container, it doesn't work anymore. Running the
> same command returns no results. Now, this is most certainly due to
> the fact that in the container, /sys/fs/cgroup is mounted in read-only
> so systemd can't create anything in /sys/fs/cgroup/memory... but then,
> what is the proper way to write into the legacy cgroups? I also tried
> to turn on Delegate=true to see if it would change something, but it
> doesn't.

Delegation of the various controllers to less privileged environments
(i.e. from host to container) is not safe on cgroupsv1, you can use it
to lock up the machine, hence we generally don't do it.

Delegation of the various controllers to less privileged environments
is safe on cgroupsv2, and there we do it. That's why you'll find
controllers such as "memory" delegated to nspawn containers and
systemd --user by default on such systems.

The "hybrid" setup is in most ways like cgroupsv1, i.e. all
controllers are still access the cgroupsv1 way, and hence delegation
is not done there either.

It's a major reason why people really should switch to cgroupsv2 now.

Lennart

--
Lennart Poettering, Berlin


More information about the systemd-devel mailing list