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

[Dariusz Michaluk]

On 04.03.2014 21:10, Lennart Poettering wrote:

> OK, this looks wrong, the machine slice appears to have been used twice
> in the cgroup path.
>
> Can you try this with 210 in the container, and then run "systemctl
> show" and report the value of the ControlGroup property, please?
>
> If you boot this up with npsawn instead of libvirt-lxc, does t work then?

I can reproduce similar behaviour on Fedora 21. I used Linux 
3.14.0-0.rc5, systemd 210 on host and guest machine, libvirtd 1.2.2.

The CGroup hierarchy for the libvirtd machine looks as follows:

├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 22
├─machine.slice
│ └─machine-lxc\x2dmycontainer.scope
│   ├─4282 /libexec/libvirt_lxc --name mycontainer --console 18 
--security=selinux --handshake 21 --background
│   └─machine.slice
│     └─machine-lxc\x2dmycontainer.scope
│       ├─4283 /usr/lib/systemd/systemd
│       ├─machine.slice
│       │ └─machine-lxc\x2dmycontainer.scope
│       │   └─user.slice
│       │     └─user-0.slice
│       │       └─user at 0.service
│       │         └─4361 /usr/lib/systemd/systemd --user
│       ├─system.slice
│       │ ├─systemd-logind.service
│       │ │ └─4345 /usr/lib/systemd/systemd-logind
│       │ ├─dbus.service
│       │ │ └─4341 /bin/dbus-daemon --system --address=systemd: --nofork 
--nopidfile --systemd-activation
│       │ ├─sshd.service
│       │ │ └─4347 /usr/sbin/sshd -D
│       │ └─systemd-journald.service
│       │   └─4319 /usr/lib/systemd/systemd-journald
│       └─user.slice
│         └─user-0.slice
│           ├─session-15.scope
│           │ ├─4349 login -- root
│           │ └─4374 -bash
│           └─user at 0.service
│             └─4367 (sd-pam)

The same container running with systemd-nspawn use below hierarchy:

├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 22
├─machine.slice
│ └─machine-mycontainer.scope
│   ├─4459 /usr/lib/systemd/systemd
│   ├─system.slice
│   │ ├─systemd-logind.service
│   │ │ └─4517 /usr/lib/systemd/systemd-logind
│   │ ├─dbus.service
│   │ │ └─4509 /bin/dbus-daemon --system --address=systemd: --nofork 
--nopidfile --systemd-activation
│   │ ├─sshd.service
│   │ │ └─4519 /usr/sbin/sshd -D
│   │ └─systemd-journald.service
│   │   └─4483 /usr/lib/systemd/systemd-journald
│   └─user.slice
│     └─user-0.slice
│       ├─session-16.scope
│       │ ├─4522 login -- root
│       │ └─4560 -bash
│       └─user at 0.service
│         ├─4547 /usr/lib/systemd/systemd --user
│         └─4553 (sd-pam)

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

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.

Regards
-- 
Dariusz Michaluk
Samsung R&D Institute Poland
Samsung Electronics
d.michaluk at samsung.com