Cron-Ausdruck prüfen
Der Cron-Ausdruck-Parser erklärt einen Zeitplan in klaren Worten und listet seine nächsten zehn Ausführungen auf – in Ihrem Browser. Er nennt die Regel, an der fast alle straucheln: Sind sowohl Tag des Monats als auch Wochentag eingeschränkt, verodert cron die beiden – 0 0 13 * 5 läuft also am 13. oder an jedem Freitag, und nicht am Freitag, den 13.
Wie funktioniert Cron-Ausdruck prüfen?
Cron besteht aus fünf Zahlen und wird trotzdem verlässlich falsch gelesen. Fast alles davon geht auf drei Dinge zurück.
Die beiden Tagesfelder werden verodert, nicht geschnitten
Jedes andere Feldpaar wird geschnitten: 0 9 * 6 * ist neun Uhr im Juni, Stunde und Monat. Die Tagesfelder nicht. Sind sowohl Tag des Monats als auch Wochentag eingeschränkt, läuft der Job, wenn eines von beiden passt. 0 0 13 * 5 feuert also am 13. jedes Monats und an jedem Freitag – rund fünfmal im Monat, nicht ein- oder zweimal im Jahr. Das steht so in POSIX und im Handbuch von Vixie cron, und es überrascht Leute immer noch – deshalb sagt diese Erklärung es explizit, statt die Felder getrennt zu beschreiben.
Steht eines der beiden auf *, entscheidet das andere allein – deshalb ist 0 0 * * 5 schlicht jeder Freitag.
Die Berechnung des nächsten Laufs ist eine Suche, die enden muss
0 0 31 2 * verlangt Mitternacht am 31. Februar, was nie eintritt. Ein Scan von Minute zu Minute braucht 2.6 Millionen Iterationen, um an eine Einjahresgrenze zu stoßen und aufzugeben; ein Scan ohne Grenze gibt überhaupt nie auf. Die Suche hier springt um die größte Einheit weiter, die sie ausschließen kann – ein Monat, der nicht passt, springt zum Ersten des nächsten Monats statt durch seine Tage –, so ist ein unmöglicher Zeitplan in ein paar hundert Schritten als unmöglich bewiesen.
Alles hier läuft in UTC, und das ist Absicht
Ein Cronjob, der in einer Zone mit Sommerzeit geplant ist, läuft an einer Nacht im Jahr wirklich zweimal und an einer anderen gar nicht: Geht die Uhr zurück, passiert 01:30 zweimal; geht sie vor, passiert 02:30 nie. Verschiedene cron-Implementierungen handhaben das unterschiedlich, manche gar nicht. In UTC zu rechnen und das zu sagen ist ehrlich; stillschweigend die Zone Ihres Browsers anzuwenden erzeugte Zeiten, die souverän aussehen und zweimal im Jahr falsch sind.
Feldanzahlen und Dialekte
Fünf Felder sind Standard bei Unix-cron. Sechs bedeuten meist Sekunden zuerst, so machen es Quartz, Spring und node-cron – einige Scheduler setzen stattdessen ein Jahr ans Ende, was wirklich mehrdeutig ist und hier zugunsten der Sekunden aufgelöst wird. Sieben Felder sind Quartz mit beidem. Der Parser akzeptiert Monats- und Tagesnamen, überlaufende Bereiche wie FRI-MON und 22-2, ? als Platzhalter, sowohl 0 als auch 7 für Sonntag und die Familie der @daily-Kürzel.
@reboot wird erkannt und erklärt, statt geparst zu werden: Es hat keinen Zeitplan, also gibt es keinen nächsten Lauf zu berechnen.
Ausdruck
0 0 13 * 5
Erklärt
At 00:00, on day 13 of the month OR on Friday — cron ORs these two fields rather than intersecting them, so this is not "Friday the 13th". UTC.
Welche Optionen und Sonderfälle unterstützt Cron-Ausdruck prüfen?
| Parameter | Typ | Standard | Verhalten & Sonderfälle |
|---|---|---|---|
| * | Wildcard | jeder Wert | Im Tagesfeld bedeutet es auch 'lasst das andere Tagesfeld entscheiden', was die OR-Regel handhabbar macht. |
| */n | Schritt | — | Jeder n-te Wert ab dem Minimum des Feldes. */15 in Minuten ist 0, 15, 30, 45 – nicht 'alle 15 Minuten ab jetzt'. |
| a-b | Bereich | — | Inklusive. Ein umschließender Bereich wird akzeptiert: 22-2 in Stunden ist 22, 23, 0, 1, 2, und FRI-MON ist das Wochenende. |
| a,b,c | Liste | — | Eine beliebige Mischung aus Einzelwerten, Bereichen und Schritten, kommagetrennt. |
| n/m | Schritt ab n | — | 5/6 in Stunden ist 5, 11, 17, 23 – ab 5 bis zum Maximum, in Schritten von 6. |
| Namen | JAN-DEC, SONN-SAM | akzeptiert | Unabhängig von der Groß-/Kleinschreibung und in Bereichen verwendbar: JAN-MAR, MON-FRI. |
| 0 und 7 | Sonntag | beide | Jede Implementierung akzeptiert beide, und fast keine Dokumentation erwähnt sie an derselben Stelle wie etwas anderes. |
| ? | Wildcard | Quartz | Wird als * behandelt. Quartz verwendet es, um 'kein bestimmter Wert' in einem Tagesfeld zu bedeuten. |
| Anzahl Felder | 5, 6 oder 7 | 5 | Fünf ist Standard Unix. Sechs wird als Sekunden-gelesen-first, was Quartz, Spring und node-cron meinen. Sieben ist Quartz mit einem Jahr. |
| @daily und ähnliche | Abkürzung | erweitert | @yearly @annually @monthly @weekly @daily @midnight @hourly. @reboot hat keinen Zeitplan und wird erklärt, nicht geparst. |
| Zeitzone | UTC | immer | Ein lokaler Zeitplan läuft tatsächlich zweimal in einer Nacht im Jahr und gar nicht an einer anderen. Die Berechnung in UTC und die Angabe dessen schlägt die Erzeugung von falschen lokalen Zeiten. |
Häufig gestellte Fragen
Läuft 0 0 13 * 5 am Freitag, den 13.?
Nein – es läuft am 13. jedes Monats und an jedem Freitag. Cron verodert die beiden Tagesfelder, statt sie zu schneiden; das ist das Gegenteil von dem, was jedes andere Feldpaar tut, und das mit Abstand häufigste Cron-Missverständnis. Speziell für Freitag, den 13., brauchen Sie eine Einschränkung auf den Tag des Monats plus eine Prüfung im Job selbst; die Schnittmenge kann cron nicht ausdrücken.
Was bedeutet */15 wirklich?
Jeder Wert, der durch 15 teilbar ist, innerhalb des Felds, beginnend beim Minimum des Felds – in Minuten also 0, 15, 30 und 45. Es heißt nicht „alle fünfzehn Minuten ab dem Deployment“. Dieser Unterschied zählt, wenn Sie ihn mit einer Stunden-Einschränkung kombinieren: 0 */2 * * * läuft um 00:00, 02:00, 04:00 und so weiter, nicht zwei Stunden nach dem jeweiligen vorherigen Lauf.
Warum sind alle Zeiten UTC?
Weil ein Zeitplan in lokaler Zeit zweimal im Jahr wirklich mehrdeutig ist. Geht die Uhr zurück, tritt 01:30 zweimal auf, und manche Implementierungen lassen den Job zweimal laufen; geht sie vor, tritt 02:30 nicht auf, und manche überspringen ihn komplett. Das Verhalten unterscheidet sich von cron-Implementierung zu cron-Implementierung. UTC zu zeigen und das zu sagen ist ehrlich; stillschweigend die Zone Ihres Browsers anzuwenden erzeugte souverän aussehende Zeiten, die an zwei Tagen im Jahr falsch sind.
Fünf, sechs oder sieben Felder?
Fünf für Unix-cron, crontab und die meisten CI-Scheduler. Sechs für Quartz, Springs @Scheduled und node-cron, wo das zusätzliche Feld zuerst steht und die Sekunden sind. Sieben für Quartz mit einem Jahr am Ende. Sechs Felder sind wirklich mehrdeutig – einige Scheduler setzen das Jahr stattdessen ans Ende –, und dieser Parser liest sie als Sekunden-zuerst, was deutlich verbreiteter ist.
Warum zeigt mein Ausdruck keine Läufe?
Er kann nie feuern. Übliche Ursache ist eine Kombination aus Tag des Monats und Monat, die nicht existiert – 0 0 31 2 * verlangt den 31. Februar –, oder eine Jahres-Einschränkung, die bereits vergangen ist. Die Suche schaut fünf Jahre voraus, bevor sie das feststellt; eine leere Liste bedeutet also wirklich unmöglich und nicht bloß weit entfernt.
Wird mein Ausdruck hochgeladen?
Nein. Parsen und die Suche nach dem nächsten Lauf laufen beide in Ihrem Browser. Ein Cron-Ausdruck ist kein Geheimnis, aber er beschreibt den Rhythmus Ihrer Infrastruktur, und dafür gibt es keinen Grund, ihn an einen Server zu schicken, der nichts damit anfangen kann.