CertGrid CertGrid
Troubleshooting·Podman

Podman User Services and Linger

Everyone repeats that a rootless service dies at logout. On Ubuntu 26.04 it does not - `KillUserProcesses` is false. What lingering changes is measurable: without it the container starts 102 seconds after boot, when somebody logs in.

systemd and Quadlet Guide 22 of 47 Intermediate

Written against the versions above. Podman follows the distribution here rather than a vendor repository, so the version you get is the one Ubuntu shipped. The commands are stable across 5.x.

Every command on this page ran on podman01.
Server NameIP AddressOSRolesCPURAMHDD
PODMAN01192.168.0.24Ubuntu 26.04 LTSPrimary Container Host2 Core4 GB50 GB

Before you start

  1. Check the claim before acting on it

    The advice you will find everywhere is that a rootless service stops when your last session ends, and that loginctl enable-linger prevents it. The first half is worth checking rather than believing.

    KillUserProcesses is what actually decides it, and asking logind directly:

    b false

    False. On this system user processes are *not* killed when the session ends, so a running container survives logout with lingering off. The widely repeated advice describes a configuration this host does not have - and several distributions do ship it as yes, which is why the claim persists.

    So check your own host rather than inheriting the conclusion. If it says true, the usual story applies to you. If it says false, lingering still matters, for a different reason.

    bash Example session 
    loginctl show-user sysadmin --property=LingerLinger=nobusctl get-property org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager KillUserProcessesb falsepodman ps --format 'table {{.Names}} {{.Status}}'NAMES        STATUSquadlet-web  Up 1 second

    Expected resultLinger=no, b false, and a running container.

    Success conditionYou know what your own logind does at logout, from logind.

  2. Reboot, wait, and compare three timestamps

    The real question is not logout but boot. With lingering off, does a service with WantedBy=default.target start when the machine starts?

    The awkward part is observing it: logging in to look is the very thing that starts it. So instead - reboot, wait 95 seconds without connecting, then log in and compare when things happened:

    boot                   2026-08-22 11:50:06
user@1000.service      2026-08-22 11:51:48
container started      2026-08-22 11:51:48

    102 seconds after boot, and precisely when the user manager started - which is when I logged in.

    So the service is not broken and not disabled. user@1000.service simply did not exist until a session created it, and a unit cannot start before the manager that owns it. default.target for your user is reached at your first login, not at boot.

    For a web service this is the whole bug: the machine reboots at 03:00, nothing serves, and it silently fixes itself the moment somebody SSHes in to investigate.

    bash Example session 
    loginctl show-user sysadmin --property=LingerLinger=nouptime -s2026-08-22 11:50:06systemctl show user@1000.service --property=ActiveEnterTimestamp --valueSat 2026-08-22 11:51:48 UTCpodman inspect quadlet-web --format 'started={{.State.StartedAt}}'started=2026-08-22 11:51:48.695802701 +0000 UTC

    Expected resultA container start time roughly 100 seconds later than the boot time, matching the user manager's start.

    Success conditionYou have measured the gap between boot and your service starting.

  3. Enable lingering and measure again

    sudo loginctl enable-linger sysadmin, then the identical experiment - reboot, wait 95 seconds, log in, read the same three timestamps.

    boot                   2026-08-22 11:52:28
user@1000.service      2026-08-22 11:52:32
container started      2026-08-22 11:52:32

    Four seconds, against 102. And the clinching detail is the status line: at the moment of that first login the container read Up About a minute. It had been serving for the whole 95 seconds nobody was watching.

    The user manager now starts at boot, so default.target is reached with nobody logged in and the container starts there.

    That is all lingering does: it tells logind to start and keep user@1000.service regardless of whether the user has a session. Everything else follows from that one fact - including the logout behaviour on hosts where KillUserProcesses is true, because there the manager stopping is what takes the container with it.

    So the rule for any rootless service that must run unattended: enable lingering. It is one command, it needs root once, and it is the difference between a service and a thing that runs while you are watching. If you take one line from this track, it is this one:

    sudo loginctl enable-linger $USER

    The alternative, if you would rather not depend on it, is a rootful unit in /etc/containers/systemd/ - which starts at boot like any system service, at the cost of the container running as root.

    bash Example session 
    loginctl show-user sysadmin --property=LingerLinger=yesuptime -s2026-08-22 11:52:28systemctl show user@1000.service --property=ActiveEnterTimestamp --valueSat 2026-08-22 11:52:32 UTCpodman inspect quadlet-web --format 'started={{.State.StartedAt}}'started=2026-08-22 11:52:32.361370136 +0000 UTCpodman ps --format 'table {{.Names}} {{.Status}}'NAMES        STATUSquadlet-web  Up About a minute

    Expected resultLinger=yes, and a container whose start time is at boot rather than at login.

    Success conditionThe same service now starts without anyone logging in.

Troubleshooting

Official sources

← All Podman guides