solita/docker-systemd

systemd-enabled versions of Docker base images

PROJECT UNMAINTAINED

This image is no longer used nor maintained by its original developer. If you want to continue its development, you may fork the project in accordance with its license.

---

solita/ubuntu-systemd

A Docker image based on ubuntu that runs systemd with a minimal set of services.

This image is meant for development use only. We strongly recommend against running it in production!

Supported tags

• 18.04, bionic
• 16.04, xenial, latest

But why?

The short answer: use solita/ubuntu-systemd for running applications that need to be run in a full Ubuntu system and not on their own as PID 1.

The long answer: solita/ubuntu-systemd might be a better choice than the stock ubuntu image if one of the following is true:

• You want to test a provisioning or deployment script that configures and starts systemd services.

• You want to run multiple services in the same container.

• You want to solve the the PID 1 zombie reaping problem.

If you just want to run a single, short-lived process in a container, you should probably use the stock ubuntu image instead.

Setup

Before you start your first systemd container, run the following command to set up your Docker host. It uses special privileges to create a cgroup hierarchy for systemd. We do this in a separate setup step so we can run systemd in unprivileged containers.

docker run --rm --privileged -v /:/host solita/ubuntu-systemd setup

Running

You need to add a couple of flags to the docker run command to make systemd play nice with Docker.

We must disable seccomp because systemd uses system calls that are not allowed by Docker's default seccomp profile:

--security-opt seccomp=unconfined

Ubuntu's systemd expects /run and /run/lock to be tmpfs file systems, but it can't mount them itself in an unprivileged container:

--tmpfs /run
--tmpfs /run/lock

systemd needs read-only access to the kernel's cgroup hierarchies:

-v /sys/fs/cgroup:/sys/fs/cgroup:ro

Allocating a pseudo-TTY is not strictly necessary, but it gives us pretty color-coded logs that we can look at with docker logs:

-t

Testing

This image is useless as it's only meant to serve as a base for your own images, but you can still create a container from it. First set up your Docker host as described in Setup above. Then run the following command:

docker run -d --name systemd --security-opt seccomp=unconfined --tmpfs /run --tmpfs /run/lock -v /sys/fs/cgroup:/sys/fs/cgroup:ro -t solita/ubuntu-systemd

Check the logs to see if systemd started correctly:

docker logs systemd

If everything worked, the output should look like this:

systemd 229 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN)
Detected virtualization docker.
Detected architecture x86-64.

Welcome to Ubuntu 16.04.2 LTS!

Set hostname to <aad1d41c3a2e>.
Initializing machine ID from random generator.
[  OK  ] Created slice System Slice.
[  OK  ] Reached target Slices.
[  OK  ] Listening on Journal Socket.
[  OK  ] Listening on Journal Socket (/dev/log).
[  OK  ] Reached target Local File Systems.
         Starting Journal Service...
         Starting Create Volatile Files and Directories...
[  OK  ] Reached target Swap.
[  OK  ] Reached target Sockets.
[  OK  ] Reached target Paths.
[  OK  ] Started Create Volatile Files and Directories.
[  OK  ] Started Journal Service.

Also check the journal logs:

docker exec systemd journalctl

The output should look like this:

-- Logs begin at Thu 2017-03-16 14:12:14 UTC, end at Thu 2017-03-16 14:12:26 UTC. --
Mar 16 14:12:14 aad1d41c3a2e systemd-journald[19]: Runtime journal (/run/log/journal/) is 8.0M, max 99.9M, 91.9M free.
Mar 16 14:12:14 aad1d41c3a2e systemd-journald[19]: Journal started
Mar 16 14:12:14 aad1d41c3a2e systemd[1]: Reached target System Initialization.
Mar 16 14:12:15 aad1d41c3a2e systemd[1]: Reached target Basic System.
Mar 16 14:12:17 aad1d41c3a2e systemd[1]: Starting LSB: Set the CPU Frequency Scaling governor to "ondemand"...
Mar 16 14:12:18 aad1d41c3a2e systemd[1]: Starting Permit User Sessions...
Mar 16 14:12:19 aad1d41c3a2e systemd[1]: Starting /etc/rc.local Compatibility...
Mar 16 14:12:20 aad1d41c3a2e systemd[1]: Started Daily Cleanup of Temporary Directories.
Mar 16 14:12:21 aad1d41c3a2e systemd[1]: Reached target Timers.
Mar 16 14:12:22 aad1d41c3a2e systemd[1]: Started Permit User Sessions.
Mar 16 14:12:23 aad1d41c3a2e systemd[1]: Started /etc/rc.local Compatibility.
Mar 16 14:12:24 aad1d41c3a2e systemd[1]: Started LSB: Set the CPU Frequency Scaling governor to "ondemand".
Mar 16 14:12:25 aad1d41c3a2e systemd[1]: Reached target Multi-User System.
Mar 16 14:12:26 aad1d41c3a2e systemd[1]: Startup finished in 11.215s.

