<div class="gmail_quote">On Sun, Jul 17, 2011 at 2:25 AM, Michael H. Warfield <span dir="ltr"><<a href="mailto:mhw@wittsend.com">mhw@wittsend.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Sat, 2011-07-16 at 23:59 +0300, Ramez Hanna wrote:<br>
> On Sat, Jul 16, 2011 at 8:27 PM, Michael H. Warfield <<a href="mailto:mhw@wittsend.com">mhw@wittsend.com</a>>wrote:<br>
><br>
> > On Fri, 2011-07-15 at 20:17 +0300, Ramez Hanna wrote:<br>
> ><br>
> > << Big Snip >><br>
> ><br>
> > > > > thanks a lot for the detailed answer<br>
> > > > > by the way have you been succesfull in starting a f15 container on<br>
> > your<br>
> > > > f15?<br>
> ><br>
> > I now have an F15 container working.<br>
> ><br>
> > > > > I have been debuggin for 2 hours now<br>
> > > > > when i start f15 container it screws my host by interfering with my<br>
> > > > hosts's<br>
> > > > > systemd which somehow doesn't make sense<br>
> > > > > and when i use systemd-nspawn i get a bunch of errors and the system<br>
> > > > doesn't<br>
> > > > > finish starting<br>
> > > > > here is a paste of systemd log from systemd-nspawn session<br>
> > > > > <a href="http://pastie.org/2218625" target="_blank">http://pastie.org/2218625</a><br>
> > > ><br>
> > > > I haven't tried it yet.  Will see what I can do.<br>
> > > ><br>
> > > > Couple of quick questions.<br>
> > > ><br>
> > > > 1) You say it screws your host if you don't uses nospawn.  What<br>
> > happens?<br>
> ><br>
> > > host console is not useable, random issues around missing characters when<br>
> > i<br>
> > > type<br>
> > > unable to login on other terminals because i cannot type<br>
> > > and i see so many systemd logs on the console<br>
> ><br>
> > I have a very strong suspicion that systemd is not going to be<br>
> > compatible with running in a container because it wants to set up and<br>
> > managed cgroups in the container which it can not do.<br>
> ><br>
> > When I try to start it with systemd, the first process doesn't even seem<br>
> > to come up (number of tasks is 0) and then the host can not remove the<br>
> > container even after I've done an lxc-stop on it.  But that's when I'm<br>
> > logged in and running lxc-start from an ssh terminal Window.  If I start<br>
> > it from a real ttyX console then I get all sorts of startup messages<br>
> > from the container and the consoles are hosed up like the console in the<br>
> > container has gotten crosswise with the console in the host.  Things try<br>
> > to initialize but all sorts of things time out and eventually I have to<br>
> > reset the host with an Magic SysRq sequence.<br>
> ><br>
> > Gave up on systemd.<br>
> ><br>
> > > > 2) Have you disabled the sys_admin cap by dropping it in that<br>
> > container?<br>
> > > > I find that causes me all sorts of grief.<br>
> > > ><br>
> > > i will try that<br>
> ><br>
> > Don't.  It wouldn't do any good and causes lots of other problems (for<br>
> > me at least).<br>
> ><br>
> > > > 3) Was this a fresh template build or did you upgrade an F14 machine to<br>
> > > > F15 (I was going to use "yum --releasever=15 distro-sync" in one of my<br>
> > > > running F14 containers).<br>
> ><br>
> > > yes fresh install<br>
> ><br>
> > Here's what I've done and now gotten an F15 container to work.<br>
> ><br>
> > I started out with an F14 container and upgraded it to F15 using the<br>
> > "yum --releasever=15 distro-sync" method.  I was able to reproduce your<br>
> > problems above and thought there may be some conflicts over cgroups so I<br>
> > decided to disable systemd.<br>
> ><br>
> > If it's not present (it wasn't for me) install upstart into the<br>
> > container from the host using "yum --installroot={your VM root}<br>
> > upstart".<br>
> ><br>
> > Next cd to {your VM root}/sbin and rm init (which is symlinked<br>
> > to ../bin/systemd) and symlink it to upstart (which is in sbin).<br>
> ><br>
> > This got me almost there.  The machine was starting but I was having<br>
> > your funky console problem and I realized (largely because I'm working<br>
> > on other related problems) that it was the ptmx device causing this.  It<br>
> > was mapping incorrectly.<br>
> ><br>
> > So, cd to {your VM root}/dev and rm ptmx if it's a hard device and not a<br>
> > symlink.  Then symlink pts/ptmx to ptmx.  If you started with some sort<br>
> > of template, this may already be done and you may not run into this<br>
> > problem at all.<br>
> ><br>
> > Now you should be able to fire your F15 container up.<br>
> ><br>
> > Also find the lines in /etc/init.d/halt that remount file systems ro or<br>
> > you'll screw your /dev/pts fs in the host when you shut that container<br>
> > down or reboot it (and, no, newinstance is not helping with that<br>
> > problem).<br>
> ><br>
> > Regards,<br>
> > Mike<br>
> > --<br>
> > Michael H. Warfield (AI4NB) | <a href="tel:%28770%29%20985-6132" value="+17709856132">(770) 985-6132</a> |  mhw@WittsEnd.com<br>
> >   /\/\|=mhw=|\/\/          | <a href="tel:%28678%29%20463-0932" value="+16784630932">(678) 463-0932</a> |<br>
> > <a href="http://www.wittsend.com/mhw/" target="_blank">http://www.wittsend.com/mhw/</a><br>
> >   NIC whois: MHW9          | An optimist believes we live in the best of<br>
> > all<br>
> >  PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!<br>
> ><br>
<br>
> it is very clear to me that systemd is interfering with the host's systemd<br>
> your solution of running f15 is not much different than running a f14<br>
> container (as systemd is the major diff)<br>
> systemd-nspawn can start systemd inside a "light weight" container<br>
> i think the problem is related to the fact that when lxc starts teh cgroup<br>
> is on the root of the tree<br>
> while it should have been under the user's tree<br>
</div></div>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
<br>
I'm not so sure I understand what you mean by that last line.  What<br>
"user's tree" are you referring to?<br></blockquote><div>in f15 systemd whenever a user starts a process it looks like this   <br>├ user<br>│ ├ root<br>│ │ └ 86<br>│ │   ├ 24814 -bash<br>│ │   ├ 24848 top<br>
│ │   └ 31324 login -- root<br>│ └ rhanna<br>│   ├ 56<br>│   │ ├  1002 pam: gdm-password<br>│   │ ├  1047 /usr/bin/enlightenment<br>│   │ ├  1058 dbus-launch --sh-syntax --exit-with-session<br>│   │ ├  1059 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --sess...<br>
<br>so i would expect lxc to create it's cgroup under the user (root in this case) instead <br>while it currebtly shows it like this<br>boss is the name of the container<br>├ 24811 [kworker/1:0]<br>├ boss<br>│ ├ 8914 init [3]<br>
│ ├ 9135 /usr/sbin/cron<br>│ ├ 9146 /usr/sbin/sshd<br><br>now I am not trying to use systemd-nspawn to replace lxc or anything, I am just using it to debug if i had problems in my container rootfs<br>and well if nspawn doesn't screw up my host then it is doing something better<br>
<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
> maybe serge can say somethiing about this<br>
<br>
</div>Maybe, maybe not.<br>
<br>
The cgroup mounts are where systemd is putting them, not where lxc is<br>
putting them.  As it is, lxc is not "starting" the cgroup anywhere, it's<br>
just using them where they are found.  And systemd-nspawn has nothing to<br>
do with lxc.<br>
<br>
Seems to me that where you're trying an F15 guest on an F15 host with<br>
cgroups mounted in the host by systemd where systemd wants them and then<br></blockquote><div>well the container's systemd should not "see" the host's cgroup tree but rather a cgroup relative to it's rootfs<br>
but again i don't think this is the main problem<br>i think that the container's systemd is triggering and "runlevel" change at the host as well, which means that something is not isolated correctly, <br>
AFAIK systemd uses /run/systemd/<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
using systemd-nspawn to fire up the container, you've completely cut lxc<br>
out of the loop here?  What does that have to do with lxc at this point? </blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
I just read up on systemd-nspawn (which I had never tried before) and it<br>
sounds like a really primitive lxc competitor comparable to lxc-start<br>
only without the configuration stuff and helper utilities.<br>
<br>
Tried it out myself firing up the same Faces container only under<br>
systemd-nspawn instead of lxc-start and execing /bin/systemd instead<br>
of /sbin/init (upstart) and yeah it face-planted with the same errors<br>
you encountered.  It also wouldn't start the same container<br>
running /sbin/init but I suspect that was more because of missing<br>
mounted file systems like sys and proc that lxc-start is so nicely<br>
handling for us.<br>
<br>
I would say that problems with systemd-nspawn are systemd-nspawn's and<br>
not ours here.  After looking at it and trying it out, I don't think<br>
I'll try it again.  Even the man pages on it mentions "systemd-nspawn -<br>
Spawn a namespace container for debugging, testing and building".<br>
Doesn't sound like a production tool to me.<br>
<div><div></div><div class="h5"><br>
Regards,<br>
Mike<br>
--<br>
Michael H. Warfield (AI4NB) | <a href="tel:%28770%29%20985-6132" value="+17709856132">(770) 985-6132</a> |  mhw@WittsEnd.com<br>
   /\/\|=mhw=|\/\/          | <a href="tel:%28678%29%20463-0932" value="+16784630932">(678) 463-0932</a> |  <a href="http://www.wittsend.com/mhw/" target="_blank">http://www.wittsend.com/mhw/</a><br>
   NIC whois: MHW9          | An optimist believes we live in the best of all<br>
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!<br>
</div></div></blockquote></div><br>