[lxc-devel] Unprivileged containers don't start with lxcfs 2.0.0

[Mathias Gibbens]

On Tue, 2016-04-05 at 16:45 +0000, Mathias Gibbens wrote:
> On Tue, 2016-04-05 at 14:59 +0000, Serge Hallyn wrote:
> > Quoting Mathias Gibbens (mathias at calenhad.com):
> > > On Sat, 2016-04-02 at 15:53 +0000, Serge Hallyn wrote:
> > > > Quoting Mathias Gibbens (mathias at calenhad.com):
> > > > >   This evening I upgraded my lxc/lxcfs install, seeing as how lxcfs
> > > > > 2.0.0 was tagged earlier today. However, with the current lxcfs (2.0.0)
> > > > > my unprivileged containers fail to start:
> > > > > 
> > > > > > lxc at narya:~$ lxc-start -F -n aule.calenhad.com
> > 
> > Which lxc version is this.  What pkg source specifically.
> 
>   This is lxc 2.0.0.rc15 compiled directly from the release source at
> https://github.com/lxc/lxc/archive/lxc-2.0.0.rc15.tar.gz. The configure
> command I've been using is
> 
> > ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --with-init-script=systemd --enable-doc --enable-apparmor --enable-seccomp --enable-capabilities --enable-cgmanager --enable-python
> 
>   I have also been compiling lxcfs from source as well. I had been running lxcfs 2.0.0.beta1 before jumping to the 2.0.0 release. I haven't had time to try any of the in-between rc's to further pinpoint where things broke.

  I've spent some time trying to pinpoint where lxcfs broke, at least
for me. 2.0.0.rc7 works fine, but 2.0.0.rc8 does not work. I see from
the commits that rc8 introduced the access(2) call; is that maybe
breaking something unexpectedly?

  Has anyone else run into this problem? I'm not doing anything fancy in
my setup. The only other possibly relevant information would be that I'm
running a 4.4.6 kernel that's been hardened with the grsec patch.
Everything else is plain vanilla Debian 8.

> > > > > > systemd 215 running in system mode. (+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP -APPARMOR)
> > > > > > Detected virtualization 'lxc'.
> > > > > > Detected architecture 'x86-64'.
> > > > > > 
> > > > > > Welcome to Debian GNU/Linux 8 (jessie)!
> > > > > > 
> > > > > > Set hostname to <aule.calenhad.com>.
> > > > > > Failed to configure loopback device: Operation not supported
> > > > > > Failed to install release agent, ignoring: No such file or directory
> > > > > > Failed to create root cgroup hierarchy: Invalid argument
> > > > > > Failed to allocate manager object: Invalid argument
> > > > 
> > > > ...  And does this still happen when you 'fix' the systemd
> > > > service unit as below?
> > > 
> > >   Yes, lxcfs 2.0.0 was running properly before I tried to start a
> > > container and got the output shown above.
> > > 
> > > > 
> > > > >   Previously I had been running lxcfs 2.0.0.beta1, which works fine.
> > > > > 
> > > > >   I am running Debian 8 (jessie) on both the host as well as in the unprivileged containers. Current software versions are lxc 2.0.0.rc15, lxcfs 2.0.0.beta1, cgmanager 0.37.
> > > > > 
> > > > >   Additionally, with the now-included systemd unit file in lxcfs, I receive this error when attempting to start the service:
> > > > > 
> > > > > > [/lib/systemd/system/lxcfs.service:11] Unknown lvalue 'Delegate' in section 'Service'
> > > > > 
> > > > >   Maybe this isn't supported in the version of systemd that ships in the current stable release of Debian; I simply commented it out and then the lxcfs service starts properly.
> > 
> > Ok this was misleading.  systemd is warning about it, but lxcfs starts fine
> > with that keyword.
> 
>   Yes, sorry about that noise. I know the systemd version in the current
> Debian stable is getting a bit old, and so my first thought was to just
> comment out the offending line in the unit file, then restart the
> service and at least I wouldn't get that error any more.
> 
> > 
> > > > Ugh.  So debian/rules in the jessie package should sed -i '/Delegate/d' that
> > > > files I guess.  Would be nice if there were a nicer way to handle that.
> > > 
> > >   I see lxc also has the same issue with its systemd unit files. I've
> > > not enabled them so far, but took a quick peek so see if the same line
> > > was present.
> _______________________________________________
> lxc-devel mailing list
> lxc-devel at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20160407/712ab056/attachment.sig>