To check for clean shutdown, in one terminal run:

docker exec systemd journalctl -f

And in another shut down systemd:

docker stop systemd

The journalctl logs should look like this on a clean shutdown:

Mar 16 14:15:49 aad1d41c3a2e systemd[1]: Received SIGRTMIN+3.
Mar 16 14:15:49 aad1d41c3a2e systemd[1]: Stopped target Multi-User System.
Mar 16 14:15:50 aad1d41c3a2e systemd[1]: Stopping Permit User Sessions...
Mar 16 14:15:51 aad1d41c3a2e systemd[1]: Stopping LSB: Set the CPU Frequency Scaling governor to "ondemand"...
Mar 16 14:15:52 aad1d41c3a2e systemd[1]: Stopped /etc/rc.local Compatibility.
Mar 16 14:15:53 aad1d41c3a2e systemd[1]: Stopped target Timers.
Mar 16 14:15:54 aad1d41c3a2e systemd[1]: Stopped Daily Cleanup of Temporary Directories.
Mar 16 14:15:55 aad1d41c3a2e systemd[1]: Stopped Permit User Sessions.
Mar 16 14:15:56 aad1d41c3a2e systemd[1]: Stopped LSB: Set the CPU Frequency Scaling governor to "ondemand".
Mar 16 14:15:57 aad1d41c3a2e systemd[1]: Stopped target Basic System.
Mar 16 14:15:58 aad1d41c3a2e systemd[1]: Stopped target Slices.

Known issues

There's a bug in Docker versions < 1.12.0 that randomly causes /run and /run/lock to be mounted in the wrong order. In this case the output of docker logs looks like this:

Failed to mount tmpfs at /run/lock: Permission denied
[!!!!!!] Failed to mount API filesystems, freezing.
Freezing execution.

If this happens to you, docker kill the container (it won't listen for the shutdown signal) and start it again with docker start. Better luck next time!

Contributors

• Timo Mihaljov
• Andrew Wason
• Damian ONeill
• Jeroen Vermeulen

License

Copyright © 2016-2018 Solita. Licensed under the MIT license.

docker-systemd's Issues

Docker-in-Docker issue.

Hey! Thanks for the work you'd done getting systemd running in an Ubuntu container. I'm trying to utilise what you've done using a a container within a container (Chef/Kitchen testing) and using the test container documented in the README I get the following error:

[root@698c28dc0f10 ~]# docker logs 69d925db484b
The systemd cgroup hierarchy is already mounted at /sys/fs/cgroup/systemd.
Your Docker host is now configured for running systemd containers!
[root@698c28dc0f10 ~]# docker run -d --name systemd --security-opt seccomp=unconfined --tmpfs /run --tmpfs /run/lock -v /sys/fs/cgroup:/sys/fs/cgroup:ro -t solita/ubuntu-systemd
7675be4a3fb0440c834739f7af790b4a4ca58b896769b065c4c0ca0a8edaf26e
[root@698c28dc0f10 ~]# docker logs systemd
systemd 229 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN)
Detected virtualization docker.
Detected architecture x86-64.

Welcome to Ubuntu 16.04.2 LTS!

Set hostname to <7675be4a3fb0>.
Initializing machine ID from random generator.
Cannot determine cgroup we are running in: No medium found
Failed to allocate manager object: No medium found
[!!!!!!] Failed to allocate manager object, freezing.
Freezing execution.

Failed to mount API filesystems, freezing.

I get freeze at startup on OS X 10.11.4. Any idea what went wrong?

