Cron-Ausdrücke: die fünf Felder, mit Beispielen

Die fünf Felder

Jede standardmäßige Unix-Cron-Zeile beginnt mit denselben fünf Feldern, gefolgt vom auszuführenden Befehl.

* * * * *  command to run
| | | | |
| | | | +-- day of week  (0-7, 0 and 7 both mean Sunday, or SUN-SAT)
| | | +---- month        (1-12, or JAN-DEC)
| | +------ day of month (1-31)
| +-------- hour         (0-23)
+---------- minute       (0-59)

Ein Feld enthält eine von vier Sachen: einen Stern für jeden Wert, eine einzelne Zahl, eine Liste oder einen Bereich. Stunden folgen einer 24-Stunden-Uhr ohne AM oder PM, 18 Uhr ist also 18. Sonntag ist sowohl 0 als auch 7, weil verschiedene Systeme historisch unterschiedlicher Meinung waren, und cron akzeptiert beides.

Manche Scheduler fügen weitere Felder hinzu. Quartz, das von vielen Java-Frameworks verwendet wird, stellt ein Sekundenfeld voran und hängt optional ein Jahr an, sodass ein sechs- oder siebenfeldiger, aus einer Quartz-Referenz kopierter Ausdruck in einer Linux-Crontab nicht funktioniert. Prüfen Sie, für welche Variante Sie schreiben, bevor Sie einen Ausdruck irgendwoher kopieren.

Die Sonderzeichen

• * passt auf jeden Wert im Feld. * * * * * läuft jede Minute.
• , listet Werte auf. 0 8,13,20 * * * läuft um 08:00, 13:00 und 20:00 Uhr.
• - gibt einen Bereich an. 0 9-17 * * * läuft stündlich von 09:00 bis 17:00 Uhr.
• / geht in Schritten durch einen Bereich. */15 * * * * läuft bei Minute 0, 15, 30 und 45. Sie können es mit einem Bereich kombinieren: 0 9-17/2 * * * läuft um 9, 11, 13, 15 und 17 Uhr.
• Namen. MON bis SUN und JAN bis DEC funktionieren in den letzten beiden Feldern und lesen sich besser als Zahlen. Sie können nicht innerhalb eines Schritts verwendet werden.

Vier weitere Zeichen tauchen ständig in Tutorials auf und existieren im Standard-Cron nicht. L für den letzten Tag, W für den nächstgelegenen Werktag, # für den n-ten Wochentag des Monats und ? anstelle eines Sterns sind Quartz-Erweiterungen. Ein Ausdruck wie 0 0 L * * wird von einer Linux-Crontab abgelehnt. Um dort etwas am letzten Tag des Monats auszuführen, lassen Sie es täglich laufen und den Befehl selbst entscheiden:

0 0 * * * [ "$(date -d tomorrow +\%d)" = "01" ] && /usr/local/bin/month-end.sh

Beachten Sie die Backslashes in dieser Zeile. Ein Prozentzeichen hat in einer Crontab eine besondere Bedeutung, das ist der fünfte Fehler weiter unten.

Cron akzeptiert außerdem sechs Kurzschreibweisen anstelle aller fünf Felder: @yearly (auch @annually), @monthly, @weekly, @daily (auch @midnight), @hourly und @reboot, das einmalig beim Start von cron läuft statt nach der Uhr. @reboot wird nicht überall unterstützt.

Gängige Zeitpläne

Fehler, die den Job zur falschen Zeit auslösen

