# SUSE Service Management: Systemd trifft auf sysconfig

TL;DR / Management Summary In SUSE wird das Service-Management durch zwei Welten geprägt: Den universellen Standard systemd und die SUSE-spezifische sysconfig-Infrastruktur. Während systemd die Prozesse steuert, dient /etc/sysconfig/ als zentrale Sammelstelle für Startparameter. Ein Senior Admin nutzt den YaST Services-Manager, um Abhängigkeiten zu visualisieren und sicherzustellen, dass Dienste nach dem Booten in der korrekten Reihenfolge und mit den richtigen Parametern starten.

# 1. Einführung & Architektur

Die Konfigurations-Logik.

In SUSE ist es Best-Practice, Dienstparameter nicht direkt in die Unit-Files zu schreiben, sondern die Variablen in /etc/sysconfig/ zu nutzen. Diese werden beim Start in das Environment des Dienstes geladen.

# Der Service-Fluss (Mermaid)

graph LR
    A[YaST Services Manager] --> B[systemd]
    B -->|Reads| C[/etc/systemd/system/]
    B -->|Reads Vars| D[/etc/sysconfig/]
    C --> E[Process: nginx/sshd/...]
    D --> E
    E --> F[Journald]

# 2. YaST Services-Manager

Die interaktive Schaltzentrale.

Starten Sie das Modul:

sudo yast2 services-manager

# Features für Profis

• Default Target: Schalten Sie bequem zwischen Multi-User (Text) und Graphical (Desktop) um.
• Start-Mode: Entscheiden Sie, ob ein Dienst On Boot, On Demand (Socket Activation) oder Manuell starten soll.
• Show Details: Zeigt die Abhängigkeiten (Wants/After) eines Dienstes grafisch an.

# 3. Die Macht von /etc/sysconfig/

Zentrale Variablen-Verwaltung.

Fast jeder wichtige Dienst hat hier eine Datei (z.B. apache2, cron, ssh).

# Beispiel: Apache2 Debug-Modus

Anstatt die httpd.conf zu ändern, bearbeiten wir /etc/sysconfig/apache2:

APACHE_SERVER_FLAGS="DEBUG"

Beim nächsten systemctl restart apache2 wird dieses Flag automatisch an den Prozess übergeben.

# Der sysconfig-Editor

Es gibt ein eigenes YaST-Modul nur für diese Dateien:

sudo yast2 sysconfig

Es bietet Beschreibungen zu jeder Variable – ideal, um versteckte Features eines Dienstes zu entdecken.

# 4. Day-2 Operations: systemd Overrides

Individuelle Anpassungen.

Wenn Sie Parameter ändern wollen, die nicht in sysconfig stehen (z.B. Ressourcen-Limits), nutzen Sie Overrides.

# Erstellt eine Drop-in Datei für den Dienst
sudo systemctl edit nginx

# Beispiel: Automatischer Restart

[Service]
Restart=always
RestartSec=5s

# 5. Troubleshooting & “War Stories”

Wenn der Dienst den Start verweigert.

# Story 1: “Der Ghost-Service”

Symptom: Ein Dienst wird in systemctl als aktiv angezeigt, tut aber nichts. Ursache: Der Dienst wurde manuell gestartet, ohne systemd zu informieren. Systemd trackt nur die PID, weiß aber nicht, dass der Prozess intern hängt. Lösung: Nutzen Sie immer systemctl restart. Prüfen Sie mit systemd-cgls, welche Prozesse wirklich in der Cgroup des Dienstes laufen.

# Story 2: “Dependency Loop”

Symptom: Der Server bootet nicht mehr und hängt in einer Endlosschleife. Ursache: Manuelle Änderungen an Unit-Files haben eine zyklische Abhängigkeit erzeugt (A braucht B, B braucht A). Lösung: Nutzen Sie systemd-analyze verify <unit>, bevor Sie den Server neu starten. Es findet solche logischen Fehler sofort.

# 6. Fazit & Empfehlung

• YaST: Nutzen Sie YaST für die Übersicht und die Aktivierung von Standard-Diensten.
• sysconfig: Schauen Sie erst in /etc/sysconfig/, bevor Sie die Haupt-Konfigurationsdatei eines Dienstes anfassen.
• Status: Nutzen Sie systemctl status -l, um die kompletten Fehlermeldungen inkl. der letzten Logzeilen zu sehen.

# Anhang: Cheatsheet