Unser Watchdog hat die Dienste neu gestartet, die wir absichtlich gestoppt hatten

Ops2026-10-31

Einer unserer Watchdogs startet jeden unserer Dienste, der aktiviert, aber nicht läuft. Zweimal im Oktober hat er Dienste gestartet, die wir absichtlich gestoppt hatten. Beim zweiten Mal erhielten Besucher einer unserer Websites etwa 45 Minuten lang Fehlermeldungen.

Warum es diesen Watchdog gibt

Ein Dienst, der sauber beendet wird, wenn er SIGTERM empfängt, zum Beispiel weil ihn jemand namentlich beendet hat, gilt für systemd nicht als "fehlgeschlagen". Restart=on-failure startet ihn nicht neu, und systemctl --failed listet ihn nicht auf. Er bleibt so lange unten, bis jemand zufällig darauf aufmerksam wird. Der Watchdog sucht daher nach Diensten, die aktiviert, aber nicht laufen, und startet sie.

Das Problem ist, dass ein Dienst, den Sie manuell gestoppt haben, genau gleich aussieht.

Das erste Mal

Am 7. Oktober haben wir einen Video-Worker um 12:47 Uhr mit systemctl stop gestoppt, um seine Job-Warteschlange zu bearbeiten. Um 12:55 Uhr lief er wieder: Der Watchdog hatte ihn gestartet.

Das zweite Mal

Am 21. Oktober brauchten wir den Speicher der Maschine, die auch zwei unserer Websites bedient, für einen Modelltest. Ein Skript stoppte die Web-Apps der Websites, einen Synchronisierungsjobs und einen Datenbank-Container, wiederum mit systemctl stop. Etwa fünf Minuten später brachte ein Timer, der die Websites überwacht, und um 19:14 Uhr der Watchdog den Tunnel und die Web-Apps wieder hoch.

Der Tunnel nahm wieder Traffic an, aber die Web-Apps konnten nicht antworten: Das getestete Modell belegte 114 GiB des Speichers der Maschine. Von etwa 19:14 bis 20:00 Uhr erhielten einige Besucher 502-Fehler. Um 20:00 Uhr deaktivierten wir den Tunnel, die Web-Apps und den Synchronisierungsjobs und stoppten den Überwachungs-Timer.

Die Regel, die wir jetzt verwenden

• Einen Dienst pausieren, indem Sie ihn deaktivieren: sudo systemctl disable --now <unit>. Wieder aktivieren mit sudo systemctl enable --now <unit>. Unser Watchdog prüft nur aktivierte Dienste, ein deaktivierter Dienst wird also in Ruhe gelassen.
• Alles pausieren, was ihn wieder starten könnte: den Tunnel davor und jeden Timer, der ihn überwacht.
• Ein kurzer Stopp ist ein Wettlauf. Wenn Sie nur stop verwenden, beenden Sie die Arbeit vor der nächsten Prüfung, die auf unseren Maschinen innerhalb weniger Minuten erfolgt.

Zwei weitere systemd-Fallen aus denselben Monaten

• systemctl mask --runtime bewirkt nichts für eine Unit-Datei in /etc/systemd/system. Units in /etc haben Vorrang vor der Runtime-Maske in /run, daher schlägt der Befehl nicht fehl, aber der Dienst startet trotzdem. Um einen Dienst anzuhalten, verwenden wir ein Drop-in mit ConditionPathExists=!/etc/<name>.hold: Solange diese Datei existiert, startet der Dienst nicht, weder beim Booten noch manuell.
• systemctl is-active meldet einen laufenden oneshot-Dienst als inaktiv. Während ein Type=oneshot-Dienst läuft, ist sein Zustand "activating", daher gibt is-active dies aus und liefert den Rückgabewert 3. Eine Schleife wie while systemctl is-active --quiet job.service; do sleep 60; done, die auf einen nächtlichen Job warten soll, wird sofort beendet. Lesen Sie stattdessen den Zustand: active, activating, reloading oder deactivating bedeuten alle, dass er noch läuft.

Factory Floor überwacht aktivierte Dienste, die nicht laufen. Standardmäßig meldet es diese nur und startet sie erst, wenn Sie dies aktivieren. Seit Version 1.0.3 enthält die Warnung auch Hinweise dazu, wie Sie einen Dienst gezielt pausieren können, und das Runbook sagt dasselbe.