Ein geplanter Auftrag, der ohne das VPN lief, sieht in Ordnung aus

Der Auftragsstatus meldet Erfolg, das Protokoll zeigt einen abgeschlossenen Lauf, und die Daten sind veraltet oder fehlen. Diese Kombination bedeutet meist, dass der geplante Auftrag ohne den benötigten Pfad gestartet ist und etwas weiter unten den Fehler geschluckt hat. Ein Zeitplan, der pünktlich auslöst, sagt nichts darüber aus, ob das Netz bereit war. Genau in der Lücke zwischen diesen beiden Tatsachen lebt dieser Fehler.

Zulassung gehört zum Lauf, nicht zur Existenz einer cron-Datei.

Ein grüner Lauf ist kein abgeschlossener Auftrag

Ein Planer vermerkt, dass ein Prozess gestartet und später beendet wurde; er hat keine Ahnung, ob dieser Prozess die Ressource erreicht hat, für die er existiert. Ein Skript, das eine fehlgeschlagene Verbindung als leeres Ergebnis behandelt oder einen Fehler abfängt und mit Null beendet, sieht für immer gesund aus. Das Symptom ist kein roter Status; es ist ein plausibler Status, der an fehlende Arbeit gekoppelt ist.

Benennen Sie, was der Lauf tatsächlich braucht, bevor Sie entscheiden, wie er geprüft wird. Eine Sicherung braucht möglicherweise privates DNS und einen authentifizierten Endpunkt, nicht bloß einen Tunnelprozess.

Prüfen Sie die Verbindung, nicht den Schnittstellennamen

Eine Schnittstelle namens tun0 kann ohne die maßgebliche Sitzung existieren, und eine andere Verbindung kann diesen Namen besitzen. Prüfen Sie das konkrete Objekt, von dem der Auftrag abhängt: eine Profilidentität, eine Dienstinstanz oder eine kleine genehmigte Operation gegen die Ressource. Halten Sie die Prüfung zeitlich begrenzt und halten Sie Anmeldedaten aus Prozessargumenten und Diagnoseprotokollen heraus.

Definieren Sie auch das Ergebnis bei getrennter Verbindung. Ein gewöhnliches Überspringen, ein Wiederholungsversuch in einem kurzen Fenster und eine für den Bediener sichtbare verpasste Frist sind drei verschiedene Antworten, und ein wiederkehrender Zeitplan wählt nicht zwischen ihnen.

Überspringungen und Fehler sind verschiedene Ergebnisse

[Service]
Type=oneshot
User=worker
ExecCondition=/usr/local/libexec/check-office-path
ExecStart=/usr/local/bin/private-task

In einer systemd-Bereitstellung führt ExecCondition= diese Prüfung vor der Arbeitslast aus. Ihr Exit-Verhalten ist spezifisch: Null fährt fort, Codes von eins bis 254 überspringen die verbleibenden Startbefehle, ohne die Einheit als fehlgeschlagen zu markieren, und 255 oder eine abnormale Beendigung lassen sie fehlschlagen. Das ergibt drei getrennte Signale, die nur nützlich sind, wenn der Vertrag der Prüfung bewusst darauf abgebildet wird. Einstellungen, die Erfolg neu definieren, können das Bild verändern, also dokumentieren Sie die Zuordnung.

Erst das Erfassen von Überspringungen macht das Design ehrlich. Ein übersprungener Lauf, der nirgends erscheint, ist von einem erfolgreichen Lauf nicht zu unterscheiden, und jeden Prüffehler als stilles Überspringen zu behandeln, verdeckt eine kaputte Bereitstellung auf unbestimmte Zeit.

Schützen Sie den gesamten Lauf, nicht nur den Start

Eine Bereitschaftsprüfung beobachtet die Welt vor dem Start; sie überwacht danach nicht jeden Socket. Wenn ein direkter Pfad für diese Aufgabe nie akzeptabel ist, hängen Sie eine genehmigte Egress-Richtlinie an, die fortlaufend durchgesetzt wird und DNS, IPv6 sowie den eigenen Transport des Tunnels abdeckt. Das Umschalten des globalen IPv6-Zustands des Hosts ersetzt keine auf die Aufgabe begrenzte Richtlinie.

Entscheiden Sie, ob ein neues Ereignis einen noch laufenden Auftrag überlappen darf, halten Sie diese Regel beim Eigentümer der Arbeitslast und machen Sie Wiederholungen für die Datenoperation sicher. Das Stoppen eines Auftrags bei Verbindungsverlust begrenzt die Arbeit, garantiert aber nichts über Ausweichverkehr.

Akzeptieren Sie den Ablauf in drei Fällen: bereiter Pfad, nicht verfügbarer Pfad und Verlust während des Laufs. Alles Geringere prüft den Zeitplan, nicht den Auftrag.