Was verursacht, dass geplante Aufgaben auf dem Host, aber nicht innerhalb eines Containers ausgeführt werden?

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

What Causes Scheduled Jobs to Run on the Host but Not Inside a Container? - Zima Store Online

Geplante Aufgaben schlagen in einem Container fehl, wenn sich Scheduler, Umgebung, Benutzer, Zeit, oder der erforderliche Laufzeitpfad von der funktionierenden Host-Umgebung unterscheiden.

Ein Befehl, der in einer interaktiven Shell auf dem Host erfolgreich ist, kann vom PATH des Hosts, dem Anmeldeprofil, der Zeitzone, eingebundenen Dateien, Zugangsdaten, DNS oder einem dauerhaft laufenden Cron-Daemon abhängen. Innerhalb eines Containers ist nichts davon garantiert. Stellen Sie zunächst sicher, dass ein Scheduler-Prozess aktiv ist, und führen Sie anschließend den exakten Job mit derselben minimalen Umgebung und demselben Benutzer aus, die Cron verwendet.

Bestätigen, dass tatsächlich ein Scheduler-Prozess läuft

Untersuchen Sie die aktiven Prozesse und den Startbefehl des Containers. Die Installation von Cron-Paketen im Image startet den Daemon nicht, und ein Container führt normalerweise nur den konfigurierten Einstiegspunkt oder Befehl aus.

Die ausführliche Docker-Cron-Diskussion auf Stack Overflow dreht sich um die Notwendigkeit, einen Scheduler innerhalb des Containers auszuführen, anstatt anzunehmen, dass der Dienst des Hosts dessen Crontab steuert. Das erste entscheidende Kriterium ist, ob der Cron-Prozess aktiv ist, wenn die geplante Zeit erreicht wird.

Wenn kein Scheduler läuft, wählen Sie bewusst ein Design: Führen Sie Cron oder einen containergeeigneten Scheduler als Vordergrundprozess aus, verwenden Sie einen separaten Job-Container oder rufen Sie den Anwendungscontainer über den Cron des Hosts auf. Fügen Sie keinen zweiten, nicht verwalteten Daemon hinzu, ohne festzulegen, wie er protokolliert und beendet wird.

Den exakten Befehl mit einer minimalen Umgebung ausführen

Kopieren Sie den geplanten Befehl und führen Sie ihn im Container als der vorgesehene Job-Benutzer mit einer bereinigten Umgebung aus. Erfassen Sie Standardausgabe, Fehlerausgabe, Exit-Code, aktuelles Verzeichnis und Umgebungsvariablen.

Container-Cron-Jobs schlagen häufig fehl, weil Cron das interaktive Shell-Profil nicht lädt, das PATH, Sprachlaufzeiten, API-Tokens oder Anwendungsvariablen bereitgestellt hat. Ein auf Container ausgerichteter Scheduler-Leitfaden hebt die Beibehaltung der erforderlichen Job-Umgebung als zentrale Voraussetzung hervor.

Wenn der Befehl nur in der minimalen Umgebung fehlschlägt, ergänzen Sie explizite absolute Pfade und nur die unbedingt erforderlichen Variablen. Vermeiden Sie es, ein vollständiges Benutzerprofil zu laden, das unabhängige Aliase, Eingabeaufforderungen oder Geheimnisse einführt.

PATH, Shell, Arbeitsverzeichnis und Benutzer prüfen

Ersetzen Sie relative Befehle und Dateipfade durch absolute. Bestätigen Sie, dass die ausgewählte Shell vorhanden ist und die Crontab-Syntax zur im Image installierten Cron-Implementierung passt.

Führen Sie den Job als den konfigurierten Cron-Benutzer aus und testen Sie den Lese-, Schreib- und Ausführungszugriff auf Skripte, Konfigurationen, Sockets und Ausgabeverzeichnisse. Ein manueller Test als Root beweist nicht, dass ein geplanter Job mit eingeschränkten Rechten erfolgreich abgeschlossen werden kann.

Setzen Sie das Arbeitsverzeichnis innerhalb des Befehls oder Wrapper-Skripts. Wenn der Job erfolgreich ist, nachdem nur das Verzeichnis oder der Benutzer geändert wurde, halten Sie diesen expliziten Kontext in einer versionskontrollierten Konfiguration fest, statt sich auf die Standardeinstellungen des Containers zu verlassen.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Containerzeit und Zeitzone mit dem Zeitplan vergleichen

Geben Sie die aktuelle Zeit, die Zeitzone und den nächsten vorgesehenen Lauf innerhalb des Containers aus. Container verwenden die Systemzeit des Host-Kernels, können für die Anzeige und die Interpretation von Cron jedoch UTC oder andere Zeitzonendateien nutzen.

Ein Fall auf Server Fault zeigt, wie die Containerzeit in einer anderen Zeitzone erscheinen kann, obwohl der Host die lokale Zeit anzeigt, wodurch eine korrekte Crontab zur falschen scheinbaren Ortszeit ausgeführt wird.

Wählen Sie eine eindeutige Zeitzonenstrategie und überprüfen Sie sie nach einer Neuerstellung. Ändern Sie nicht einfach den Cron-Ausdruck, während die zugrunde liegende Zeitzone unklar bleibt, da Sommerzeit oder Änderungen am Image den Zeitpunkt erneut verschieben können.

Mounts, Geheimnisse, Netzwerkzugriff und Lebensdauer des Containers prüfen

Prüfen Sie, ob jedes Eingabeverzeichnis, jeder Ausgabepfad, jedes Geheimnis, jeder Socket und jede Konfigurationsdatei zur Laufzeit im Container vorhanden ist. Testen Sie anschließend DNS, Datenbank-, API- oder NAS-Zugriff aus demselben Containernetzwerk.

Der Cron des Hosts kann auf Hostpfade zugreifen, die im Container fehlen. Ein Nextcloud-Docker-Fall zeigt, wie ein Hintergrundjob zwar konfiguriert erscheinen kann, der tatsächliche Containerbefehl, Benutzer oder Anwendungspfad jedoch weiterhin die erwartete Hintergrundausführung verhindert.

Bestätigen Sie außerdem, dass der Container zum geplanten Zeitpunkt weiterläuft. Kurzlebige Anwendungscontainer und Ersetzungen im Rahmen von Deployments können einen internen Scheduler beenden, bevor lang laufende oder seltene Jobs abgeschlossen sind.

Eine Zeitplan-Grenze festlegen und den unbeaufsichtigten Betrieb nachweisen

Verwenden Sie eine einzige Instanz als Verantwortlichen für den Zeitplan: den Cron des Hosts, der docker exec aufruft, einen dedizierten Scheduler-Container oder einen Vordergrund-Scheduler innerhalb des Anwendungs-Images. Doppelte Scheduler können dieselbe Wartungsaufgabe zweimal ausführen.

Der ZimaSpace-Leitfaden zu DNS-Tests innerhalb von Containern behandelt eine mögliche nachgelagerte Ursache, wenn der Scheduler startet, aber einen anderen Dienst nicht erreichen kann.

Das Problem ist erst behoben, wenn der Job nach einer Neuerstellung des Containers und einem Neustart des Hosts zur vorgesehenen Zeit läuft, erfasste Protokolle erzeugt, den erwarteten Benutzer und die erwarteten Pfade verwendet und das überprüfte Anwendungsergebnis erstellt. Ein erfolgreicher manueller Befehl ist nicht der abschließende Test.