On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote: > Quoting Michael H. Warfield (m...@wittsend.com): > > Serge, > > > > On Mon, 2012-10-22 at 09:12 -0500, Serge Hallyn wrote: > > > Quoting Serge Hallyn (serge.hal...@canonical.com): > > > > Quoting Michael H. Warfield (m...@wittsend.com): > > > > > On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote: > > > > > > Quoting Michael H. Warfield (m...@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 | m...@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 | m...@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!
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
