MajorLinux
6592eb4fea
- Fixed 4 broken markdown links (bad relative paths in See Also sections) - Corrected n8n port binding to 127.0.0.1:5678 (matches actual deployment) - Updated SnapRAID article with actual majorhome paths (/majorRAID, disk1-3) - Converted 67 Obsidian wikilinks to relative markdown links or plain text - Added YAML frontmatter to 35 articles missing it entirely - Completed frontmatter on 8 articles with missing fields Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
103 lines
3.1 KiB
Markdown
103 lines
3.1 KiB
Markdown
---
|
|
title: "Systemd Session Scope Fails at Login (session-cN.scope)"
|
|
domain: troubleshooting
|
|
category: systemd
|
|
tags: [systemd, ssh, login, session, linux]
|
|
status: published
|
|
created: 2026-04-02
|
|
updated: 2026-04-02
|
|
---
|
|
# 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](../gitea-runner-boot-race-network-target.md) — Another systemd race condition involving service startup ordering
|