systemd is Linux’s init system and service manager. As the first process after the kernel, it launches services, tracks their processes, and manages their lifecycles through unit files. section 1.3.7 section 7.0
Podman integrates with systemd rather than requiring a daemon to control containers. A systemd service can start, stop, restart, and supervise a container, while systemd tracks its processes in the service’s cgroup hierarchy. section 7.0 section 7.3
systemd integration supports several operational patterns:
- Run systemd as PID 1 inside a container so it can launch multiple services from their unit files. section 7.1
- Use socket activation and service-ready notifications for containerized applications. section 1.3.7
- Start containers at boot through systemd units or Podman restart policies such as always and unless-stopped. section 7.3 section 7.3.1
- Use journald for container logs and events, and generate unit files with podman generate systemd. section 7.7
Containers running systemd need an environment that matches its expectations. Podman supplies tmpfs mounts for /run, /tmp, and journald storage, sets the container environment marker, and uses SIGRTMIN+3 as the stop signal so systemd shuts down correctly without granting CAP_SYS_ADMIN. section 7.1.1 section 7.1.2
Inspect a systemd-enabled container
Create a debugging container with podman create --rm --name SystemD -ti --systemd=always ubi8-init sh. Inspect its stop signal with podman inspect SystemD --format '{{ .Config.StopSignal}}', then verify /run and /tmp are tmpfs mounts. Running ubi8-init launches systemd as PID 1. section 7.1.2
Table 7.1 Systemd requirements for running within a nonprivileged container (view table figure)
Use the requirements table to check the mounts, environment marker, logging path, and stop signal needed for systemd in an unprivileged container. section 7.1.1
