libvirt users - Mar 2014 - Re: [libvirt] LXC, user namespaces and systemd

On Mon, Mar 03, 2014 at 03:52:01PM +0100, Dariusz Michaluk
wrote:
> Hi.
> 
> Another week, another experiment ;) I was trying to run systemd user
> session for non-root user, for example darek (uid=1000), operation
> failed with error:
> 
> systemd[26]: pam_unix(systemd-user:session): session opened for user
> darek by (uid=0)
> systemd[1]: Started Login Service.
> systemd[26]: Failed to create root cgroup hierarchy: Permission denied
> systemd[26]: Failed to allocate manager object: Permission denied
> systemd[29]: pam_unix(systemd-user:session): session closed for user darek
> 
> The Cgroup hierarchy for the machine looks as follows:
> 
> ├─machine.slice
> │ └─machine-lxc\x2dmycontainer.scope
> │   ├─17303 /usr/libexec/libvirt_lxc --name mycontainer --console 22
> --security=selinux --handshake 25 --background
> │   └─machine.slice
> │     └─machine-lxc\x2dmycontainer.scope
> │       ├─17306 /usr/lib/systemd/systemd
> │       ├─machine.slice
> │       │ └─machine-lxc\x2dmycontainer.scope

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.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

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.html
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

On Tue, Mar 04, 2014 at 05:16:42PM +0100, Dariusz Michaluk
wrote:
> 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.html
> 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. "
Libvirt honours that actually. When starting a guest it invokes a
DBus API call to systemd-machined, which talks to systemd to create
the cgroups. Libvirt isn't actually creating these in the filesystem
itself.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|