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.ht... 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@samsung.com