Files

MajorLinux 87d63039af wiki: audit fixes — broken links, wikilinks, frontmatter, stale content (66 files)

- 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>

2026-04-02 11:16:29 -04:00

3.1 KiB

Raw Blame History

title, domain, category, tags, status, created, updated

title

domain

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:

PID N vanished before we could move it to target cgroup
No 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 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.

gitea-runner-boot-race-network-target — Another systemd race condition involving service startup ordering

3.1 KiB Raw Blame History

Systemd Session Scope Fails at Login (session-cN.scope)