# systemd on RHEL: Enterprise Standards für Dienste

TL;DR / Management Summary Obwohl systemd ein universeller Standard ist, folgt Red Hat (RHEL/Rocky/Fedora) spezifischen Konventionen. Während Debian-Admins oft alles in Unit-Files hardcodieren, nutzt die Red Hat Welt intensiv EnvironmentFiles in /etc/sysconfig/, um Konfiguration von Logik zu trennen. Zudem ist die Interaktion zwischen systemd und SELinux in RHEL deutlich strikter. In diesem Modul lernen wir den “Red Hat Way” des Service-Managements.

# 1. Einführung & Architektur

Wo liegen die Dateien?

In RHEL gibt es eine klare Trennung zwischen System-Standards und Admin-Änderungen:

• /usr/lib/systemd/system/: Standard-Units der Distribution (werden bei Updates überschrieben). Finger weg!
• /etc/systemd/system/: Ort für Admin-eigene Units oder Overrides. Hier arbeiten wir.

# Der Konfigurations-Fluss (Mermaid)

graph LR
    A[/etc/systemd/system/app.service] -->|Loads Vars| B[/etc/sysconfig/app]
    A -->|Execution| C[Process Binary]
    C -->|Logging| D[Journald]
    C -->|Security| E[SELinux Context]
    F[systemctl] -->|Controls| A

# 2. Der Red Hat Standard: /etc/sysconfig

Konfiguration sauber trennen.

Anstatt das Unit-File für jede Änderung (z.B. ein anderer Port) zu bearbeiten, nutzen wir Variablen-Dateien.

# Schritt 1: Die Config-Datei (/etc/sysconfig/myapp)

# Optionen für mein Go-Binary
MYAPP_OPTS="--port 8080 --db-host 10.0.0.5"
LOG_LEVEL="debug"

# Schritt 2: Das Unit-File (/etc/systemd/system/myapp.service)

[Unit]
Description=My Enterprise App
After=network.target

[Service]
Type=simple
EnvironmentFile=-/etc/sysconfig/myapp
ExecStart=/usr/local/bin/myapp $MYAPP_OPTS
Restart=on-failure

[Install]
WantedBy=multi-user.target

Das - vor dem Pfad sorgt dafür, dass systemd nicht abbricht, wenn die Datei fehlt.

# 3. Overrides: Bestehende Dienste anpassen

Kein Copy-Paste von Distribution-Files.

Wenn Sie einen Standard-Dienst (z.B. Nginx) anpassen wollen, kopieren Sie nicht das File aus /usr/lib. Nutzen Sie Drop-in Files.

# Erstellt automatisch /etc/systemd/system/nginx.service.d/override.conf
sudo systemctl edit nginx

Fügen Sie nur die Änderungen ein:

[Service]
# Dienst soll nach Absturz schneller neustarten
RestartSec=2s
# Limit für offene Files erhöhen
LimitNOFILE=65535

# 4. Day-2 Operations: Legacy & Management

Von chkconfig zu systemctl.

# Legacy-Befehle

RHEL hat lange an chkconfig festgehalten. Systemd erkennt alte SysVinit-Skripte automatisch und wrappt sie. Dennoch sollten Sie nur noch systemctl nutzen.

# Startup-Analyse (RHEL spezifisch)

# Welche Dienste bremsen den Bootvorgang?
systemd-analyze blame

# Visualisierung der Abhängigkeiten
systemd-analyze dot | dot -Tsvg > boot.svg

# 5. Troubleshooting & “War Stories”

Wenn der Dienst im RHEL-Ökosystem hakt.

# Story 1: “Der Environment-Verlust”

Symptom: Ein Skript läuft in der Bash einwandfrei, scheitert aber als systemd-Service, weil Pfade oder API-Keys fehlen. Ursache: systemd nutzt eine minimale Umgebung. $PATH ist oft nur /usr/bin:/bin. Lösung: Definieren Sie alle benötigten Variablen explizit im EnvironmentFile in /etc/sysconfig/.

# Story 2: “SELinux verhindert ExecStart”

Symptom: systemctl start meldet “Permission Denied” für das Binary in /opt/mytool/bin, obwohl es 755 Rechte hat. Ursache: Das Binary hat ein falsches Label (z.B. usr_t statt bin_t), und systemd darf keine unvertrauenswürdigen Typen ausführen. Lösung: restorecon -v /opt/mytool/bin/tool.

# 6. Fazit & Empfehlung

• Finger weg von /usr/lib: Nutzen Sie immer /etc/systemd/system/.
• Modularität: Nutzen Sie /etc/sysconfig/ für Variablen. Das macht Ihre Ansible-Playbooks deutlich sauberer.
• Status: Gewöhnen Sie sich an systemctl status -l, um die volle Fehlermeldung (statt abgeschnittener Zeilen) zu sehen.

# Anhang: Cheatsheet