systemd and systemctl within Ubuntu Docker images

Duncan Gravill picture Duncan Gravill · Aug 26, 2016 · Viewed 45.2k times · Source

Problem

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

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?

Answer

BMitch picture BMitch · Aug 26, 2016

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.