Cron-Ausdruck-Parser

Fünf Felder, das gröbste zuletzt

Innerhalb eines Feldes: * heißt beliebig, , zählt Werte auf, - gibt einen Bereich, / schrittet. */15 im Minutenfeld ist alle fünfzehn Minuten; 5/10 heißt ab 5 in Zehnerschritten, also 5, 15, 25 und so fort. Bereiche dürfen umlaufen, FRI-MON ist also eine gültige Art, das Wochenende samt seiner Ränder zu sagen.

Die Regel, die jeden erwischt

Das ist das eine, was man von dieser Seite mitnehmen sollte.

Sind beide Felder — Tag des Monats und Wochentag — eingeschränkt, führt cron den Job aus, wenn eines von beiden zutrifft. Nicht beide. Es ist ein ODER und liest sich wie ein UND.

0 0 1 * MON   # NOT "the 1st, if it is a Monday"
              # Actually: every 1st, AND every Monday

Dieser Zeitplan feuert rund fünfmal im Monat. Fügen Sie ihn oben in den Parser ein und sehen Sie sich die nächsten Laufzeiten an — die Folge verrät es sofort.

Die Regel greift nur, wenn beide Felder eingeschränkt sind. Steht in einem *, bestimmt schlicht das andere, weshalb 0 0 * * MON sich genau wie erwartet verhält. Das Verhalten steht in der POSIX-Spezifikation und jeder verbreitete cron setzt es um, es ist also kein Fehler, den man wegkonfigurieren kann.

Um wirklich beide Bedingungen zu verlangen, schränken Sie ein Feld im Zeitplan ein und prüfen das andere am Anfang des Jobs:

0 0 * * MON  [ "$(date +\%d)" = "01" ] && /usr/local/bin/job

Die Zeitumstellung, die Jobs zweimal im Jahr zerlegt

Cron läuft in der lokalen Zeitzone des Servers, sofern nichts anderes gesagt wird, und Ortszeit ist nicht durchgehend. Beim Vorstellen verschwindet eine Stunde: Ein für 02:30 geplanter Job kann ganz ausfallen oder um 03:30 feuern, je nach cron. Beim Zurückstellen gibt es 01:30 zweimal — und womöglich den Job auch.

Moderner Vixie-cron bemüht sich — durch den Vorwärtssprung verpasste Jobs laufen meist einmal danach —, aber das Verhalten ist über die Implementierungen hinweg nicht einheitlich, und Container-Scheduler weichen nochmals ab.

Die dauerhafte Lösung ist, den Scheduler in UTC laufen zu lassen und an den Rändern umzurechnen. Kubernetes-CronJobs laufen genau deshalb standardmäßig in UTC. Muss ein Job zu einer bestimmten Ortszeit laufen, nehmen Sie hin, dass er einen Teil des Jahres eine Stunde danebenliegt — oder nehmen Sie einen Scheduler, der Zeitzonen wirklich versteht: systemd-Timer tun das.

Andere Gründe, warum ein Cron-Job nicht läuft

• Die Umgebung ist nahezu leer. Cron liest Ihr Shell-Profil nicht ein, PATH ist also minimal und Ihr virtuelles Environment nicht aktiv. Verwenden Sie immer absolute Pfade.
• Ein nacktes Prozentzeichen. In einer crontab bedeutet % einen Zeilenumbruch. date +%Y bricht stillschweigend; es muss date +\%Y heißen.
• Kein abschließender Zeilenumbruch. Manche crons ignorieren die letzte Zeile einer crontab, die nicht mit einem endet.
• Die Ausgabe geht ins Nichts. Cron mailt die Ausgabe an den Benutzer, und ohne konfigurierte Mail verschwindet sie. Leiten Sie in eine Logdatei um, damit Fehlschläge sichtbar sind.
• Überlappende Läufe. Cron wartet nicht, bis der vorige Lauf fertig ist. Ein fünfminütiger Job im Minutentakt staut sich, bis etwas umfällt. Nehmen Sie flock.

Was cron nicht ausdrücken kann

Die Felder sind unabhängig, alles, was nicht glatt in eine Stunde oder einen Tag aufgeht, ist damit unerreichbar. „Alle 90 Minuten“ lässt sich nicht schreiben. „Der letzte Freitag im Monat“ in Standard-cron ebenso wenig — dafür gibt es L und # in Quartz, und deshalb sind sie nicht portabel.

Wenn Sie mit der Syntax ringen, ist das meist das Signal, zu einem Scheduler zu wechseln, der in Intervallen statt in Kalenderfeldern denkt. Ein systemd-Timer mit OnUnitActiveSec=90min sagt in einer Zeile, was Sie meinten.

Verwandt

Die Laufzeiten oben sind in UTC — der Zeitstempel-Konverter bringt jede davon in Ihre eigene Zeitzone oder in das Format, in dem Ihr Scheduler protokolliert. Geht es ums Treffen von Text statt ums Planen, ist der Regex-Tester nebenan.