liveBook · Manning

Systemd unit file

As explained in Podman in Action: Secure, rootless containers for Kubernetes, microservices, and more

A systemd unit file is a declarative configuration file describing a systemd-managed service or other unit.

A systemd unit file is a declarative configuration file that tells systemd how to manage a service. For Podman, it connects container lifecycle operations to Linux’s init system, allowing containers to start, stop, restart, and run at boot. section 7.0 section 7.3

Systemd tracks the processes belonging to a unit through cgroups, while Podman’s fork/exec model keeps those processes visible to systemd. A generated service commonly includes ExecStart, ExecStop, restart behavior, dependencies, and a conmon PID file. Avoid placing a detached podman run command directly in a hand-written unit: when Podman exits, systemd may treat the service as finished. section 7.0 section 7.3.2

Podman supports two useful unit-generation patterns:

  • Generate a unit for an existing container; ExecStart starts its identifier, while ExecStop stops it. section 7.3.2
  • Generate with --new; the unit runs the image, records a container ID, stops the container, and removes it afterward. section 7.3.3
  • Place rootless units under $HOME/.config/systemd/user, reload the user manager, and control them with systemctl --user. section 7.3.2

Generated rootless service

A generated myapp.service can declare Restart=on-failure, start an existing container with /usr/bin/podman start, stop it with /usr/bin/podman stop, and expose it through systemctl --user start myapp and systemctl --user status myapp. With --new, ExecStart instead uses podman run with --cidfile, --rm, --sdnotify=conmon, and --replace. section 7.3.2 section 7.3.3

ExecStop=/usr/bin/podman stop -t 10 8879112805...
Let's take a look at the generated service file: 
$ cat $HOME/.config/systemd/user/myapp.service
# container-8879112805e976b4b6d97c07c9426bdde22ee4ffc7ba4daa59965ae25aa08331.service
# autogenerated by Podman 3.4.1
# Wed Nov 10 08:23:06 EST 2021 
[Unit]
Description=Podman container-8879112805...service
Documentation=man:podman-generate-SystemD(1)
Wants=network-online.target
After=network-online.target
RequiresMountsFor=/run/user/3267/containers 
[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
TimeoutStopSec=70
ExecStart=/usr/bin/podman start 8879112805...
ExecStop=/usr/bin/podman stop -t 10 8879112805...
ExecStopPost=/usr/bin/podman stop -t 10 8879112805...
PIDFile=/run/user/3267/containers/overlay-containers/8879112805.../userdata/conmon.pid
Type=forking
[Install]
WantedBy=multi-user.target default.target

Inspect a complete generated unit showing dependency declarations, restart policy, lifecycle commands, PID tracking, and installation targets. section 7.3.2

How Podman in Action: Secure, rootless containers for Kubernetes, microservices, and more covers it

How deep it goes
Explains generated lifecycle commands, cgroup tracking, restart behavior, and rootless control, while warning against detached hand-written commands.
Examples
Uses generated myapp.service files, podman generate systemd, systemctl --user commands, and the --new lifecycle variant.
What you can do after
Operate/configure Podman containers through generated systemd units and systemctl, including boot startup, restarts, and cleanup.
How it connects
Connects systemd with Podman, containers, cgroups, conmon, restart policies, socket activation, and service notifications.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Podman in Action: Secure, rootless containers for Kubernetes, microservices, and more. The section links point to the parts of the book it draws on.