1. Beide Tagesfelder ausfüllen. Das ist der Fehler, der jedem passiert. Sind Tag des Monats und Wochentag beide auf etwas anderes als einen Stern gesetzt, führt cron den Job aus, sobald eines von beiden zutrifft, nicht beide zusammen. 0 0 13 * FRI läuft an jedem 13. und an jedem Freitag, nicht nur an Freitag, dem 13.
2. Ein Schritt, der den Bereich nicht teilt. */7 * * * * feuert bei Minute 0, 7, 14, 21, 28, 35, 42, 49 und 56 und beginnt dann wieder bei 0. Die Lücke über die Stundengrenze hinweg beträgt vier Minuten, nicht sieben. Dieselbe Falle gilt für */40 im Minutenfeld und jeden Schritt, der kein Teiler von 60 ist.
3. Den Schritt im falschen Feld platzieren. */2 * * * * bedeutet alle zwei Minuten. 0 */2 * * * bedeutet alle zwei Stunden. Die führende 0 wegzulassen macht aus einem stündlichen Job einen, der 30-mal so oft läuft.
4. Die Umgebung als gegeben annehmen. Cron gibt dem Job eine minimale Umgebung, meist kaum mehr als PATH=/usr/bin:/bin und SHELL=/bin/sh. Ein Skript, das in Ihrer Shell funktioniert, scheitert in cron, weil es etwas unter /usr/local/bin aufruft. Verwenden Sie absolute Pfade für den Befehl und darin.
5. Ein nicht maskiertes Prozentzeichen. In einer Crontab wird % in einen Zeilenumbruch umgewandelt, und alles nach dem ersten wird dem Befehl als Standardeingabe zugeführt. Ein date +%Y-%m-%d in einer Crontab-Zeile muss als date +\%Y-\%m-\%d geschrieben werden.
6. Die Ausgabe ignorieren. Alles, was der Job ausgibt, wird an den Crontab-Besitzer gemailt, und auf einer Maschine ohne konfigurierten Mailversand geht es verloren. Schicken Sie es dorthin, wo Sie es lesen: 0 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1
7. Durchläufe überlappen lassen. Cron startet den nächsten Durchlauf planmäßig, egal ob der letzte fertig ist oder nicht. Umhüllen Sie lange Jobs mit einer Sperre: */5 * * * * flock -n /tmp/sync.lock /usr/local/bin/sync.sh
8. Die Zeitumstellung vergessen. Cron verwendet die lokale Zeit der Maschine. An den Tagen, an denen die Uhr umgestellt wird, existiert die Stunde um 02:00 Uhr entweder nicht oder tritt zweimal auf, sodass ein Job, der genau dorthin fällt, je nach Cron-Implementierung ausfallen oder doppelt laufen kann. Stellen Sie Server auf UTC, oder legen Sie den Zeitplan außerhalb dieses Fensters.
9. crontab -r tippen. Das löscht die gesamte Crontab ohne Bestätigung, und der Befehl liegt nur eine Taste von crontab -e entfernt. Halten Sie die Crontab in der Versionsverwaltung und installieren Sie sie aus einer Datei.

Von außen prüfen

Ein Ausdruck, der sich fehlerfrei parsen lässt, ist nicht dasselbe wie ein Job, der tatsächlich gelaufen ist. Prüfen Sie beides, auf der Maschine und dann von außerhalb.

Bestätigen Sie auf der Maschine, was installiert ist, was die Uhr sagt, und ob cron den Job gestartet hat:

crontab -l
timedatectl
grep CRON /var/log/syslog | tail -20
journalctl -u cron -u crond --since "2 hours ago"

Die Protokollzeile belegt, dass cron den Befehl gestartet hat. Sie sagt nichts darüber aus, ob der Befehl erfolgreich war, weshalb die Umleitung in eine Protokolldatei bei den Fehlern oben wichtig ist.

Prüfen Sie das Ergebnis anschließend so, wie es ein Nutzer täte, von außerhalb des Servers. Die meisten geplanten Jobs existieren, um etwas Beobachtbares zu ändern: einen Feed, der das heutige Datum tragen sollte, eine Sitemap, die neu geschrieben worden sein sollte, einen Export, der erschienen sein sollte. Fragen Sie ihn ab und lesen Sie die Header:

curl -sI https://example.com/exports/daily.json
curl -s https://example.com/health/last-run

Der Header Last-Modified sagt Ihnen, ob die Datei aktuell ist, und das ganz ohne Shell-Zugriff. Dieselbe Anfrage von mehreren Standorten aus mit der HTTP-Prüfung auszuführen, unterscheidet einen Job, der nicht gelaufen ist, von einer Seite, die an einem Edge-Standort in einer Region gecacht und nur dort veraltet ist. Dieser Unterschied ist von einem einzelnen curl auf dem Server selbst aus nicht zu erkennen.

Erkennen, wann ein geplanter Job aufhört zu laufen

Ein Cron-Job, der aufhört zu laufen, erzeugt nichts, das auffällt. Es gibt keine Fehlerseite und keine fehlgeschlagene Anfrage, also löst nichts einen Alarm aus, sofern nicht etwas auf genau diese Abwesenheit achtet. Was Sie überwachen, ist die Wirkung des Jobs, nicht der Job selbst: eine Statusdatei, die er neu schreibt, ein Zeitstempel, den er veröffentlicht, ein Endpunkt, der seinen letzten erfolgreichen Lauf meldet. Eine geplante Prüfung gegen diesen Endpunkt macht aus einem stillen Fehlschlag eine Benachrichtigung, und HostTracker verschickt diese per E-Mail, SMS, Sprachanruf, Slack, Telegram und mehr über 13 Monitortypen hinweg. Wie Sie das einrichten, steht in der Anleitung zur HTTP-Prüfung, die übrigen Anleitungen zur Problemlösung finden Sie im Bereich Problemlösung, und die vollständige Liste der Prüfungstypen steht auf der Funktionsseite.