[systemd-devel] [systemd][cgroup in container] problem with cgroup hierarchy in container

Lennart Poettering lennart at poettering.net
Wed Mar 5 10:16:12 PST 2014


On Wed, 05.03.14 11:38, Dariusz Michaluk (d.michaluk at samsung.com) wrote:

> 
> I can't report the value of the ControlGroup property, I get this:
> # systemctl show
> Segmentation fault

Oh, yuck! THis is weird. Can you get a gdb backtrac and/or valgrind run
for this? Can't reproduce this here...

What's the contents of /proc/1/cgroup in both cases (i.e. the nspawn and
the libvrit-lxc case?)
> 
> Libvirt only ever creates the first two levels as expected.
> When starting a guest it invokes a DBus API call to
> systemd-machined, which talks to systemd to create the cgroups:
> 
> /sys/fs/cgroup/systemd/machine.slice
> /sys/fs/cgroup/systemd/machine.slice/machine-lxc\x2dmycontainer.scope
> 
> The fact that the libvirt_lxc process itself ends up in the right
> place suggest that this isn't libvirt, but rather systemd
> is creating these extra levels.
> It seems to me that systemd create second level
> (machine.slice/machine-lxc\x2dmycontainer.scope) during
> /usr/lib/systemd/systemd execution, and the third level during
> /usr/lib/systemd/systemd --user execution.

nspawn and libvirt-lxc mostly follow the same code paths and register
via machined... So it's weird that different things happen. Somehow the
systemd instance inside the container must be confused about the cgroup
it is running in...

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list