92

Problem

It seems systemd is not active or available in Ubuntu Docker containers.

Setup

I'm running Docker containers from the ubuntu:16.04 and ubuntu:16.10 images.

Tests

If I execute:

systemctl status ssh in the 16,04 container

the result is the error Failed to connect to bus: No such file or directory

In the 16.10 container the error is: bash: systemctl: command not found.

If I do which systemctl systemctl is found in the 16.04 container but not in the 16.10 container.

I have spotted that /lib/systemd exists.

I have tried installing systemd with:

apt-get install systemd libpam-systemd systemd-ui

Then which systemctl finds systemctl in 16.10

but systemctl status ssh still gives the error Failed to connect to bus: No such file or directory

Questions

How can systemd and systemctl be activated for use in Ubuntu Docker images?

Why is systemd not active in Ubuntu Docker containers? Is systemd not used in instantiating the container?

I have failed to find any documentation on this topic for Ubuntu / Ubuntu Docker images, only information on the Ubuntu transition from Upstart to systemd. Is there any documentation giving a full explanation?

Mr. rc
  • 5
  • 1
  • 2
Duncan Gravill
  • 4,552
  • 7
  • 34
  • 51
  • If you want a fully functioning init system, use a virtual machine. – user2105103 Aug 26 '16 at 16:51
  • There are several proposals to imitate an init system at PID-1 inside a container. Basically it should react to the SIGTERM that is sent by "docker stop" distributing it to other processes in the container. And it should be able to reap zombies from killed background processes. => Now it just remains to choose one of the implementations that are around. Some are just porting a real "init" in C/C++, others are doing some scripting around signal(3) and waitpid(3) in a high-level language - Python's "signal" standard lib works for that too. (as shown in my docker-systemctl-replacement script) – Guido U. Draheim Mar 23 '17 at 14:37
  • 3
    run docker image with ```docker run --privileged -v /sys/fs/cgroup:/sys/fs/cgroup:ro ``` and ```systemctl``` works fine – bucky May 24 '19 at 06:48
  • why is this question closed? – gary69 Feb 08 '23 at 14:52

1 Answers1

95

This is by design. Docker should be running a process in the foreground in your container and it will be spawned as PID 1 within the container's pid namespace. Docker is designed for process isolation, not for OS virtualization, so there are no other OS processes and daemons running inside the container (like systemd, cron, syslog, etc), only your entrypoint or command you run.

If they included systemd commands, you'd find a lot of things not working since your entrypoint replaces init. Systemd also makes use to cgroups which docker restricts inside of containers since the ability to change cgroups could allow a process to escape the container's isolation. Without systemd running as init inside your container, there's no daemon to process your start and stop commands.

BMitch
  • 231,797
  • 42
  • 475
  • 450
  • 7
    There is no discussion of any of your points in the tutorial you have linked to so I don't see how you can say that it is "pretty much the first note in the tutorial" and it really isn't helpful to just link to the front page of the documentation. I learned from the Self-Paced Docker Training videos that the Entrypoint of a container has PID 1, so implicitly understood that the Entrypoint replaces systemd. However after reading numerous sections of the Docker docs I feel I am yet to read a full and clear explanation. – Duncan Gravill Aug 26 '16 at 17:25
  • 4
    To do something useful nearly always a base image contains an operating environment, my understanding was that the only difference between this and a full OS is that it doesn't have a kernel and instead uses the host OS's kernel. Perhaps a knowledge of OSs is assumed. I'm new to Linux. I need a detailed explanation of the differences between a regular Ubuntu/Linux Distro Operating Environment and a Dockerized Ubuntu/Linux Distro Operating Environment. – Duncan Gravill Aug 26 '16 at 17:25
  • 1
    Another point is that the first Self-paced Training Video implies that multiple processes can run inside a container so I feel that your statement about "no other processes" running in a container is at least partially inaccurate. Thanks for your response anyway. – Duncan Gravill Aug 26 '16 at 17:38
  • 1
    The top ranked related question to this is [How is Docker different from a normal virtual machine?](http://stackoverflow.com/questions/16047306/how-is-docker-different-from-a-normal-virtual-machine?rq=1) which you may find helpful. – BMitch Aug 26 '16 at 17:43
  • From the linked tutorial, the section I was referencing was "So what happened to the container after that? Well, Docker containers only run as long as the command you specify is active. Therefore, in the above example, the container stops once the command is executed." If you're not familiar with unix processes, shell scripts, and daemons vs foreground processes, I'd recommend learning about those before getting into containers. – BMitch Aug 26 '16 at 17:48
  • Re "no other processes", I never said that, I said "no other OS processes" in reference to systemd, init, cron, etc. The only processes running are those you launch from your pid 1, and once your pid 1 exits, your container exits. Therefore, it's an anti-pattern to try running any service as a daemon under something like systemd. – BMitch Aug 26 '16 at 17:50
  • Thanks for helping me onto the right track! I was speculating as to whether service processes could be started up upon container creation and then closed down when PID 1 exits. Clearly I was on the wrong track. Thanks for the pointers. – Duncan Gravill Aug 26 '16 at 18:36
  • 4
    By the way.... as I had some scripts around that issued "systemctl start" and "systemctl stop" as well, I have simply created a replacement script that can handle the necessary steps..... it is just interpreting the /etc/systemd/system/*.service files for that. No SystemD daemon is required for that. It can even perform what you would expect from a PID-1 process in a docker container. Feel free to have a look at the https://github.com/gdraheim/docker-systemctl-replacement – Guido U. Draheim Mar 23 '17 at 14:28
  • What is most curious for me is that service command (legacy for ubuntu 16.04) is working. How is is it different from systemctl as it is just alias for systemctl in modern ubuntu installations (as I understand it)? BTW +1 really nice answer. – abalcerek Aug 06 '18 at 20:44
  • Older releases of Ubuntu were likely SystemV, not systemd. Very different init system and doesn't cover the question from the OP. – BMitch Aug 06 '18 at 21:33
  • @BMitch There are alternatives to those SystemV, systemd etc. containers like docker etc can not provide %100 process isolation as the parent process has a view of child process ? what is the difference from chroot jail ? – hakkican Nov 25 '18 at 20:11
  • https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/ . I feel like the answer is missing something... Systemd's "nspawn" can do that and I've seen `docker run` lines that pass `-e container=docker` and run `systemd` as `init` inside. That would contradict your answer. – Johannes Schaub - litb May 30 '23 at 21:59