~ ❯❯❯ docker run -i -t --stop-signal=SIGRTMIN+3 --tmpfs /run -v /sys/fs/cgroup:/sys/fs/cgroup:ro solita/centos-systemd:latest
[!!!!!!] Failed to mount API filesystems, freezing.

Failed to create bus connection

Host OS is OSX, running Docker for OSX.

$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.12.6
BuildVersion:	16G1212

$ docker --version
Docker version 17.12.0-ce, build c97c6d6

If I run the command from your example

docker run -d --name systemd --security-opt seccomp=unconfined --tmpfs /run --tmpfs /run/lock -v /sys/fs/cgroup:/sys/fs/cgroup:ro -t solita/ubuntu-systemd

Then

docker exec -it systemd /bin/sh
# timedatectl status
Failed to create bus connection: No such file or directory

The same scenario works fine with a centos image running systemd.

Thanks in advance for your help with this.
Damian.

Starting all the services in ubuntu-16.04

I am using Docker as a light-weight VM. I tried the official image ubuntu-16.04 but it did not start all the services. Then I came up with the following hack, which somehow works:
(see: https://github.com/dashohoxha/dbox/blob/master/docker/Dockerfile#L1-L12)

FROM ubuntu:16.04
ENV container docker
RUN echo '#!/bin/bash\n\
        for service in /etc/rc3.d/S* ; do\n\
            service=$(basename $service)\n\
            service=${service:3}\n\
            /etc/init.d/$service start\n\
        done\n\
        exec /sbin/init\n'\
    > /usr/local/sbin/init.sh
RUN chmod +x /usr/local/sbin/init.sh
CMD ["/usr/local/sbin/init.sh"]

Later I discovered solita/docker-systemd which looks like more professional, but also seems to me more complex. The previous solution seems to me simpler, it seems to work well so far, and I would like to stick with it if there is nothing fundamentally wrong with it.

What do you think, is it ok to keep using it, or there is something wrong with it?

docker logs is empty (aka. how to force systemd to log to stdout?)

Hello,

I tried to emulate the same setup for 16.10, but there seems to be no output from systemd.

I tried to strace systemd, but it just relentlessly tries to open /dev/console. Which is EIO or ENOSYS.

Then I tried with the 'canonical' image from docker hub, same result, no logs.

Support Docker for Mac and Docker for Windows

Add support for Docker for Mac and Docker for Windows.

cgroup location?

Hi, when I try to set up the cgroup hierarchy in amazon linux(EC2 example), it does not work. It outputs mkdir: cannot create directory '/host/sys/fs/cgroup/systemd': No such file or directory. And I realized that cgroup is not under /host/sys/fs and rather just /cgroups. How do I change the run command so it works on EC2 amazon linux?

user and passwd?

when i accept to access the container through ssh,what is the user and the passwd ?

docker-compose

hi, i cant figure out how to run this image with docker-compose

Update instruction seccomp=unconfined to seccomp:unconfined

In the instruction under Testing at https://hub.docker.com/r/solita/ubuntu-systemd/ there is the following:
docker run -d --name systemd --security-opt seccomp=unconfined --stop-signal=SIGRTMIN+3 --tmpfs /run --tmpfs /run/lock -v /sys/fs/cgroup:/sys/fs/cgroup:ro -t solita/ubuntu-systemd

That seccomp=unconfined should be updated to seccomp:unconfined - see e.g. moby/moby#24810

Warning: unable to find a suitable fs in /proc/mounts, is it mounted?

The aa-complain /usr/sbin/mysqld inside of a container ends with:

root@cikit01:~# aa-complain /usr/sbin/mysqld
Setting /usr/sbin/mysqld to complain mode.

ERROR: Cache read/write disabled: interface file missing. (Kernel needs AppArmor 2.4 compatibility patch.)
Warning: unable to find a suitable fs in /proc/mounts, is it mounted?
Use --subdomainfs to override.

Host and guest - Ubuntu 16.04.2 LTS.

The command for creating a container:

    docker run \
      -d \
      -h "cikit01.example.com" \
      -v /sys/fs/cgroup:/sys/fs/cgroup:ro \
      --name "cikit01" \
      --tmpfs /run \
      --tmpfs /run/lock \
      --security-opt seccomp=unconfined \
      -p 2201:22 \
      solita/ubuntu-systemd

root@brbr:~# docker --version
Docker version 17.06.0-ce, build 02c1d87

Documentation might offer a section to smoke test the running machine

For example

~ ❯❯❯ docker ps -a
CONTAINER ID        IMAGE                   COMMAND             CREATED             STATUS              PORTS               NAMES
6cf6cb029583        solita/ubuntu-systemd   "/sbin/init"        27 seconds ago      Up 26 seconds                           furious_shirley
~ ❯❯❯ docker exec -i -t 6c bash
root@6cf6cb029583:/# ps axufww
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root        33  0.0  0.0  18212  3216 ?        Ss   20:06   0:00 bash
root        44  0.0  0.0  34424  2892 ?        R+   20:06   0:00  \_ ps axufww
root         1  0.0  0.1  36824  4652 ?        Ss   20:04   0:00 /sbin/init
root        18  0.0  0.0  27904  1352 ?        Ss   20:04   0:00 /lib/systemd/systemd-journald
root@6cf6cb029583:/#

Or how to set up and run a ssh daemon inside the container. Including how to find out networking details.

How to set seccomp to unconfined while starting docker service ?

ARCH : S390X
OS : SLES 12 SP2

I am getting the below error while creating container on SLES using docker-18.03 installed from static binary.

"docker: Error response from daemon: OCI runtime create failed: container_linux.go:265: starting container process caused "seccomp: config provided but seccomp not supported": unknown.
"

I have installed libseccomp dependency and able to create a container by including --security-opt seccomp=unconfined while executing docker run command, but I want to disable seccomp while initializing the docker service itself.

I have tried to do it by passing the same parameter to docker service file but could not start the docker. Please let me know if there is any way.

SO_PEERCRED returns pid=0 when sending socket is in sibling container

This may be by design, but I'm wondering if there's some setting I can add when I create the docker-systemd container so that it can correctly resolve the PID in this case?

If I have a daemon running on the host listening to a unix domain socket and I volume-mount the socket file into some container, then that container can communicate with the host over the socket (say, via a REST API, similar to communicating with docker engine from the container). Also, the daemon can get the host-relative PID of the client process (e.g. to authorize the client) via getsockopt() with SO_PEERCRED.

But if I move the server into the systemd container (I'm testing the end-to-end experience of installing and running the daemon), then SO_PEERCRED returns pid=0.

It makes sense that this wouldn't work since the systemd container has its own PID namespace, but I'm wondering if the systemd container can be given a read-only view of the host PIDs so that SO_PEERCRED can see the right value, without interfering with the container's own PID namespace?

Sorry I don't have a minimal, self-contained example. The daemon I'm working with is here.

Thanks!

systemd-container-host-config: confusing error when DOCKER_MACHINE_NAME not set

Currently systemd-container-host-config fails confusingly on Windows or OS X when DOCKER_MACHINE_NAME is not set. E.g. on OS X:

usage: mount [-dfruvw] [-o options] [-t external_type] special node

       mount [-adfruvw] [-t external_type]

       mount [-dfruvw] special | node

Check if Docker has been set up, and if not, tell the user what they should do to set it up.

doesn't do clean shutdown at all.

Followed the instruction to test clean shutdown. When I run docker stop systemd, the other terminal basically just quit instantly and I'm not seeing any logs for graceful shutdown.

Possible to run container as user without affecting systemd functionality?

I realise this is quite an edge case scenario, but I was wondering if anybody knows if there is any way to make this container run as a specific user (not root) but without breaking systemd (PID1)?

Is it possible to load /etc/environment?

At the moment bash -lc 'env' results in something like:

TERM=xterm
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:
PATH=/root/.rbenv/shims:/root/.rbenv/bin:/root/.rbenv/plugins/ruby-build/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
PWD=/
RBENV_SHELL=bash
SHLVL=1
HOME=/root
LESSOPEN=| /usr/bin/lesspipe %s
LESSCLOSE=/usr/bin/lesspipe %s %s
container=docker
_=/usr/bin/env

However, the /etc/environment isn't loaded.

Support for Bionic 18.04

We love your Docker image, we use it daily for our test builds.
We are already testing on Ubuntu Bionic 18.04, do you plan to create an 18.04 image?