On 03.03.2014 16:26, Daniel P. Berrange wrote:
That looks really bizarre. The same two directory names nested over
and over again. I can't reproduce this kind of thing on my own host.
Libvirt only ever creates the first two levels as expected
/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 something else
is creating these extra levels and moving systemd into them.
On arch linux mailing lists I found similar things:
https://mailman.archlinux.org/pipermail/arch-general/2014-February/035077...
Behavior can be reproduced. After re-taking a look at the topic, it
seems to me that the cause of the problem is the behavior of systemd.
Systemd create first level
(machine.slice/machine-lxc\x2dmycontainer.scope) during
/usr/lib/systemd/systemd execution, and the second level during
/usr/lib/systemd/systemd --user execution.
#cat /proc/1/cgroup
2:name=systemd:/machine.slice/machine-lxc\x2dmycontainer.scope/machine.slice/machine-lxc\x2dmycontainer.scope
#cat /proc/28/cgroup
2:name=systemd:/machine.slice/machine-lxc\x2dmycontainer.scope/machine.slice/machine-lxc\x2dmycontainer.scope/machine.slice/machine-lxc\x2dmycontainer.scope/user.slice/user-0.slice/user@0.service
Maybe the problem is that the libvirt itself creates machine.slice /
machine-lxc \ x2dmycontainer.scope
According to:
http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/
"Container managers should stay away from the "name=systemd" cgroup
hierarchy. That's private property of systemd, and no other code should
interfere with it. "
Regards.
--
Dariusz Michaluk
Samsung R&D Institute Poland
Samsung Electronics
d.michaluk(a)samsung.com