8

There seems to be tons of different ways people have been able to run systemd services within Docker containers. The latest example of direct advice I've found is to run Docker with --volume=/sys/fs/cgroup:/sys/fs/cgroup:ro --cap-add=SYS_ADMIN --security-opt=seccomp:unconfined. However, it still just fails:

Error: Could not start Service[ntpd]: Execution of '/usr/sbin/systemctl start ntpd' returned 1: Failed to connect to bus: No such file or directory

What is the absolute minimum I need to do to get simple services running under systemd 231 on a docker 1.12.1 container with an up-to-date Arch Linux distribution?

Improve this question
  • 1
    Docker is more about running the daemon directly once you give it a predefined ENTRYPOINT systemd doesn't factor into it. If you're looking for some sort of container integration with systemd you can look into creating an nspawn service – Bratchley Aug 23 '16 at 21:30
  • 1
    I'm not using Docker to run a single service. I'm using it to test a Puppet run which (among other things) starts multiple services. If I special case the test environment (use nspawn instead of systemd) the test is kind of useless. – l0b0 Aug 24 '16 at 7:50
  • "I'm not using Docker to run a single service" Then you can't use Docker at all. It's intended to run a single executable and everything is built around that fact. That's probably why this problem is so hard for you to solve. If you're testing a puppet run, what I usually do in that case is have a VM that I snapshot prior to doing the run. If you have something like Vagrant setup already it's pretty easy to just build new VM's and blow them away (as opposed to doing a snapshot). – Bratchley Aug 24 '16 at 9:31
  • The immediate problem you appear to be having though is that dbus isn't running inside your container. – Bratchley Aug 24 '16 at 9:33
  • 1
    I'm using Docker for this work for two reasons: Layers are easier to work with than snapshots to avoid large amounts of unnecessary work when re-running tests, and the current Docker setup is much simpler than the corresponding Vagrant one. I don't see why Docker should preclude running multiple services - they are just processes, after all. There's nothing stopping anyone from running multiple processes in Docker. I don't want any of them to be the ENTRYPOINT. – l0b0 Aug 24 '16 at 11:56
4

I ran into the same problem testing my Ansible playbooks which require systemd. And as you said, docker seems like the best approach here as it is much easier to bring up and down a container rather than a virtual machine.
First of all base/archlinux image is deprecated - you should use archlinux/base instead. Then, to run systemd totally unprivileged, number of things should be done:

  • provide a container= variable, so systemd won't try to do number of things it usually does booting a hardware machine
  • systemd actively uses cgroups, so bind mount /sys/fs/cgroup file system from a host
  • bind mounting /sys/fs/fuse is not required but helps to avoid issues with fuse-dependent software
  • systemd thinks that using tmpfs everywhere is a good approach, but running unprivileged makes it impossible for it to mount tmpfs where ever it wants, so pre-mount tmpfs to /tmp, /run and /run/lock
  • as the last bit you need to specify sysinit.target as default unit to boot instead of multi-user.target or whatever, as you really do not want to start graphical things inside a container

The resulting command line is

docker run \
  --entrypoint=/usr/lib/systemd/systemd \
  --env container=docker \
  --mount type=bind,source=/sys/fs/cgroup,target=/sys/fs/cgroup \
  --mount type=bind,source=/sys/fs/fuse,target=/sys/fs/fuse \
  --mount type=tmpfs,destination=/tmp \
  --mount type=tmpfs,destination=/run \
  --mount type=tmpfs,destination=/run/lock \
    archlinux/base --log-level=info --unit=sysinit.target

If we are talking about running particular service there like ntpd from your example you will need to add

--cap-add=SYS_TIME

otherwise ntpd will fail with permission deny as nobody wants a container to set system time by default.

P.s I spent quite a while learning how systemd behaves and managed to get it working on number of operating system images. I described my experience in an article Running systemd in docker container. It is in Russian but I believe google translate should work in your browser. Thanks

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.