HN Debrief

Systemd Linger

  • Infrastructure
  • Open Source
  • Developer Tools

The post walks through systemd's user-session model and the "linger" feature, which keeps a per-user systemd instance running after logout so user services can stay alive. It frames linger as part of the long-running fight over whether a user logging out should also kill their processes, especially things like screen, tmux, nohup jobs, and small user-owned daemons. The key practical point is that systemd split this behavior across more than one control, so what survives logout depends on both the feature and the distro's defaults.

If you rely on tmux, screen, user daemons, or background jobs surviving logout, check your distro defaults for both linger and KillUserProcesses instead of assuming generic systemd behavior. More broadly, expect Linux operational behavior to vary by distribution policy even when the underlying feature is the same.

Discussion mood

Mixed, but tilted negative on this specific feature. Even people who otherwise tolerate or like systemd described logout-time process killing and user-session semantics as confusing, surprising, and classic scope creep. Defenders mostly argued that the complexity buys consistency, security controls, and saner service management than the old init-script mess.

Key insights

  1. 01

    Distro defaults decide what you feel

    What users experience here depends less on abstract systemd behavior than on distribution policy. Debian Trixie ships with linger enabled, so detached workflows can appear unchanged, while Pop!_OS users reported getting burned. That makes a lot of blanket "systemd broke X" claims imprecise. The same feature lands very differently depending on what your distro turned on for you.

    Audit the actual defaults on every distro you run before writing docs or incident notes about session persistence. Mixed Debian and Ubuntu fleets can behave differently even when both are "using systemd."

      Attribution:
    • walrus01 #1
    • mike_hock #1
    • yjftsjthsd-h #1
  2. 02

    tmux survival is not mainly linger

    Detached tmux and screen sessions are easy to lump into the linger story, but that blurs two separate mechanisms. One commenter called out that linger has nothing to do with screen muxers on their setup and that the post mainly surfaced KillUserProcesses, which is the setting that surprises people expecting detached sessions to survive logout. That distinction matters because it changes what you need to inspect and fix.

    When sessions die on logout, check KillUserProcesses first. Only reach for linger when you actually need user services to keep running without an active login.

      Attribution:
    • c-hendricks #1
    • tux3 #1
  3. 03

    Uniform service management is systemd's real win

    The strongest pro-systemd case was not "it is simpler" but that it replaces a pile of bespoke startup scripts and daemon-specific conventions with one shared model. Dependency graphs, restart behavior, capability limits, sandboxing, and logging stop being one-off local craftsmanship and become repeatable platform features. That is why operators who manage large fleets keep defending it even when the interface is verbose.

    If you operate many services, standardize on unit files and built-in hardening features instead of carrying custom wrapper scripts. The migration cost is front-loaded, but it reduces per-service operational variance later.

      Attribution:
    • jauntywundrkind #1
    • dietr1ch #1
    • m0llusk #1
  4. 04

    Modular in theory, sticky in practice

    Several critics accepted that systemd is technically a collection of components, then argued that some parts are hard to remove without losing useful behavior or running into packaging and dependency pain. journald, logind, resolved, udev, and dbus create a level of coupling that feels bigger than the "pick and choose" story suggests. That criticism lands because the pain is operational, not architectural. If disabling a piece breaks enough adjacent features, the software may be modular on paper but not in the way admins care about.

    Before adopting one systemd component in isolation, test the real dependency surface on your distro. Treat "optional" modules as potentially sticky until you have proved you can swap them out cleanly.

      Attribution:
    • rnhmjoj #1
    • inigyou #1
    • yjftsjthsd-h #1

Against the grain

  1. 01

    Killing user processes can be sane

    The minority defense of this behavior is that child processes should not quietly outlive the user session that launched them unless you make that persistence explicit. From that view, detached jobs surviving logout are the surprising case, not the safe default, and clearing user processes on logout makes upgrades and session hygiene more predictable. That framing does not match old Unix habits, but it is internally consistent.

    If you care about strict session boundaries or shared-machine hygiene, make persistence an explicit opt-in. Document approved ways to launch durable user jobs instead of relying on inherited shell behavior.

      Attribution:
    • NekkoDroid #1
    • preg_match #1
  2. 02

    Plain sysvinit is still easier for some admins

    One admin running bare sysvinit said the attraction is not nostalgia but inspectability. When startup behavior lives in /etc/inittab and simple scripts, they can see the whole machine model at once and only add complexity they chose themselves. That is a useful reminder that "better for large fleets" and "easier to understand locally" are not the same criterion.

    For small, static systems, optimize for legibility before feature depth. If your team rarely needs advanced service controls, a simpler init stack may lower support overhead.

      Attribution:
    • M95D #1

In plain english

dbus ↩
D-Bus, an inter-process communication system that lets Linux services and desktop components talk to each other.
journald ↩
systemd-journald, the systemd logging service that collects and stores system and service logs.
KillUserProcesses ↩
A systemd logind setting that controls whether processes started by a user are terminated when that user logs out.
linger ↩
A systemd feature that keeps a user's systemd instance running after logout so user services can continue running without an active session.
logind ↩
systemd-logind, the systemd component that manages user logins, sessions, and related policy decisions.
nohup ↩
A Unix command that starts a process so it ignores hangup signals and can continue after logout or terminal closure.
resolved ↩
systemd-resolved, a systemd component that provides DNS resolution and can manage resolv.conf.
screen ↩
GNU Screen, an older terminal multiplexer that allows persistent command-line sessions you can detach from and resume later.
systemd ↩
A widely used Linux system and service manager that starts services, tracks processes, and provides related components like logging and session management.
tmux ↩
A terminal multiplexer that lets you run shell sessions in the background and reconnect to them later.
udev ↩
The Linux device manager that handles hardware events and device naming as devices appear and disappear.

Reference links

Alternative login and session components

Manuals and documentation examples