Zum Inhalt

Gecrashten Dienst neu starten

Ungeprüft

Diese Anleitung ist noch nicht durchgespielt worden; Befehle, Bezeichnungen und erwartete Ausgaben können abweichen. Was noch zu prüfen ist, steht in todo/doku.md.

Nur starten und stoppen, nichts ändern

Auf dieser Seite wird ein Dienst nur gestartet, gestoppt oder neu gestartet. Liegt der Fehler in der Konfiguration, wird er über das Repo behoben, nicht auf dem Host; siehe Was man von Hand darf.

Ziel

Ein abgestürzter Container, den systemd nicht mehr von selbst neu startet, läuft wieder.

Voraussetzungen

Die Beispiele nutzen hedgedoc-server.service auf werner; die Unit heißt wie der Container, mit der Endung .service. Alle Befehle laufen auf dem Host, nach:

Bash
1
ssh werner.garage-lab.de

Schritte

1. Status ansehen

Bash
1
systemctl status hedgedoc-server.service

Erwartet: In der Zeile Active: steht failed, meist mit Start request repeated too quickly darunter, oder activating (auto-restart).

  • Bei active (running) läuft der Container; dann liegt der Fehler woanders, weiter mit Container-Status und Logs ansehen.
  • Bei activating (auto-restart) versucht systemd es noch selbst; lies trotzdem die Logs in Schritt 2, damit du die Ursache kennst.

2. Ursache in den Logs suchen

Bash
1
journalctl -u hedgedoc-server.service -n 100 --no-pager

Erwartet: die letzten Zeilen vor dem Absturz; die Ursache steht meist kurz vor Main process exited bzw. Failed with result. Typische Ursachen:

Im Log Ursache Weiter
Verbindung zur Datenbank abgelehnt (connection refused, could not connect) Der Datenbank-Container lief nicht erst die Datenbank, etwa hedgedoc-postgres.service, mit diesen Schritten prüfen
Permission denied auf einem Volume SELinux „Permission denied“ durch SELinux beheben
out of memory oder oom-kill Speicherlimit erreicht Limit in syslet/<host>/host.cue anheben und ausrollen (Änderung ausrollen)
Fehler in einer Einstellung der App Konfiguration Stack-Datei korrigieren und ausrollen (Änderung ausrollen); kein Neustart hilft

Behebe die Ursache, bevor du weitermachst; sonst stürzt der Container gleich wieder ab.

3. Dienst neu starten

Bash
1
systemctl restart hedgedoc-server.service

Erwartet: keine Ausgabe. Der Befehl setzt auch den Zustand failed zurück, sodass systemd den Container bei einem späteren Absturz wieder von selbst neu startet.

Nicht systemctl reload und nicht podman restart: Einen Container steuerst du immer über seine Unit.

Muss ein Container für die Fehlersuche kurz aus sein, etwa damit er eine Datenbank nicht weiter beschreibt, geht das mit systemctl stop hedgedoc-server.service und danach systemctl start hedgedoc-server.service. Ein von Hand gestoppter Container bleibt gestoppt, bis du ihn startest oder jemand apply ausführt; soll er länger aus bleiben, geht das über das Repo (Was man von Hand darf).

4. Prüfen, ob er läuft

Bash
1
systemctl status hedgedoc-server.service

Erwartet: Active: active (running) mit einer Zeitangabe von eben, und nach einer Minute immer noch. Steht dort wieder activating (auto-restart) oder failed, zurück zu Schritt 2.

Prüfen

  • systemctl status hedgedoc-server.service zeigt active (running).
  • cue cmd plan im Ordner des Hosts zeigt No changes detected. All units are up to date.
  • Die App ist unter ihrem Namen erreichbar; welcher das ist, zeigt cue cmd ingress.

Wenn etwas schiefgeht

  • systemctl restart meldet Job for … failed: Der Container stürzt sofort wieder ab; zurück zu Schritt 2.
  • Der Container hängt beim Start an einem anderen, der nicht läuft (Dependency failed im Status): Starte zuerst diesen, etwa die Datenbank oder das Netzwerk (<name>-network.service).
  • Mehrere Container eines Hosts sind gleichzeitig ausgefallen, etwa nach einem Neustart: cue cmd apply im Ordner des Hosts startet alle, die laufen sollen (Änderung ausrollen).
  • Allgemeines: A unit failed during the apply in der syslet-Doku