2.9 KiB
Systemd Session Scope Fails at Login (session-cN.scope)
After SSH login, systemd reports a failed transient unit like session-c1.scope. The MOTD or login banner shows Failed Units: 1 — session-c1.scope. This is a harmless race condition, not a real service failure.
Symptoms
- Login banner or MOTD displays:
Failed Units: 1 session-c1.scope systemctl list-units --failedshows one or moresession-cN.scopeunits in a failed state- The system is otherwise healthy — no services are actually broken
What Causes It
A transient session scope is created by systemd-logind every time a user logs in (SSH, console, etc.). The scope tracks the login session's process group via cgroups.
The failure occurs when a login process (PID) exits before systemd can move it into the target cgroup. This is a race condition triggered by:
- Short-lived SSH connections — automated probes, health checks, or monitoring tools that connect and immediately disconnect
- Sessions that disconnect before PAM completes — network interruptions or aggressive client timeouts
- Cron jobs or scripts that create transient SSH sessions
systemd logs the sequence:
PID N vanished before we could move it to target cgroupNo PIDs left to attach to the scope's control group, refusing.- Unit enters
failed (Result: resources)state
Because session scopes are transient (not backed by a unit file), the failed state lingers until manually cleared.
How to Diagnose
1. Check the failed unit
systemctl status session-c1.scope
Look for:
Active: failed (Result: resources)
And in the log output:
PID <N> vanished before we could move it to target cgroup
No PIDs left to attach to the scope's control group, refusing.
2. Confirm no real failures
systemctl list-units --failed
If the only failed units are session-cN.scope entries, the system is healthy.
Fix
Reset the failed unit:
systemctl reset-failed session-c1.scope
To clear all failed session scopes at once:
systemctl reset-failed 'session-*.scope'
Verify:
systemctl list-units --failed
Should report 0 failed units.
Notes
- This is a known systemd behavior and not indicative of a real problem. It can be safely ignored or cleared whenever it appears.
- If it recurs frequently, investigate what is creating short-lived SSH sessions — common culprits include monitoring agents (Netdata, Nagios), automated backup scripts, or SSH brute-force attempts.
- The
cinsession-c1.scopeindicates a console/SSH session (as opposed to graphical sessions which use different prefixes). The number increments with each new session. - Applies to Fedora, Ubuntu, and any systemd-based Linux distribution.
Related
- gitea-runner-boot-race-network-target — Another systemd race condition involving service startup ordering