wiki: add systemd session scope failure troubleshooting article

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

05-troubleshooting/index.md

@@ -16,6 +16,7 @@ Practical fixes for common Linux, networking, and application problems.
 ## 📦 Docker & Systems
 - [Docker & Caddy Recovery After Reboot (Fedora + SELinux)](docker-caddy-selinux-post-reboot-recovery.md)
 - [Gitea Actions Runner: Boot Race Condition Fix](gitea-runner-boot-race-network-target.md)
+- [Systemd Session Scope Fails at Login (`session-cN.scope`)](systemd/session-scope-failure-at-login.md)
 - [MajorWiki Setup & Publishing Pipeline](majwiki-setup-and-pipeline.md)
 
 ## 🔒 SELinux

05-troubleshooting/systemd/session-scope-failure-at-login.md

@@ -0,0 +1,93 @@
+# 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 --failed` shows one or more `session-cN.scope` units 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:
+
+1. `PID N vanished before we could move it to target cgroup`
+2. `No PIDs left to attach to the scope's control group, refusing.`
+3. 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
+
+```bash
+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
+
+```bash
+systemctl list-units --failed
+```
+
+If the only failed units are `session-cN.scope` entries, the system is healthy.
+
+## Fix
+
+Reset the failed unit:
+
+```bash
+systemctl reset-failed session-c1.scope
+```
+
+To clear all failed session scopes at once:
+
+```bash
+systemctl reset-failed 'session-*.scope'
+```
+
+Verify:
+
+```bash
+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 `c` in `session-c1.scope` indicates 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