How to run a command inside a running systemd container

OpenVPN wouldn't start with that Dockerfile because there's nothing to start it :-). Your entrypoint is sh; that's all it will run.

If you want to start two daemons inside Docker, your entrypoint needs to be a program that starts both of them. A lot of people use supervisord for this. Note that Docker is relatively opinionated software, and running multiple daemons in one container is not considered idiomatic.

If this is just about debugging, there's no problem. Just don't run openvpn with --daemon or --log. It will write to stdout (allegedly, though I wouldn't be surprised to see stderr). This is great for debugging if you start it manually. You'll see all the log messages immediately in the terminal.

If you set up the entrypoint and manually start the container in interactive mode - same deal. If you start it as a background container (pardon my vagueness), the output will be captured for docker logs. It's the same technique favored by modern init systems like systemd (and the systemd "journal" logging system).

Once you have the daemon set up how you want, you may be interested in more customized systems for capturing logs, like the other answers.

Docker has pluggable logging drivers, according to the manpage for docker logs. There's a "syslog" driver which says it writes to the host syslog. It says docker logs won't work, but I don't expect that's a problem for you.

WARNING: docker logs does work if you use the journald logging driver. However, on Debian defaults, my assumption is this would cause logs to be lost on reboot. Because Debian doesn't set up a persistent journal. It's not hard to change though, if that's what you want.

The other logging driver which supports the docker logs command is called "json-file". I expect that's persistent, but you might prefer one of the other solutions.

The "why" question

The point is that Docker containers don't necessarily work the same as the OS they're based on. Docker isn't OS virtualization like LXC, systemd-nspawn, or a virtual machine. Although Docker was derived from LXC, it was specifically designed for "application containers" that run a single program.

(Current) server distributions are designed as a combination of several running programs. So you can't take a package from them and expect it to behave exactly the same way inside one of these application containers.

Communication with a logging daemon is a great example. There's nothing there that's going to change, except that people will become more familiar with the concept of application containers. And whether that's what they actually want to use :). I suspect a lot of sysadmins would be more interested in a mashup of LXC (OS containers), with something like NixOS to share packages between containers; it just hasn't been written yet AFAIK. Or just a better LXC.

I've managed to fix this issue in a CentOS:7 Docker container. I've followed mainly the Guide on CentOS Docker image project.

FROM centos:7

ENV container docker
RUN (cd /lib/systemd/system/sysinit.target.wants/; for i in *; do [ $i == \
systemd-tmpfiles-setup.service ] || rm -f $i; done); \
rm -f /lib/systemd/system/multi-user.target.wants/*;\
rm -f /etc/systemd/system/*.wants/*;\
rm -f /lib/systemd/system/local-fs.target.wants/*; \
rm -f /lib/systemd/system/sockets.target.wants/*udev*; \
rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \
rm -f /lib/systemd/system/basic.target.wants/*;\
rm -f /lib/systemd/system/anaconda.target.wants/*;

# Install anything. The service you want to start must be a SystemD service.

CMD ["/usr/sbin/init"]

Now, build the image, and run it using at least the following arguments to docker run command: -v /run -v /sys/fs/cgroup:/sys/fs/cgroup:ro

Then main point is that /usr/sbin/init must be the first process inside the Docker container.

So if you want to use a custom script that executes some commands before running /usr/sbin/init, launch it at the end of your script using exec /usr/sbin/init (in a bash script).

Here is an example:

ADD cmd.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/cmd.sh

CMD ["/usr/local/bin/cmd.sh"]

And here is the content of cmd.sh:

#!/bin/bash

# Do some stuffs

exec /usr/sbin/init # To correctly start D-Bus thanks to https://forums.docker.com/t/any-simple-and-safe-way-to-start-services-on-centos7-systemd/5695/8

You could have System is booting up. See pam_nologin(8) if your using the PAM system, in that case, delete /usr/lib/tmpfiles.d/systemd-nologin.conf in your Dockerfile because it creates the file /var/run/nologin which generates this specific error.