10

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
8
  • 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 Commented Aug 23, 2016 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. Commented Aug 24, 2016 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). Commented Aug 24, 2016 at 9:31
  • The immediate problem you appear to be having though is that dbus isn't running inside your container. Commented Aug 24, 2016 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. Commented Aug 24, 2016 at 11:56

1 Answer 1

Reset to default
6

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
2
  • 3
    I just experimented a problem related to cgroups : your container cgroup version must match the one of the host, or you will get an error like "Failed to create /init.scope control group: Read-only file system". This is manageable through the boot flag systemd.unified_cgroup_hierarchy=[0|1], 0 for v1, 1 for v2. Commented Apr 7, 2021 at 10:07
  • 1
    @Hexdump You spared me a headache! Looks like cgroups v2 is default as of systemd v248: github.com/systemd/systemd/blob/… and github.com/systemd/systemd/blob/…. Also, archlinux/base has since been deprecated hub.docker.com/r/archlinux/base. hub.docker.com/r/archlinux/archlinux is the successor as of now. Commented Apr 14, 2021 at 8:26

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.