<html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 04/04/14 23:17, Leonid Isaev wrote: </div> <blockquote cite="mid:20140404181708.07f77a04@hermes" type="cite"> <pre wrap="">On Fri, 04 Apr 2014 21:19:45 +0100 John Lane <a class="moz-txt-link-rfc2396E" href="mailto:systemd@jelmail.com"><systemd@jelmail.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">[...] I did this: systemd-nspawn -bD /srv/lxc/testcontainer Starting the container this way is pretty-much instantaneous. You can log in and halt it cleanly. </pre> </blockquote> <pre wrap=""> Now that's interesting... </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">3. How do you mount API filesystems into the container (your config doesn't have /sys and /proc entries)? Try putting the fstab generated by the archlinux template (because that one I tested and it works). </pre> </blockquote> <pre wrap="">AIUI systemd does this automatically. They are mounted in my container. # df /proc /proc/sys /sys Filesystem 1K-blocks Used Available Use% Mounted on proc 0 0 0 - /proc proc 0 0 0 - /proc sysfs 0 0 0 - /sys </pre> </blockquote> <pre wrap=""> You are right, a container can be run without any lxc.mount entries at all. </pre> <blockquote type="cite"> <pre wrap=""> However, FYI, the following works and gives verbose logging output. lxc-start -n testcontainer /usr/lib/systemd/systemd -- --log-target=console --log-level=debug </pre> </blockquote> <pre wrap=""> ... which is? </pre> <blockquote type="cite"> <pre wrap="">I am now at the point where I have 2 containers, one created by lxc-archlinux (which works) and one created using what I believe are similar equivalent steps. They both have the exact same lxc config and the exact same packages installed. I still have the problem, but I have discovered more info... I get <a class="moz-txt-link-rfc2396E" href="mailto:user@0.servicestartoperationtimedout.Terminating.">"user@0.service start operation timed out. Terminating."</a> I tried to execute "systemd --user" manually and got "Trying to run as user instance, but $XDG_RUNTIME_DIR is not set". I've been digging around and noticed in the journal: Failed to open private bus connection: Failed to connect to socket /run/user/0/dbus/user_bus_socket: No such file or directory and pam_systemd(login:session): Failed to create session: Connection timed out I believe the problem lies in pam_systemd timing out (hence the login delay) because it can't talk to systemd-logind due to some IPC problem that I can't work out yet... </pre> </blockquote> <pre wrap=""> It's difficult to say what's going on without a verbose journal output... Can you obtain one? Can you post your container creation scripts, so that I try to reproduce your issue over the weekend? </pre> </blockquote> Ok, now this is wierd. I have distilled the problem down to the bare bones. I have a "build_container" script (<a class="moz-txt-link-freetext" href="http://pastebin.com/raw.php?i=RhDFhRZi">http://pastebin.com/raw.php?i=RhDFhRZi</a>) that will create a container called "testcontainer". It exhibits the problems I see. Now, if I rename that container to, say "testc", and restart it (changing nothing else at all) then it works fine. I am totally confused but it appears that the container's name affects how systemd operates...? if you can try it and see if the same happens to you that would be very helpful. $ ./build_container $ lxc-start -n testcontainer it starts: will see journal output in the console boot messages, like this: "<30>systemd[1]: Set hostname to <test>." you can log in as root. no password. Long delay. Eventual <a class="moz-txt-link-rfc2396E" href="mailto:user@0.servicestartoperationtimedout.Terminating">"user@0.service start operation timed out. Terminating"</a> You can then "halt". slow to stop. <a class="moz-txt-link-rfc2396E" href="mailto:user@0.servicestartoperationtimedout.Terminating">"user@0.service start operation timed out. Terminating"</a> takes 90 seconds. Eventually stops, host prompt returned. Now, with the container stopped, rename it: $ mv /var/lib/lxc/testcontainer /var/lib/lxc/testc Start the container again (with the new name) $ lxc-start -n testc it starts, instantly and without journal output in the console boot messages. you can log in as root. no password. instant prompt display. you can "halt". Immediate and quick termination. I don't know what to make of that. Actually, you can avoid the above. Here's another test with just "lxc-create" $ lxc-create -n testcontainer -t archlinux -- -P util-linux $ lxc-start -n testcontainer Same problem. (rename container as before but also edit the rootfs path in the /var/lib/lxc/testc/config file) Puzzled! I'll re-run this test tomorrow and capture full journal output if you need it but I've had enough for one day. J <blockquote cite="mid:20140404181708.07f77a04@hermes" type="cite"> <pre wrap=""> Also, what's the answer to Tom's question?</pre> </blockquote> just answered that one too (actually did so yesterday but forgot to press "send"!) <blockquote cite="mid:20140404181708.07f77a04@hermes" type="cite"> <pre wrap=""> Cheers, </pre> <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">_______________________________________________ systemd-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:systemd-devel@lists.freedesktop.org">systemd-devel@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/systemd-devel">http://lists.freedesktop.org/mailman/listinfo/systemd-devel</a> </pre> </blockquote> </body> </html>