Running systemd based container in LXC

Question

I'm currently trying to run an Arch Linux container using LXC on an Ubuntu 12.04 host. Arch Linux has recently migrated to systemd, which according to a variety of places has some problems operating as an LXC guest. However, many of these sources are substantially outdated, and I've seen various other sources suggesting that it is possible to run a systemd based guest, using things like lxc.autodev or devtmpfs.

As such, I'm trying to find out the following:

1. Is it possible to run a systemd based guest inside an LXC container (as of February 2013)?
2. Does anybody have an example template/config file to use with ```mkarchroot`` to get one running?

Currently using LXC version 0.7.5, but upgrading shouldn't be an issue if this is necessary.

Answer 1

answering to myself. The lxc-archlinux template is available at https://github.com/dotcloud/lxc/blob/master/templates/lxc-archlinux.in but it does not include the migration to systemd (as of Feb 15 2013) .

there are usable rootfs part of archlinux (e.g http://www.gtlib.gatech.edu/pub/archlinux/iso/2013.02.01/arch/i686/root-image.fs.sfs for i686 there also is a 64 bit version)

I did not run an lxc guest out of it yet but I got a functional i686 chroot from inside ubuntu 12.04 x64. 1/ download and unsquash the root image, mount it somewhere.

2/ as root (sudo) cp -ar the root filesystem to your location and chroot into it

3/ edit /etc/pacman.conf and update the arch line (by default it is auto, which pulls the ar ch from uname, but ubuntu and arch do not use the same designation)

4/ mount /proc /dev/random and /dev/urandom (this is needed by pacman and pacman-key)

I could not get pacman to run without package signature properly setup

5/ pacman-key --init (here it needs a good source of entropy)

6/ pacman-key --populate archlinux

7/ optional: pacman-key --refresh-keys (needs a working internet connection)

8/ edit /etc/pacman.d/mirrorlist to activate mirrors relevant to you.

9/ pacman -Syy

ready to update or install new packages.

What's (direly) missing is the container startup. I'm not up to speed on systemd but if I understand correctly this is mostly a matter of starting dbus and systemd.

Answer 2

I just stubmled upon your question. I have running systemd containers under Arch. I wrote some notes on the Arch Wiki explaining how to get it working. You do need lxc.autodev and you also need to mask some services that shouldn't run inside a container.

I do a basic mkarchroot and then make some changes (chroot into the new archroot):

ln -s /dev/null /etc/systemd/system/systemd-udevd.service
ln -s /dev/null /etc/systemd/system/systemd-udevd-control.socket
ln -s /dev/null /etc/systemd/system/systemd-udevd-kernel.socket
ln -s /dev/null /etc/systemd/system/proc-sys-fs-binfmt_misc.automount

In your container config you need

lxc.autodev = 1

And, if you need to create any device nodes (you probably will), you also need

lxc.hook.autodev = /path/to/script

plus the script file

#!/bin/bash
# LXC Autodev hook.
cd ${LXC_ROOTFS_MOUNT}/dev
mknod .....

The /path/to/script is a location on the HOST filesystem - for example /etc/lxc/mycontainer-autodev-hook.

Answer 3

According to the Gentoo wiki there is a template for arch that is partially functional (see http://wiki.gentoo.org/wiki/LXC#Arch_Linux for details). the template may be older than the switch to systemd. the fix/workaround includes using arch's package manager pacman. This is ok with gentoo, I managed once to get it to work on Ubuntu but the compilation is a chore.

the template may not be present in the lxc package provided with 12.04

if you recompile pacman (and its support library) then you'll probably be just as good using archbootstrap ( https://wiki.archlinux.org/index.php/Archbootstrap ) which is wildly inspired from debootstrap, brewing your own template based on the debian one.

Answer 4

We are successfully deploying systemd-based LXC containers on CentOS 7. The difficulties we've had mostly stem from standard Linux upgrades in general, like /run being a tmpfs and /var/run => /run (and some packages requiring that they be the same with internal tools using both), and systemd setting that up automagically, not under control of any unit that we can find and override.

We're converting from other process management methods (monit, hand-crafted daemons, periodic checks via cron) as we have to touch those services for whatever reason.