<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 03/04/14 19:41, Leonid Isaev wrote: </div> <blockquote cite="mid:20140403144155.76f726c8@hermes" type="cite"> <pre wrap="">On Thu, 03 Apr 2014 18:53:48 +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="">On 03/04/14 16:40, Leonid Isaev wrote: </pre> <blockquote type="cite"> <pre wrap="">Hi, On Thu, 03 Apr 2014 11:25:27 +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="">Hello, I have a number of LXC containers that have been working with systemd for some time. I have just tried to perform some upgrades, taking them from 204 to 212 (actually they are scripted rebuilds rather than upgrades). </pre> </blockquote> <pre wrap="">You have to tell exactly what you are doing. Just calling lxc-archlinux in a loop? </pre> </blockquote> <pre wrap="">I am not sure what you mean by "Just calling lxc-archlinux in a loop". I build a container using a script that is similar to, but not the lxc-archlinux template. It uses the Arch tools "mkarchroot" and "pacman" to install a collection of packages and then performs various setup tasks and creates appropriate configuration. Here is the LXC config produced: # Use autodev to be compatible with systemd lxc.autodev = 1 lxc.hook.autodev = /srv/lxc/testcontainer/autodev # hostname lxc.utsname = testcontainer # # network # if the network is not defined then the container # will be able to use the host's network lxc.network.type = veth #lxc.network.flags = up lxc.network.link = br0 lxc.network.name = eth0 lxc.network.mtu = 1500 lxc.network.hwaddr = DE:AD:BE:EF:CA:FE # restrict capabilities (security) see "man capabilities" lxc.cap.drop = sys_module #lxc.cap.drop = sys_admin # only explicit device access lxc.cgroup.devices.deny = a # # Memory Devices lxc.cgroup.devices.allow = c 1:3 rwm lxc.cgroup.devices.allow = c 1:5 rwm lxc.cgroup.devices.allow = c 1:7 rwm lxc.cgroup.devices.allow = c 1:8 rwm lxc.cgroup.devices.allow = c 1:9 rwm # # Terminals lxc.tty = 1 lxc.pts = 1024 lxc.cgroup.devices.allow = c 4:0 rwm lxc.cgroup.devices.allow = c 5:0 rwm lxc.cgroup.devices.allow = c 5:1 rwm lxc.cgroup.devices.allow = c 5:2 rwm lxc.cgroup.devices.allow = c 136:* rwm # # root filesystem lxc.rootfs = /srv/lxc/testcontainer # bind mount the host's pacman cache so container uses the same cache # rather than wasting time downloading packages already downloaded. lxc.mount.entry = /var/cache/pacman/pkg /srv/lxc/testcontainer/var/cache/pacman/pkg none rw,bind 0 0 This works fine with 208 but not with 209 so, I guess I am doing something that was correct for 208 but the goal-posts have been moved by 209. </pre> </blockquote> <pre wrap=""> Well, few obvious questions: 1. Have you tried booting and logging in the container with systemd-nspawn? </pre> </blockquote> 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 wrap="">Also, look at the --link-journal option for log debugging. 2. What does the autodev hook do and why do you need it?</pre> I use this hook to create device nodes in containers that need them. The test container doesn't need it so I've removed it. <blockquote cite="mid:20140403144155.76f726c8@hermes" 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> 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 However, I did try adding them to the fstab but it make no difference. I believe they're in the template so Arch containers work on non-systemd hosts. <blockquote cite="mid:20140403144155.76f726c8@hermes" type="cite"> <pre wrap=""> 4. AFAIU, lxc-start calls /sbin/init (which points to systemd). I'm not sure if this will work, but try replacing container init with a script that calls systemd --log-target=console --log-level=debug...</pre> </blockquote> #!/bin/sh /usr/lib/systemd/systemd --log-target=console --log-level=debug when container started: Failed to read /proc/cmdline. Ignoring: No such file or directory Trying to run as user instance, but the system has not been booted with systemd. However, FYI, the following works and gives verbose logging output. lxc-start -n testcontainer /usr/lib/systemd/systemd -- --log-target=console --log-level=debug <blockquote cite="mid:20140403144155.76f726c8@hermes" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">I have found that they do not work properly with any systemd versions 209 or later. I have read that 209 was a "massive new release". </pre> </blockquote> <pre wrap="">What do you mean by "do not work properly"? </pre> </blockquote> <pre wrap="">What I find is that the login prompt never results in a prompt. I enter the correct user/password and it takes an age before redisplaying the login prompt. If apply 208 before starting the container then it works as expected. I can get into the container with "lxc-attach". I'm a bit in the dark as the journal isn't showing me anything (or I don't know where to look). The thing I did notice was the 209 journal contained less than the 208 one which would suggest that 209 is not starting some services that 208 does (see linked pastes). I am looking into that but was hoping there might be an obvious pointer from the list - some things that have changed in 209 that might affect LXC and that I could perhaps look into more. </pre> </blockquote> <pre wrap=""> I am not sure that this particular issue is systemd's fault because I just created a working container on a fresh/stock arch install (with community/lxc) using the template (to test the patches which I sent to lxc-devel). </pre> </blockquote> Yes I can do that too. My script supposedly performs similarly to lxc-archlinux and it's producing the exact same LXC config and pacstrapping the exact same collection of packages. <blockquote cite="mid:20140403144155.76f726c8@hermes" type="cite"> <pre wrap=""> HTH, </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> 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... </body> </html>