Fix Podman Container Stops After Logout or Reboot

A detached podman run -d container can look healthy until you log out of SSH or reboot the host. Logout survival and reboot survival are different problems with different fixes. This guide shows how to reproduce each case, which knob applies, and how to confirm your host is configured correctly.

Container stops when the rootless user logs out

Rootless Podman ties container processes to your user systemd session. Start a long-running detached container as a normal user (not root):

podman run -d --name logout-demo registry.access.redhat.com/ubi9/ubi-minimal:latest sleep infinity

Confirm it is running before you disconnect:

podman ps --filter name=logout-demo

Sample output:

CONTAINER ID  IMAGE                                               COMMAND         CREATED        STATUS       NAMES
824831da2573  registry.access.redhat.com/ubi9/ubi-minimal:latest  sleep infinity  3 seconds ago  Up 3 seconds logout-demo

Log out of SSH completely — end every interactive session for that user — and log back in. Without linger enabled, list containers again:

podman ps -a --filter name=logout-demo

Sample output after the last session ended:

CONTAINER ID  IMAGE                                               COMMAND         CREATED         STATUS                       NAMES
824831da2573  registry.access.redhat.com/ubi9/ubi-minimal:latest  sleep infinity  10 minutes ago  Exited (137) 10 minutes ago  logout-demo

Exited (137) means the process received SIGKILL. systemd tore down user@UID.service when your final session closed, which killed conmon and the container workload. Rootful containers on the system instance do not hit this logout path — this symptom is almost always rootless plus linger disabled.

Why rootless containers can stop at logout

systemd-logind tracks login sessions per user. Rootless Podman stores containers under that user's cgroup tree, managed by user@UID.service.

When linger is off and your last session ends:

• logind stops the per-user systemd manager for that login period
• the user's runtime directory under /run/user/UID is removed
• processes in the user slice — including podman, conmon, and container PID 1 — are terminated

Linger tells logind to keep user@UID.service running even when no one is logged in. That is the upstream-supported way to run rootless daemons that must outlive SSH.

Fix logout survival with loginctl enable-linger

An administrator enables linger for the Podman user. Replace podmantest with your account:

sudo loginctl enable-linger podmantest

When you run the command for your own account from an elevated shell:

sudo loginctl enable-linger "$(id -un)"

enable-linger exits silently on success. Confirm the setting:

loginctl show-user podmantest -p Linger

Sample output:

Linger=yes

Start a fresh container with linger active:

podman run -d --name logout-demo2 registry.access.redhat.com/ubi9/ubi-minimal:latest sleep infinity

End your SSH session and reconnect. The container should still be up:

podman ps --filter name=logout-demo2

Sample output:

CONTAINER ID  IMAGE                                               COMMAND         CREATED        STATUS       NAMES
4a64dfa9b9d6  registry.access.redhat.com/ubi9/ubi-minimal:latest  sleep infinity  2 minutes ago  Up 2 minutes logout-demo2

Linger keeps the user manager alive; it does not restart a container you already stopped.

Disable linger and what it does not do

Turn linger off when you no longer want background user services after logout:

sudo loginctl disable-linger podmantest

Verify:

loginctl show-user podmantest -p Linger

Sample output:

Linger=no

Linger only affects the user systemd session lifecycle. It does not:

• set a Podman restart policy on any container
• recreate containers you removed
• start stopped containers after a host reboot

Treat linger as the logout fix. Reboot survival needs --restart plus podman-restart.service, or a systemd/Quadlet unit.

Logout survival and reboot survival are different

loginctl enable-linger alone does not restart a manually launched container after reboot. After power loss or reboot, every container process is gone until something explicitly starts it again.

Container is stopped after reboot

No container process survives an OS reboot. Create one without a restart policy to see the default:

podman run -d --name reboot-demo registry.access.redhat.com/ubi9/ubi-minimal:latest sleep infinity

After the host comes back, list all containers:

podman ps -a --filter name=reboot-demo

Sample output:

CONTAINER ID  IMAGE                                               COMMAND         CREATED       STATUS                     NAMES
7e8ffee07b78  registry.access.redhat.com/ubi9/ubi-minimal:latest  sleep infinity  2 hours ago   Exited (137) 2 hours ago   reboot-demo

The container record still exists in Podman storage, but the workload is stopped. Something must start it again — you, podman-restart.service, or a systemd unit.

Configure a Podman restart policy

Add --restart=always when you create the container so Podman tracks it for runtime restarts and boot:

podman run -d --name reboot-demo --restart=always registry.access.redhat.com/ubi9/ubi-minimal:latest sleep infinity

Read the stored policy:

podman inspect --format '{{json .HostConfig.RestartPolicy}}' reboot-demo

Sample output:

{"Name":"always","MaximumRetryCount":0}

--restart tells Podman what to do when the main process exits while Podman is running on a live host. Boot is a separate step handled by podman-restart.service.

podman-restart.service

Podman ships a systemd unit that starts eligible containers after boot. Inspect the system unit:

systemctl cat podman-restart.service

The ExecStart line on RHEL 10.2 Podman 5.8.2 is:

