Question
Podman Rootless Containers and systemd User Session Persistence
Rahul Nea
0 reputation · 25 Jul 2024, 04:14 UTC
138K views1
Loading…
0 reputation · 25 Jul 2024, 04:14 UTC
Creating a repeatable development environment often requires containers to start automatically upon system boot, regardless of whether the developer has an active SSH or local session. Podman facilitates this by allowing the generation of systemd unit files to manage containers as user-level services.
In a rootless configuration, systemd user instances typically terminate when the last session for that user closes. This behavior creates a dependency between the physical or remote login state and the availability of the development services defined in the systemd user units.
While loginctl enable-linger is a known mechanism to keep the user manager running, the interaction between lingering sessions and the automatic restart policies defined in Podman-generated systemd units requires clarification for consistent environment repeatability.
podman generate systemd output interact with the WantedBy=default.target directive in a rootless context to ensure boot-time execution?Yes, the systemd user manager maintains the desired container state across reboots if lingering is enabled, even without an interactive session. When lingering is active, systemd starts a user-level manager instance for that specific user at boot and keeps it running independently of any active login sessions.
The WantedBy=default.target directive in a Podman-generated unit file tells the user-level systemd manager to start the service as soon as the user manager itself initializes. In a standard rootless setup, the user manager only starts upon the first login. However, when loginctl enable-linger is applied, the user manager is triggered at boot, which in turn triggers all services tied to default.target.
To ensure a rootless container starts automatically at boot and persists without a session, follow these steps:
podmansudo loginctl enable-linger <username>podman generate systemd is the legacy method, the resulting unit file must be placed in the user's systemd directory:
mkdir -p ~/.config/systemd/user/
# Example for legacy generation:
podman generate systemd --name my-container --files
mv container-my-container.service ~/.config/systemd/user/--user flag to enable the service within the user's session manager:
systemctl --user enable --now container-my-container.serviceThis behavior assumes you are using a modern Linux distribution with systemd (v230+) and that the user has correctly configured /etc/subuid and /etc/subgid for rootless mapping. To verify the configuration, you can check the linger status:
loginctl show-user <username> | grep LingerIf Linger=yes is returned, the user manager will persist across reboots. You can further verify by rebooting the host and running podman ps via a fresh SSH session to see if the container is already running.
Diagnostic Note: If the container fails to start despite lingering, please specify if you are using Quadlets (.container files) or legacy .service files, as the placement and activation methods differ.
Use comments to ask for clarification. Post a solution as an answer.
30,275 reputation · 25 Jul 2024, 14:26 UTC
A useful nuance for repeatability is that podman generate systemd is legacy in current Podman releases. Podman 4.x+ prefers systemd Quadlets, where a *.container file placed in ~/.config/containers/systemd/ is auto-converted to a user unit.
The unit still ends up WantedBy=default.target, so boot-time start still depends on lingering keeping the user manager alive. With lingering enabled, XDG_RUNTIME_DIR is created under /run/user/ by systemd-tmpfiles before the user manager starts, which is required for the container runtime socket.
Practical verification: loginctl show-user <user> -p Linger and sudo -u <user> systemctl --user is-system-running after reboot without interactive login.