Lösung von "invalid cron expression" und häufigen Cron-Syntaxfehlern: Ein kompletter Leitfaden

Cron ist das Standardwerkzeug zur Planung wiederkehrender Aufgaben auf Unix-ähnlichen Betriebssystemen. Ob Sie jede Nacht ein Datenbank-Backup erstellen oder jeden Montag einen Newsletter versenden – Cron ist der Motor im Hintergrund. Die „Fünf-Felder-Syntax“ (oder sechs Felder) kann jedoch verwirrend sein und zu Fehlern wie invalid cron expression (ungültiger Cron-Ausdruck), cron syntax error (Cron-Syntaxfehler) oder dem frustrierendsten von allen führen: cron job not running (Cron-Job wird nicht ausgeführt).

In diesem Leitfaden analysieren wir die Cron-Syntax und zeigen Ihnen, wie Sie häufige Planungsfehler beheben können.

1. Häufige Cron-Fehlermeldungen

Im Gegensatz zu einem Compiler gibt Cron nicht immer eine klare Fehlermeldung aus. Stattdessen sehen Sie möglicherweise:

Crontab-Validierung: crontab: installing new crontab, gefolgt von errors in crontab file, can't install (Fehler in der crontab-Datei, Installation nicht möglich).
Systemprotokolle: ORPHAN (no passwd entry) oder CMD (failed to execute).
Parsing-Bibliotheken: invalid cron expression, Unexpected end of expression oder Number out of range (Zahl außerhalb des Bereichs).

2. Hauptursachen und Lösungen

2.1 Die Verwechslung von „5 vs. 6 Feldern“

Standard-Linux-Cron (Vixie) verwendet 5 Felder: Minute Stunde Tag Monat Wochentag

Viele moderne Bibliotheken (wie Quartz in Java oder Node-Cron) und einige Systeme (wie AWS Lambda oder Spring) verwenden jedoch 6 Felder und fügen am Anfang Sekunden oder am Ende das Jahr hinzu.

Der Fehler: Verwendung eines 6-Felder-Ausdrucks in einer Standard-Linux-Crontab.

Die Lösung: Prüfen Sie die Dokumentation Ihrer Umgebung. Wenn Sie crontab -e unter Linux verwenden, nutzen Sie 5 Felder. Wenn Sie eine spezifische Bibliothek verwenden, prüfen Sie, ob diese Sekunden erwartet.

2.2 Bereichs- und Schrittfehler

Cron verwendet / für Schritte (z. B. */5 für alle 5 Einheiten) und - für Bereiche. Ein häufiger Fehler ist die Verwendung einer Zahl außerhalb des zulässigen Bereichs.

Der Fehler:

* * 31 2 * (Versuch, am 31. Februar auszuführen)
60 * * * * (Minute 60 ist ungültig; verwenden Sie 0-59)
* 24 * * * (Stunde 24 ist ungültig; verwenden Sie 0-23)

Die Lösung: Stellen Sie immer sicher, dass Ihre Zahlen innerhalb dieser Grenzen liegen:

Minuten: 0-59
Stunden: 0-23
Tag des Monats: 1-31
Monat: 1-12 (oder JAN-DEZ)
Wochentag: 0-6 (0 ist Sonntag, oder SUN-SAT)

2.3 Die Falle „Tag des Monats“ vs. „Wochentag“

Im Standard-Cron wird die Aufgabe ausgeführt, wenn eine der beiden Bedingungen erfüllt ist (OR-Logik), falls Sie sowohl einen „Tag des Monats“ als auch einen „Wochentag“ angeben. Es ist keine AND-Logik.

Der Fehler: 0 0 1 * 1 (Sie erwarten, dass es nur ausgeführt wird, wenn der 1. des Monats ein Montag ist, aber es wird tatsächlich an jedem 1. des Monats UND an jedem Montag ausgeführt).

Die Lösung: Um eine „AND“-Logik zu erreichen, müssen Sie eine Befehlsprüfung verwenden: 0 0 1 * * [ "$(date +\%u)" = "1" ] && /path/to/command

