Introduction

Running systemd inside Docker is possible, but it is usually a specialized choice rather than a default container pattern. Standard containers are designed for one main process, while systemd expects broader host-level control and cgroup integration. If you must run it, you need explicit runtime settings and strong security awareness.

Why It Is Usually Discouraged

Docker container design favors one foreground process with direct signal handling. systemd introduces additional process management complexity that is unnecessary for many workloads.

Prefer simpler alternatives when possible:

• Run one service per container.
• Use Docker Compose or Kubernetes for multi-service orchestration.
• Use lightweight supervisors only when truly necessary.

Still, legacy service bundles or migration constraints can require systemd temporarily.

Minimal Ubuntu Image with systemd

A basic setup installs systemd, configures stop signal, and starts /sbin/init.

1FROM ubuntu:22.04
2
3ENV container docker
4
5RUN apt-get update &&     DEBIAN_FRONTEND=noninteractive apt-get install -y systemd systemd-sysv &&     apt-get clean && rm -rf /var/lib/apt/lists/*
6
7STOPSIGNAL SIGRTMIN+3
8
9CMD ["/sbin/init"]

Build image:

docker build -t ubuntu-systemd .

Required Runtime Flags

You typically need privileged mode and cgroup mounts so systemd can manage services.

docker run -d   --name ubuntu-systemd-test   --privileged   -v /sys/fs/cgroup:/sys/fs/cgroup:ro   ubuntu-systemd

Then enter container and use systemctl:

docker exec -it ubuntu-systemd-test bash
systemctl status

Without proper cgroup integration, systemctl commands usually fail or show degraded state.

Service Management Example

Once systemd is running, you can install and manage services as usual.

1apt-get update
2apt-get install -y cron
3systemctl enable cron
4systemctl start cron
5systemctl status cron

This confirms service management flow works in the containerized environment.

Security and Operational Tradeoffs

--privileged significantly expands container capabilities and weakens isolation boundaries. Treat such containers as high-trust components and avoid exposing them broadly.

Operationally, debugging can be harder because process trees, logs, and health assumptions differ from standard single-process containers. Teams should document why systemd is needed and set a migration path away from it when feasible.

For production platforms, orchestration-level supervision is usually safer and easier to observe than nested service managers.

Migration Strategy Away from systemd Containers

If you inherit a systemd-based container, plan an incremental migration. Start by listing all managed services, then split them into separate containers based on runtime dependencies. Move shared configuration to environment variables or mounted config files, and replace systemctl lifecycle actions with container entrypoint logic.

A phased migration limits risk. You can keep one compatibility container for legacy functions while new services move to single-process images, then retire the compatibility layer once observability and health checks are stable.

Better Alternatives

If your goal is starting multiple dependent processes, consider:

• Splitting services into separate containers.
• Using an init process like tini for signal forwarding only.
• Orchestrating dependencies through Compose or Kubernetes.

These patterns align better with container-native operations and reduce privileged runtime requirements.

Common Pitfalls

A common pitfall is expecting systemctl to work in a regular Ubuntu container without extra runtime flags. It usually fails due to missing cgroup support.

Another issue is using privileged containers in sensitive environments without risk review. This can violate security policies.

Developers also keep long-term production workloads on systemd-in-container setups that were meant as migration bridges. Revisit architecture after initial migration pressure passes.

Finally, logs can be fragmented between journald and container stdout streams. Decide one observability strategy early to avoid troubleshooting delays.

Summary

• systemd in Docker is possible but not the default container model.
• It requires cgroup integration and often privileged runtime settings.
• Use it mainly for legacy or transitional scenarios.
• Prefer container-native orchestration for long-term operations.
• Document security implications and plan migration away from privileged setups.