The problems systemd-docker solves

Running Docker containers directly under systemd sounds simple—but in practice, it introduces several subtle and annoying issues. These problems are exactly why systemd-docker was created.

1. Broken PID Tracking

When systemd starts a service, it expects to track the main process (PID 1) directly.
But if you run docker run in a unit file, the process systemd sees is actually the Docker client—not the container itself. This breaks restart logic, monitoring, and signal handling.

systemd-docker replaces itself with the actual container process using exec, so systemd sees and manages the real thing.

2. Missing Logs

Docker logs usually go to the container's stdout/stderr, which isn't automatically connected to journald. Without extra config, logs just vanish from journalctl.

systemd-docker makes sure the container’s output ends up in the journal—without hacks.

3. Zombie Processes

Containers often run just a single process. If that process is PID 1 and doesn't wait() on child processes, zombies pile up.

docker run --init fixes this inside the container. But systemd-docker ensures the host doesn’t lose control over container shutdown and cleanup, which is still an issue if you don't manage PIDs correctly.

4. Signal Handling

systemd expects to send signals (like SIGTERM) and have them respected by the main process. But Docker swallows and forwards signals in odd ways.

systemd-docker forwards signals properly and ensures clean shutdown behavior.

5. Inconsistent Behavior Across Machines

Different distros and systemd versions behave differently when wrapping Docker. What works on one host might fail silently on another.

systemd-docker makes the integration predictable and reliable, regardless of environment.