Red Hat Training
A Red Hat training course is available for Red Hat Enterprise Linux
Chapter 5. Process Management
This section on process management covers two different situations:
- the single-process container, which houses the files that the container needs to do its job
- the managed-multiprocess container, which consists of several heterogeneous processes running at the same time
Apache is an example of a single-process container. Apache does all of its own logging, which means that it does not require an external container to do its logging. This means that using systemd in this case does not offer any benefits.
GNOME 3 is an example of a managed-multiprocess container. Attempting to manage this kind of container manually (for instance, trying to get upower and DBUS and logging working together) is more onerous than simply getting systemd to work.
5.1. Running systemd in a Container
In the case of the managed-multiprocess container, implement systemd to manage the several processes running within the container. To run systemd in a container, run a command similar to the following command:
$ sudo docker run -it IMAGE /bin/bash
The above command (-it) launches an interactive-tty container running systemd.
For more historical context on running systemd in a container, see Dan Walsh’s May 2014 blog post on the matter: Running systemd within a Docker Container.
5.1.1. journald and systemd in a container
Disable journal auditing in containers. Permit only the docker host to run journald. Journal auditing is a kernel feature, and only one instance of journald can use it at a time. (It is fine if the docker host is still running journald.)
5.1.2. Services and containers
Services work out of the box in containers. Services "just work" in containers. No special configuration is necessary for services to work in containers.
5.1.3. Managing Hardware that is Outside the Container
It is possible to create a container that uses systemd to manage outside hardware, but so configuring a container makes it non-portable because the container expects the specific hardware setup against which it is configured to be available for management.
5.1.4. systemd and Zombies
systemd solves the zombie problem. When processes die and become zombies, init 1 reaps them. This is just as true inside a container as it is outside a container. Expect systemd inside a container to reap zombies in exactly the way you have come to expect it to reap zombies outside a container.
If you start a container without systemd (or, for instance, sysv), processes that die in that container will never be reaped.
