Dienste sind Programme die im Hintergrund laufen - ohne direkte Benutzerinteraktion. Ein SSH-Server wartet auf Verbindungen, ein Webserver liefert Seiten aus, eine Datenbank verarbeitet Anfragen. Das Init-System startet diese Dienste beim Boot und hält sie am Laufen.
Dienste, Services und Daemons
Die Begriffe Dienst, Service und Daemon beschreiben dasselbe Konzept mit unterschiedlichen Nuancen:
Daemon:
Unix-Tradition bezeichnet Hintergrundprozesse als Daemons. Der Name stammt von griechischen Daimones - hilfreiche Geister die unsichtbar im Hintergrund wirken. Daemon-Programme enden oft mit ’d’: sshd (SSH-Daemon), httpd (HTTP-Daemon), crond (Cron-Daemon).
Service:
Moderner Begriff für verwaltete Hintergrunddienste. Services werden vom Init-System kontrolliert - gestartet, gestoppt, überwacht. Ein Service ist mehr als nur ein laufender Prozess: Er kennt seine Abhängigkeiten, seine Konfiguration und seinen Zustand.
Unterschied zu normalen Prozessen:
Normale Prozesse sind mit einem Terminal verbunden. Wenn der Benutzer sich ausloggt, beendet das System diese Prozesse. Dienste laufen unabhängig von Benutzer-Sessions. Sie starten beim Boot automatisch und laufen bis zum Shutdown.
Technisch trennt sich ein Daemon vom steuernden Terminal durch spezielle System-Calls (setsid(), fork()). Das Init-System übernimmt die Verwaltung - der Daemon muss sich nicht selbst daemonisieren.
Service-Zustände verstehen
Jeder Dienst befindet sich in einem bestimmten Zustand. Diese Zustände sind über verschiedene Init-Systeme hinweg ähnlich:
Running (Laufend):
Der Dienst ist aktiv und verarbeitet Anfragen. Ein SSH-Server im Running-Zustand akzeptiert Verbindungen. Der Prozess ist in der Prozess-Liste sichtbar und belegt Ressourcen.
Stopped (Gestoppt):
Der Dienst ist gestoppt - kein Prozess läuft. Ein gestoppter Webserver liefert keine Seiten aus. Gestoppte Dienste verbrauchen keine CPU oder RAM, nur Festplattenplatz für ihre Programmdateien.
Failed (Fehlgeschlagen):
Der Dienst sollte laufen, ist aber abgestürzt oder konnte nicht starten. Ein Failed-Status deutet auf Konfigurationsfehler, fehlende Abhängigkeiten oder Programm-Bugs hin. Das Init-System versucht typischerweise einen automatischen Neustart.
Enabled (Aktiviert):
Der Dienst startet automatisch beim Boot. Enabled ist keine Aussage über den aktuellen Zustand - ein Dienst kann enabled aber stopped sein. Die Enabled-Konfiguration bleibt über Reboots erhalten.
Disabled (Deaktiviert):
Der Dienst startet nicht automatisch beim Boot. Disabled-Dienste können manuell gestartet werden, starten aber nach einem Reboot nicht von selbst. Nützlich für Dienste die nur gelegentlich benötigt werden.
Masked (Maskiert):
Stärkere Form von Disabled - der Dienst kann weder manuell noch automatisch gestartet werden. Masking verhindert versehentliches Starten problematischer Dienste. Wird selten benötigt, ist aber verfügbar für spezielle Szenarien.
Ein Dienst kann gleichzeitig enabled und stopped sein: Er startet beim nächsten Boot, läuft aber momentan nicht. Oder disabled und running: Er läuft jetzt, startet aber nicht automatisch beim nächsten Boot.
Autostart-Konzepte
Das Init-System entscheidet beim Boot welche Dienste automatisch starten. Diese Entscheidung basiert auf Konfiguration und Abhängigkeiten.
Persistente Konfiguration:
Init-Systeme speichern Autostart-Informationen unterschiedlich. systemd nutzt Symlinks in /etc/systemd/system/, SysV-Init Runlevel-Verzeichnisse, OpenBSD die Datei /etc/rc.conf. Die Speicherung unterscheidet sich, das Konzept bleibt gleich: Eine Liste aktivierter Dienste.
Boot-Target oder Runlevel:
Verschiedene System-Modi definieren unterschiedliche aktive Dienste. Ein Server-System im Multi-User-Modus startet SSH und Datenbanken, aber keine grafische Oberfläche. Ein Desktop-System startet zusätzlich Display-Manager und Desktop-Services. Das gewünschte Target bestimmt welche Dienste aktiviert werden.
Abhängigkeitsbasierter Start:
Moderne Init-Systeme starten Dienste basierend auf Abhängigkeiten. Ein Webserver der eine Datenbank benötigt, startet erst nach der Datenbank. Das Init-System löst diese Abhängigkeiten automatisch auf. Der nächste Artikel dieser Serie behandelt Abhängigkeiten detailliert.
Default-Konfiguration vs. Administrator-Entscheidungen:
Paket-Installationen aktivieren oft Dienste automatisch. Ein installierter SSH-Server startet beim nächsten Boot. Diese Defaults sind praktisch, können aber unerwünscht sein. Administratoren deaktivieren nicht benötigte Dienste manuell - reduziert Angriffsfläche und Ressourcenverbrauch.
Service-Operationen
Das Management von Diensten umfasst grundlegende Operationen die über Init-Systeme hinweg ähnlich funktionieren:
Start:
Startet einen gestoppten Dienst. Das Init-System führt das Service-Binary aus, setzt Umgebungsvariablen und übergibt Konfigurationsdateien. Nach erfolgreichem Start wechselt der Service von Stopped zu Running. Bei Fehlern bleibt der Status Failed.
Stop:
Stoppt einen laufenden Dienst kontrolliert. Das Init-System sendet dem Service-Prozess ein SIGTERM-Signal. Der Dienst kann aufräumen - Verbindungen schließen, Daten speichern, temporäre Dateien löschen. Nach einem Timeout (typisch 90 Sekunden) erzwingt das Init-System die Beendigung mit SIGKILL.
Restart:
Kombiniert Stop und Start. Nützlich nach Konfigurationsänderungen die einen Neustart erfordern. Ein Webserver muss nach SSL-Zertifikat-Änderungen neu starten um die neuen Zertifikate zu laden.
Reload:
Lädt Konfiguration neu ohne den Dienst zu stoppen. Funktioniert über SIGHUP-Signal. Nicht alle Dienste unterstützen Reload - manche erfordern einen vollständigen Restart. Ein Nginx-Reload aktualisiert Virtual-Host-Konfiguration ohne bestehende Verbindungen zu beenden.
Enable/Disable:
Aktiviert oder deaktiviert Autostart beim Boot. Ändert nicht den aktuellen Zustand - ein laufender Dienst läuft nach Disable weiter, startet aber beim nächsten Boot nicht. Ein gestoppter Dienst startet nach Enable beim nächsten Boot automatisch.
Status-Abfrage:
Zeigt aktuellen Service-Zustand, Prozess-ID, Speicherverbrauch und letzte Log-Zeilen. Status-Informationen helfen bei der Fehlersuche - ein Service der constant restart-loopt deutet auf Konfigurationsprobleme hin.
Log-Zugriff und Monitoring
Dienste schreiben Logs für Debugging und Monitoring. Die Log-Speicherung unterscheidet sich zwischen Systemen, die Konzepte bleiben ähnlich:
Traditionelle Text-Logs:
Klassische Unix-Systeme schreiben Logs als Text-Dateien. System-Logs landen in /var/log/messages oder /var/log/syslog, service-spezifische Logs in eigenen Dateien wie /var/log/nginx/access.log. Text-Logs sind mit normalen Tools lesbar - grep, tail, less.
Binäre Logs:
systemd speichert Logs binär in journald. Binäre Logs ermöglichen strukturierte Abfragen - nach Zeitraum, Service, Priorität. Die Lesbarkeit erfordert spezielle Tools - ein journald-Log ist nicht mit less lesbar.
Log-Rotation:
Dienste schreiben kontinuierlich Logs. Ohne Management füllen Logs die Festplatte. Log-Rotation archiviert alte Logs komprimiert und löscht sehr alte Einträge. Die Rotation erfolgt zeitbasiert (täglich, wöchentlich) oder größenbasiert (bei 100 MB rotieren).
Prioritäts-Level:
Logs haben unterschiedliche Wichtigkeit. Debug-Logs enthalten detaillierte Programm-Abläufe. Info-Logs dokumentieren normale Ereignisse. Warning-Logs zeigen potenzielle Probleme. Error-Logs signalisieren Fehler. Critical-Logs markieren systembedrohende Situationen. Filter nach Priorität reduziert Log-Volumen.
Echtzeit-Monitoring:
Live-Logs zeigen Ereignisse während sie passieren. Ähnlich wie tail -f auf Text-Dateien. Nützlich beim Testen von Konfigurationsänderungen - die Auswirkungen sind sofort sichtbar.
Prozess-Überwachung und automatischer Neustart
Dienste können abstürzen - Bugs, Speichermangel, Netzwerkprobleme. Das Init-System überwacht Dienste und reagiert auf Ausfälle:
Crash-Detection:
Das Init-System bemerkt wenn ein Service-Prozess unerwartet terminiert. Ein SSH-Server der mit Exit-Code 1 endet signalisiert einen Fehler. Das Init-System unterscheidet zwischen sauberem Shutdown (Exit-Code 0) und Crash (andere Exit-Codes).
Restart-Policies:
Konfigurierbare Neustart-Strategien definieren Reaktionen auf Crashes. “Always” startet den Dienst bei jedem Absturz neu. “On-Failure” startet nur bei Fehlern neu, nicht nach sauberem Stop. “Never” überlässt die Entscheidung dem Administrator.
Restart-Delays und Backoff:
Sofortiger Neustart nach Crash kann zu Restart-Loops führen. Ein Dienst der wegen Konfigurationsfehler sofort wieder abstürzt, crasht in Endlosschleife. Restart-Delays verzögern Neustarts zunehmend - 1 Sekunde, 2 Sekunden, 4 Sekunden. Nach erfolgreicher Laufzeit (z.B. 60 Sekunden) resettet der Delay.
Restart-Limits:
Unbegrenzte Restart-Versuche verschleiern Probleme. Limits stoppen Neustart-Versuche nach bestimmter Anzahl oder Zeitraum. Ein Dienst der 5-mal in 10 Minuten abstürzt, bleibt gestoppt. Der Administrator muss das Problem beheben bevor der Dienst wieder startet.
Health-Checks:
Fortgeschrittene Monitoring-Konzepte prüfen nicht nur Prozess-Existenz, sondern Service-Funktionalität. Ein Webserver-Prozess kann laufen, aber keine Anfragen mehr beantworten. Health-Checks senden Test-Anfragen - bei Timeout gilt der Service als failed.
Socket-Activation und On-Demand-Start
Moderne Init-Systeme starten Dienste bei Bedarf statt beim Boot:
Konzept:
Das Init-System hört auf dem Service-Port und startet den eigentlichen Dienst erst bei eingehender Verbindung. Reduziert Boot-Zeit und Ressourcenverbrauch. Dienste die selten genutzt werden, belegen keinen Speicher bis sie gebraucht werden.
Transparenz:
Clients merken keinen Unterschied. Der erste Connect dauert etwas länger (Service-Start), nachfolgende Verbindungen funktionieren normal. Nach Inaktivität kann das Init-System den Dienst stoppen und bei Bedarf neu starten.
Use-Cases:
Sinnvoll für selten genutzte Dienste. Ein Drucker-Service der einmal pro Woche benutzt wird, muss nicht permanent laufen. Kritische Dienste wie SSH sollten permanent laufen - Socket-Activation bringt hier keinen Nutzen und erhöht nur die Komplexität.
Praktische Szenarien
Diese Konzepte zeigen sich in alltäglichen Situationen:
Service startet nicht:
Die Ursache liegt oft in Abhängigkeiten oder Konfiguration. Status-Abfragen zeigen den Failed-Zustand. Logs enthalten Fehlermeldungen - fehlende Konfig-Datei, Port bereits belegt, Berechtigungsproblem.
Service crashed wiederholt:
Restart-Loops deuten auf systematische Probleme hin. Zu viele Neustarts in kurzer Zeit triggern Restart-Limits. Logs zeigen die Crash-Ursache - Speichermangel, Datenbank-Verbindungsfehler, Bug im Service-Code.
Autostart funktioniert nicht:
Der Dienst läuft manuell gestartet, startet aber nicht beim Boot. Meist ist Enable nicht gesetzt oder Abhängigkeiten sind nicht erfüllt. Die Enabled-Konfiguration prüfen und Abhängigkeits-Kette untersuchen.
Performance-Probleme beim Boot:
Zu viele Services verzögern den Boot. Die Service-Start-Reihenfolge beeinflusst die Boot-Zeit. Nicht benötigte Dienste deaktivieren beschleunigt den Start. Der nächste Artikel erklärt wie Abhängigkeiten die Start-Reihenfolge beeinflussen.
Verwendete Software und Versionen
Diese Anleitung bezieht sich auf:
- Unix/Linux-Systeme: Allgemeine Service-Management-Konzepte
- Kontext: Distributionsunabhängig - systemd, SysV-Init, BSD-Init
- Stand: Oktober 2025
