# User Sessions: Die Macht von systemd --user

TL;DR / Management Summary Viele Admins wissen nicht, dass Systemd nicht nur globale Dienste verwaltet, sondern jeder Benutzer seine eigene Systemd-Instanz besitzt. Mit systemd --user lassen sich Dienste (z.B. Hintergrund-Syncs, Backup-Skripte, User-Level Webserver) starten, die nur für diesen Benutzer laufen und keine Root-Rechte erfordern. Der entscheidende Trick für Server-Automatisierung ist das Lingering, damit diese Dienste auch nach dem Logout aktiv bleiben.

# 1. Einführung & Konzepte

Dienste im User-Space.

Normalerweise laufen Systemd-Dienste als PID 1 (root). Die User-Instanz hingegen läuft als separater Prozess (systemd --user) unter der UID des jeweiligen Benutzers.

# Warum User-Services nutzen?

• Sicherheit: Keine Root-Rechte für die Ausführung nötig (Least Privilege Principle).
• Isolation: Konfigurationsfehler des Benutzers gefährden nicht das gesamte System.
• Autonomie: Benutzer können ihre eigenen Crons (Timer) und Dämons verwalten, ohne den Admin zu fragen.

graph TD
    A[PID 1: systemd --system] --> B[User Manager: systemd --user UID 1000]
    A --> C[User Manager: systemd --user UID 1001]
    B --> D[User Service: syncthing.service]
    B --> E[User Timer: backup.timer]
    C --> F[User Service: node-app.service]

# 2. Grundkonfiguration

Wo liegen die Dateien?

User-Unit-Files werden nicht in /etc/systemd/system/ abgelegt, sondern in:

• ~/.config/systemd/user/ (Für den jeweiligen Benutzer)
• /etc/systemd/user/ (Global für alle Benutzer, aber als User-Service ausgeführt)

# Beispiel: Ein User-Service (~/.config/systemd/user/my-agent.service)

[Unit]
Description=My Background Agent

[Service]
ExecStart=/home/user/bin/agent.sh
Restart=on-failure

[Install]
WantedBy=default.target

# Management-Befehle

Für User-Services muss immer das Flag --user angehängt werden:

# Status prüfen
systemctl --user status my-agent

# Starten/Aktivieren
systemctl --user enable --now my-agent

# Logs einsehen
journalctl --user -u my-agent

# 3. Der Admin-Trick: Lingering

Dienste am Leben erhalten.

Standardmäßig beendet Systemd alle User-Prozesse, sobald sich der Benutzer abmeldet (Logout). Für Server-Workloads ist das fatal.

# Lingering aktivieren

Mit “Lingering” startet der User-Manager beim Booten und bleibt nach dem Logout aktiv.

# Lingering für den aktuellen User aktivieren
loginctl enable-linger

# Status prüfen (als root)
loginctl user-status <username>

# 4. Day-2 Operations: Automatisierung

Praktische Anwendungsfälle.

# User-Timer statt Crontab

Anstatt crontab -e zu nutzen, definieren Sie Unit-Files. Diese sind sauberer in Systemd integriert und bieten besseres Logging.

Beispiel: ~/.config/systemd/user/cleanup.timer

[Unit]
Description=Hourly Temp Cleanup

[Timer]
OnCalendar=hourly
Persistent=true

[Install]
WantedBy=timers.target

# 5. Troubleshooting & “War Stories”

Wenn die User-Instanz streikt.

# Story 1: “Failed to connect to bus”

Symptom: systemctl --user gibt die Fehlermeldung “Failed to connect to bus: No such file or directory” zurück. Ursache: Die Umgebungsvariable XDG_RUNTIME_DIR ist nicht gesetzt (oft bei su - username oder SSH ohne korrekte Session-Initialisierung). Lösung: Nutzen Sie machinectl shell <user>@ oder exportieren Sie die Variable manuell (unsauber). Am besten via SSH direkt als dieser User einloggen.

# Story 2: “Dienst startet beim Booten nicht”

Symptom: Trotz enable startet der Service erst, wenn sich der User per SSH einloggt. Ursache: Lingering ist nicht aktiviert. Ohne Lingering wartet der User-Manager auf die erste interaktive Session. Lösung: loginctl enable-linger <user>.

# 6. Sicherheit & Limits

Obwohl User-Services sicherer sind als Root-Services, können sie Ressourcen verbrauchen. Admins können Limits in /etc/systemd/user.conf oder via globale User-Slices definieren.

• Tipp: Nutzen Sie systemd-run --user --scope -p MemoryMax=500M my-command.sh, um interaktive Befehle sofort zu limitieren.

# Anhang: Cheatsheet