[Lxc-users] systemd inside LXC

[Michael H. Warfield]

On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote:
> Quoting Michael H. Warfield (mhw at wittsend.com):
> > Serge,
> > 
> > On Mon, 2012-10-22 at 09:12 -0500, Serge Hallyn wrote:
> > > Quoting Serge Hallyn (serge.hallyn at canonical.com):
> > > > Quoting Michael H. Warfield (mhw at WittsEnd.com):
> > > > > On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote:
> > > > > > Quoting Michael H. Warfield (mhw at WittsEnd.com):
> > > > > > > Serge,
> > > > > > > 
> > > > > 
> > > > > ...
> > > > > 
> > > > > > > Short of building a custom systemd, I don't know how to fix that problem
> > > > > > > and I suspect this OP is going to run into this same thing (container
> > > > > > > taking over host's console) and might explain some of what he's seeing.
> > > > > > > Several of these look like they could cause problems (like /dev/pts in
> > > > > > > there).  I've really reached an impasse at getting systemd (at least
> > > > > > > Fedora 16 and 17) to work in a container without screwing up the host.
> > > > > > > Prohibiting mounts entirely in the container might work but I suspect
> > > > > > > (having read some systemd error messages) systemd is going to have some
> > > > > > > serious heartburn there.
> > > > > > > 
> > > > > > > Thoughts?
> > > > > > 
> > > > > > IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the
> > > > > > container should work, i.e. systemd was not going to fail as a result.
> > > > > 
> > > > > Hopefully, you've seen the message from Kay Sievers cc'ed to this list
> > > > > from my post to the systemd-devel list.  Looks like they have a
> > > > > mechanism in place to do this...
> > > > > 
> > > > > http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface
> > > > 
> > > > Saw the email, haven't yet read the page, thanks.
> > 
> > > So based on that page, what we do (set 'container=lxc') should already be
> > > sufficient.
> > 
> > Thanks to the dude asking a libvirt-lxc question on the list, I was let
> > to a page that let to a page that led to some discussion you were having
> > back in March with Ramez Hanna on this very subject, "Re: [Lxc-users]
> > f16 update"...
> > 
> > http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg03263.html
> 
> thanks, I knew we'd been over some of this, but couldn't find my logs of
> it.
> 
> > This would look to be the kludge to make a workaround for this problem,
> > I'm just not sure how to make it happen.  Given you already found the
> > answer that the device for /dev has to be different than the device for
> > the parent, what should we do.
> > 
> > I tried this in the config...
> > 
> > lxc.mount.entry=tmpfs /var/lib/lxc/private/Alcove/dev tmpfs defaults 0 0

> How about just a devtmpfs?  We actually now do this by default (as of very
> recently) in ubuntu by adding

> devtmpfs        dev          devtmpfs defaults 0 0

NO!  That's the problem!  That leads to the container connecting to the
hosts console and other devices and committing random acts of terrorism.
That's exactly the case we are trying to avoid and which is causing the
problems to begin with.  That's what systemd is doing if it doesn't
find /dev mounted to begin with.

> to /var/lib/lxc/$container/fstab

> Or, are you on an older kernel which doesn't have devtmpfs?

> > Maybe I got that entry wrong but it didn't do anything (and would have
> > resulted in other failures later as I found out).  A similar mount entry
> > for a shared filesystem worked just fine.
> > 
> > Trying an empty /dev fails because it's missing EVERYTHING so starting
> > out with a tmpfs without populating it is not the answer either.
> > 
> > The correct answer would be to mount a tmpfs file system and then
> > populate it before firing up systemd in the container.  I don't see how
> > to do that.  A bind mount isn't going to work either, for the reasons
> > you stated in that thread, it ends up on the same device.  Having
> > another mount on another real device would be a workaround but a really
> > bad kludge that would complicate things immensely.
> > 
> > > -serge
> > 
> > 
> > -- 
> > Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
> >    /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
> >    NIC whois: MHW9          | An optimist believes we live in the best of all
> >  PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20121022/0a5ad4da/attachment.pgp>