ExecStart=/usr/bin/podman $LOGGING start --all --filter should-start-on-boot=true

Check whether the system service is enabled:

systemctl status podman-restart.service --no-pager

Sample output (truncated):

○ podman-restart.service - Podman Start All Containers With Restart Policy Set To Always
     Loaded: loaded (/usr/lib/systemd/system/podman-restart.service; disabled; preset: disabled)
     Active: inactive (dead)

On this lab host the unit exists but is disabled until you enable it. Rootful hosts that rely on CLI-created containers should run:

sudo systemctl enable --now podman-restart.service

Rootless users need linger so user@UID.service runs at boot, then enable the user unit:

systemctl --user enable --now podman-restart.service

Inspect the user unit when present:

systemctl --user cat podman-restart.service

Package layout varies by distribution — verify the unit on your host instead of assuming paths.

always vs unless-stopped after reboot

Both policies can restart a container when its process dies on a running host. They differ after reboot and after manual stop.

List containers Podman considers boot candidates:

podman ps -a --filter should-start-on-boot=true --format '{{.Names}} {{.Status}}'

With reboot-demo (always) running and unless-demo (unless-stopped) manually stopped:

reboot-demo Up 43 seconds

unless-demo does not appear because podman stop recorded an explicit stop. Start it again and the filter includes it:

podman start unless-demo

Re-run the boot filter now that unless-demo is running again:

podman ps -a --filter should-start-on-boot=true --format '{{.Names}} {{.Status}}'

Sample output:

reboot-demo Up About a minute
unless-demo Up 2 seconds

After a simulated reboot — user runtime stopped and podman-restart.service started — only reboot-demo came back up; the stopped unless-stopped container stayed exited.

Why --restart is not meaningless

A common misconception is that --restart only matters with Quadlet. That is not accurate.

• --restart handles process exit while the Podman host is running
• podman-restart.service handles the after-reboot start for containers in the should-start-on-boot filter

Standalone podman run --restart=always plus an enabled podman-restart.service is a valid pattern for lab boxes and single-container hosts. For production services you usually move to Podman Quadlet and systemd so journalctl, dependency ordering, and systemctl restart apply.

Quadlet is the durable service answer

For a long-running server workload, declare the container in a Quadlet .container file and let systemd own lifecycle:

[Container]
Image=registry.access.redhat.com/ubi9/ubi-minimal:latest
ContainerName=web-demo

[Service]
Restart=always

[Install]
WantedBy=default.target

For this rootless example, default.target starts the service with the user manager. A rootful system Quadlet commonly uses multi-user.target instead.

For rootless Quadlet, place the .container file in the user Quadlet search path, include [Install] WantedBy=default.target, run systemctl --user daemon-reload, and start the generated service with systemctl --user start UNIT.service. Quadlet applies the [Install] section automatically; do not run systemctl --user enable on the generated service. Enable linger when the service must start at boot without anyone logging in.

For rootful Quadlet, use the system Quadlet path, include an appropriate [Install] target such as multi-user.target, run sudo systemctl daemon-reload, and start the generated service with sudo systemctl start UNIT.service.

This article does not walk through Quadlet syntax — see Podman Quadlet and systemd for the full workflow.

Do not combine Podman and systemd restart policy blindly

When systemd generates or manages the unit, systemd should own restart behavior:

[Service]
Restart=always

Do not normally add --restart=always inside the same systemd-managed container definition. One lifecycle manager should decide when the workload restarts. Layering both can produce double restarts or make failures harder to read in logs.

Diagnostic checklist

When a container disappeared or stayed stopped, run these checks in order.

Restart policy on the container:

podman inspect --format '{{json .HostConfig.RestartPolicy}}' CONTAINER

Linger for the rootless user:

loginctl show-user USER -p Linger

System restart service (pick root or user):

systemctl status podman-restart.service

For rootless workloads, check the user-scoped unit the same way:

systemctl --user status podman-restart.service

Boot-eligible containers:

podman ps -a --filter should-start-on-boot=true

Quadlet-managed service:

systemctl status SERVICE

Rootless Quadlet units use the user manager instead:

systemctl --user status SERVICE

Troubleshooting

References

• Podman rootless documentation
• loginctl(1) — enable-linger
• systemd user@.service
• Podman podman-restart.service unit

Summary

Rootless Podman containers stop at logout when linger is disabled because they live under user@UID.service, and logind tears that down when your last session ends. sudo loginctl enable-linger USER keeps the user manager running so detached containers can survive SSH disconnect — but linger does not bring containers back after a reboot.

Reboot is a separate problem. Every container process dies when the host restarts; Podman only starts them again when a restart policy marks them for boot (should-start-on-boot) and podman-restart.service runs — or when systemd/Quadlet owns the unit. Use --restart=always when you want boot survival; use unless-stopped when manual podman stop should be remembered across reboot.

For production services, move from ad hoc podman run to Quadlet with Restart= on the unit, enable linger for rootless boot, and avoid stacking Podman --restart on top of systemd-managed containers. When the container exits immediately instead of at logout, read the exit code before changing restart policy — that is a different troubleshooting path.