On 03/04/14 19:41, Leonid Isaev wrote:
On Thu, 03 Apr 2014 18:53:48 +0100
John Lane <syst...@jelmail.com> wrote:
On 03/04/14 16:40, Leonid Isaev wrote:
Hi,
On Thu, 03 Apr 2014 11:25:27 +0100
John Lane <syst...@jelmail.com> wrote:
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).
You have to tell exactly what you are doing. Just calling lxc-archlinux in
a loop?
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.
Well, few obvious questions:
1. Have you tried booting and logging in the container with
systemd-nspawn?
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.
Also, look at the --link-journal option for log debugging.
2. What does the autodev hook do and why do you need it?
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.
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).
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.
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...
#!/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
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".
What do you mean by "do not work properly"?
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.
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).
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.
HTH,
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 "user@0.service start operation timed out. Terminating."
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...
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