2.4 Umgebungsvariablen und Pfade

Ein sehr häufiger Grund dafür, dass ein „Cron nicht ausgeführt wird“, ist, dass Cron Befehle in einer sehr minimalen Umgebung ausführt. Ihr PATH könnte anders sein und Ihre .bashrc wird nicht geladen.

Das Symptom: Der Befehl funktioniert, wenn Sie ihn manuell ausführen, schlägt aber unter Cron fehl.

Die Lösung: Verwenden Sie immer absolute Pfade sowohl für den Befehl als auch für alle Dateien, die er berührt: /usr/bin/python3 /home/user/script.py >> /home/user/cron.log 2>&1

3. Fortgeschrittene Fehlerbehebung

3.1 Prozentzeichen (%) in Crontab

In einer Crontab-Datei hat das Prozentzeichen % eine spezielle Bedeutung (es steht für einen Zeilenumbruch). Wenn Ihr Befehl ein % enthält (häufig in date-Befehlen), müssen Sie es mit einem Backslash \% maskieren.

Der Fehler: 0 0 * * * tar -cvf backup-$(date +%Y-%m-%d).tar /data

Die Lösung: 0 0 * * * tar -cvf backup-$(date +\%Y-\%m-\%d).tar /data

3.2 Umleitung der Ausgabe

Wenn ein Cron-Job lautlos fehlschlägt, liegt das meist daran, dass die Ausgabe (stdout/stderr) an eine lokale Mail-Datei gesendet wird, die Sie nie prüfen. Lösung: Leiten Sie die Ausgabe immer in eine Protokolldatei um, um zu sehen, was schiefgelaufen ist: >> /var/log/myjob.log 2>&1.

4. Prävention und Best Practices

Nutzen Sie einen Parser/Generator: Raten Sie nicht. Verwenden Sie ein visuelles Tool, um genau zu sehen, wann Ihr Ausdruck ausgeführt wird.
Kommentieren Sie Ihre Jobs: Füge immer einen Kommentar über Ihrem Crontab-Eintrag hinzu, der erklärt, was er tut.
Verwenden Sie absolute Pfade: Wir können das nicht oft genug betonen. /usr/local/bin/node statt node.
Testen Sie mit „Jede Minute“: Wenn Sie einen Job zum ersten Mal einrichten, stellen Sie ihn auf * * * * *, um zu prüfen, ob er funktioniert, und ändern Sie ihn dann auf den tatsächlichen Zeitplan.

5. FAQ: Häufig gestellte Fragen

F: Steht 0 oder 7 für Sonntag?

A: In den meisten Cron-Implementierungen (wie Linux) stehen sowohl 0 als auch 7 für Sonntag. Einige verwenden jedoch strikt die 0. Die Verwendung von SUN ist oft klarer.

F: Wie führe ich eine Aufgabe alle 5 Minuten aus?

A: Verwenden Sie die Schritt-Syntax: */5 * * * *.

F: Warum wurde mein Cron-Job während der Zeitumstellung um 2 Uhr morgens nicht ausgeführt?

A: Dies ist ein klassisches Problem. Wenn die Uhr vor- oder zurückgestellt wird, können Jobs, die in dieser Stunde geplant sind, zweimal oder gar nicht ausgeführt werden. Lösung: Vermeiden Sie es, kritische Aufgaben zwischen 1 Uhr und 3 Uhr morgens zu planen, oder lassen Sie Ihren Server auf UTC-Zeit laufen.

6. Schnell-Check-Tool

Verwirrt von Sternchen und Schrägstrichen? Nutzen Sie unseren Cron-Ausdruck-Parser & Visualisierer. Er kann:

Cron-Syntax sofort übersetzen: In eine für Menschen lesbare Sprache.
Die nächsten 5 Ausführungszeiten berechnen.
Sowohl 5-Felder- als auch 6-Felder-Formate unterstützen.
Ihren Ausdruck validieren und Syntaxfehler hervorheben.

Lösung von 'invalid cron expression' und häufigen Cron-Syntaxfehlern