Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
running systemd inside docker arch container hangs or segfaults #3629
I tried running the
When I run
In the same container (but with strace installed), running
segfaults, leaving the following output: https://gist.github.com/flokli/8456044
Do you have any idea whats wrong here? I'd really like to use docker in system container mode, and according to #223, this should already be possible...
I've tried this at digitalocean.com arch64 vm.
Same issue here with systemd 208-10
See https://bitbucket.org/dpaw/dpaw_docker/src/4785d502d806bc002bfc1644adb7d5bbcf7f68c3/arch-base/build.sh?at=default for the build script I've been testing (using archlinux's included lxc-create script), no GPT warning but still hit a segfault (will attach a strace when I get a chance).
Same problem on Fedora 20 with 208-9.
My initial impression is that it has something to do with the incomplete mount points in /sys/fs/cgroups and /sys/fs/selinux. When I use
My proposed solution would be one of:
Edit 01: Rebuilding with the --disable-selinux option leads to a segfault too, but at a different point. I had to remove the fsck and fstab related services to move on.
Edit 02: Hm, it looks like something cgroups related, here's the backtrace:
#0 strlen () at ../sysdeps/x86_64/strlen.S:106
And to save some time, here's the relevant code:
So it looks like to me either a null reference or just a null string. My C/C++ knowledge ends about right here. Maybe someone could take a go at it from here?
Edit 03: I tried it with disabling other systemd compile options and nothing changed. So, back to figuring out how to mount cgroups in /sys/fs I guess...
Edit 04: Final edit, giving up.
I found a collection of items/ideas that lead me to realize a couple things. The first is that the default docker container does not have the capability (SYS_CAP_ADMIN) to mount or unmount things. In newer builds (0.6 and later) there is the "-privileged" option for "docker run" that allows the container more leeway.
From there I found the option "lxc.mount.auto" that should have allowed me to auto mount sys, proc, and cgroups to the contained operating system. Running the following command
Really didn't do any good as it just makes a bunch of errors.
docker run -t -i -privileged -lxc-conf="lxc.mount.auto = proc:rw sys:rw cgroup-full:mixed" fedora /bin/bash
So... I found some more stuff here: http://blog.docker.io/2013/09/docker-can-now-run-within-docker/
I copied the helper script that he used, or at least parts of it, and I got SELinux and CGROUPS mounted!
But nothing changed. The segfault still happens at the same place. Maybe someone else can figure out what the heck is going on here.
There is a blog post from somebody that managed to run systemd in docker here: http://rhatdan.wordpress.com/2014/04/30/running-systemd-within-a-docker-container/
Apparently you need --privileged, mount cgroups and then tweak systemd configuration to stop it from bringing up a lot of unnecessary services.
is the first mail in a thread discussing the blog post mentioned above with hints from the systemd people on how the environment expected by systemd looks like. It would rock if docker could implement some of the things suggested there, especially mounting /sys RO (which will stop systemd from starting udev and is also sensible from a security point of view).
#5445 mounts /sys as read-only.
On Thu, May 8, 2014 at 1:29 AM, Tobias Hunger firstname.lastname@example.org:
--privileged requires write access to sys and proc. We wouldn't want to do
On Thu, May 8, 2014 at 10:44 AM, kfox1111 email@example.com wrote:
If we don't drop CAP_SYS_ADMIN, we are almost a privileged container :)
I think this should be handled at the container option level to drop/add
On Fri, May 9, 2014 at 9:50 AM, Victor Marmol firstname.lastname@example.org:
@victor: You are right But then it would be nice to be able to keep some
I do e.g. have one container that needs to be privileged because it needs
On Fri, May 9, 2014 at 6:53 PM, Rohit Jnagal email@example.com:
I don't think we have a good answer today for something in between unpriviledged and priviledged. I think we'd hope to have something since there are many usecases where you only want some privileges. I'm guessing the hard part is how to expose that in the API in a way that makes sense.
Given the prevalence of systemd, we should find a way to make it work though. I know @alexlarsson has been taking a look at that.
This is not really resolved, because this #5773 was reverted in c7d1cb227288fa2174bd601b7214d49955f387e3. I don't know what's going on, i just know that without cgroups and /run as tmpfs systemd can't be started in container, but with these two it can and it works fine.