Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 5. Process Management

This section on process management covers two different situations:

  1. the single-process container, which houses the files that the container needs to do its job
  2. 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:

Copy to Clipboard Toggle word wrap 
$ sudo docker run -it IMAGE /bin/bash
Note

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.

Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat, Inc.