Der teuerste Cron-Ausdruck, den ich je geschrieben habe, war 0 0 * * 0drohen Es wurde eine wöchentliche Digest-E-Mail für eine Laravel-SaaS-Mail ausgeführt, die ich gebaut habe, und ich war mir absolut sicher, dass dies am letzten Tag der Woche "Mitternacht" bedeutete. "Es bedeutet Mitternachtssonntag. Mein mentales Modell sagte, die Woche endete am Samstag. Fünf Wochen lang erhielten die Kunden ihre "Woche im Test" einen Tag zu spät, und niemand im Team fing sie auf, weil auch niemand im Team Cron lesen konnte - wir alle schielten nur auf den fünf Feldern und nickten.
Das ist das schmutzige Geheimnis der Cron-Syntax: Fast jeder, der es schreibt, entspricht dem Muster, das einem früheren Ausdruck entspricht, an den er sich halb erinnert. Das Format ist mehr als vierzig Jahre alt, dicht genug, dass ein einzelner Charakter den Zeitplan vollständig ändert und stumm scheitert. Es gibt keinen Compilerfehler für "Lauft am falschen Tag". Der Job läuft nur am falschen Tag, für immer, bis jemand es bemerkt.
ein Cron-Expression-Parser schließt diese Lücke. Sie fügen den Ausdruck ein und er sagt Ihnen auf Englisch, was tatsächlich passieren wird - 0 0 * * 0 Kommt als "um 00:00 Uhr, am Sonntag" zurück - plus wenn der nächste Läufe feuert. Dieser Rückleseschritt ist der Unterschied zwischen dem Versand eines Zeitplans und dem Versand einer Vermutung. Ich habe das auf toolz.dev gebaut, weil ich es satt hatte, das Kontext-Wechselprogramm zu einem Terminal zu wechseln, und weil das WP-Cron-Ungefährt, mit dem ich mich jahrelang in der WP-Administration befasst habe, mir beigebracht hat, dass die Planungsfehler die geduldigen Fehler in der Software sind.
Dieser Leitfaden beschreibt die Verwendung des Parsers, wie die fünf Felder tatsächlich funktionieren (einschließlich der beiden Macken, die die meisten Produktionsvorfälle verursachen) und wo sich die Cron-Syntax zwischen den Crontab-, GitHub-Aktionen, Quarz und Laravel unterscheidet.
tl; dr: Fügen Sie einen beliebigen Crontab-Ausdruck in die toolz.dev cron Parser Und erhalten Sie eine einfache Übersetzung und kommen Sie auf die kommenden Laufzeiten – clientseitig, keine Anmeldung. Bevor Sie einen Zeitplan bereitstellen, überprüfen Sie immer zwei Dinge: die Wochentag-Nummerierung (0 und 7 sind beide Sonntag) und die Zeitzone, in der der Scheduler ausgeführt wird (GitHub-Aktionen ist immer UTC). Kombiniere es mit dem Zeitstempelkonverter Wenn Sie diese Next-Run-Zeiten über Zonen hinweg übersetzen müssen, und die Datumsdifferenzrechner zu den Vernunft-Check-Intervallen.
Hauptmerkmale
Deutsch-Englisch-Übersetzung
Die Kernaufgabe des Parsers ist das Drehen */15 9-17 * * 1-5 In "jede 15. Minute nach Stunde 9, 10, 11, 12, 13, 14, 15, 16 und 17, Montag, Dienstag, Mittwoch, Donnerstag und Freitag." Die Aufzählung ist eindeutig, eine zusammengefasste Reichweite ist eine weitere Chance, falsch zu lesen. Der Satz ist etwas, das Sie in eine Pull-Anforderungsbeschreibung einfügen, in einem Standup vorlesen oder einen nicht-technischen Stakeholder anzeigen können. Der rohe Ausdruck ist nicht. Nach meiner Erfahrung ist die Übersetzung während der Codeüberprüfung am wichtigsten: Ein Rezensent, der fünf kryptische Felder stempeln würde, wird sofort "warten, warum erscheint Stunde 17, wenn der Job um 17 Uhr aufhören soll?" ", Wenn jede Stunde ausgeschrieben ist. Die Übersetzung macht den Zeitplan falsifizierbar, genau das ist die RAW-Cron-Syntax.
Nächste Vorschau ausführen
Wissen, was ein Ausdruck Mittel ist das halbe Problem; zu wissen, wann es Feuer als nächstes ist die andere Hälfte. Der Parser berechnet die nächsten fünf Ausführungszeiten, damit Sie sie gegen Ihre Absicht betrachten können. Hier tauchen subtile Fehler auf - ein Ausdruck, der auf Englisch gut gelesen wird, aber einen nächsten Lauf von "in 27 Tagen" hervorbringt, weil Sie den Monatstag mit dem Monat verwechselt haben oder der heute Abend um 03:00 Uhr feuert, als Sie nach dem Wochenende 03:00 Uhr meinten. Ich überprüfe jetzt jedes Mal die nächste Laufliste, auch für Ausdrücke, bei denen ich zuversichtlich bin. Besonders für Ausdrücke bin ich zuversichtlich - siehe die Eröffnungsanekdote.
Zwei Details darüber, wie diese Zeiten berechnet werden. Zunächst werden sie bewertet Die lokale Zeitzone Ihres Browsers, nicht UTC und nicht die Zone Ihres Servers - jeder Lauf wird zweimal angezeigt, einmal als lokaler Zeitstempel und einmal als äquivalenter UTC-Instant, sodass Sie die passende Datei für Ihr Bereitstellungsziel lesen können. Zweitens, wenn sowohl der Monatstag als auch der Wochentag eingeschränkt sind, wendet der Parser eher echte Crone oder Semantik an als und: 0 0 1 * 1 Feuer am 1. des Monats und Jeden Montag, nicht nur montags, der am 1. Diese Regel stößt erfahrene Menschen auf, und wenn man fünf konkrete Daten sieht, wird dies offensichtlich, dass der Satz niemals tut.
Eine raue Kante: ein unmöglicher Ausdruck wie 0 0 30 2 * (30. Februar) parsiert sich als gültig, beschreibt sich glücklich als "um 00:00 Uhr, am 30. Februar, im Februar" und zeigt dann eine leere Liste der nächsten Läufe an. Leer bedeutet nie. Es ist richtig, aber es ist leise - ein "Dieser Zeitplan wird niemals ausgelöst" Warnung ist die offensichtliche Verbesserung und ich habe es noch nicht gebaut.
Aufschlüsselung von Feld zu Feld
Der Parser teilt den Ausdruck in seine fünf Komponenten auf – Minute, Stunde, Monat, Monat, Monat, Wochentag – und zeigt, was jeder beiträgt. Dies ist wichtig, da Cron-Fehler fast immer ein Einzelfeldproblem sind: der richtige Wert in der falschen Spalte. 0 12 * * * (mittags) und 12 0 * * * (12:12 Uhr täglich... Nein, 00:12 täglich) sind einen Tausch auseinander. Wenn Sie "Stunde: 0" explizit beschriftet sehen, können Sie diesen Tausch in zwei Sekunden statt in zwei Wochen abfangen.
Unterstützung für Bereiche, Schritte und Listen
Real-World-Ausdrücke lehnen sich an die Operator-Syntax an: 1-5 Bereiche, */10 Schritte, 1,15 Listen und Kombinationen wie 0 8-18/2 * * 1,3,5drohen Der Parser erledigt alles, einschließlich der kombinierten Formen, die menschliche Leser auflösen. Schrittwerte über Bereiche — 8-18/2 Bedeutung "Alle 2 Stunden von 8 bis 18" - sind legal, nützlich und ohne Werkzeug fast unlesbar. Wenn Sie jemals eine davon voll von einem verstorbenen Systemadministrator geerbt haben, wissen Sie, warum diese Funktion existiert.
Strenge Fünf-Feld-Validierung (einschließlich der nicht akzeptierten)
Der Parser nimmt Standard-5-Feld-Ausdrücke und sonst nichts. einkleistern @daily Und Sie erhalten einen Fehler - "Erwartete 5 Felder (Minuten-Stunde-Monat-Monat-Tag-Woche), 1" - keine Übersetzung. Gleich für @hourly, @weekly, und @rebootdrohen Das ist eher eine echte Lücke als ein Designprinzip, und ich würde es eher sagen, als dass Sie dies mitten in der Debug herausfinden lassen; die Kurzschriftmakros sind in echten Crontabs so häufig, dass sie in das Werkzeug gehören. Bis sie ein sind, übersetzen Sie manuell: @hourly ist 0 * * * *, @daily ist 0 0 * * *, @weekly ist 0 0 * * 0, @monthly ist 0 0 1 * *, @yearly ist 0 0 1 1 *drohen @reboot Hat überhaupt kein Fünf-Felder-Äquivalent - es ist kein Zeitplan, es läuft einmal beim Daemon-Startup, was viele Leute überrascht hat, die Migrationen von Crontab durchführen.
Die Strenge zahlt sich an anderer Stelle aus. Ein Sechs-Feld-Quarzausdruck wird mit einer Feldzählung abgelehnt, anstatt still fehlzulesen. Werte außerhalb des Bereichs Benennen Sie das Feld und den rechtlichen Bereich (Value 25 out of range for hour (allowed 0-23)).). Umgekehrte Bereiche wie 5-1 werden gefangen. Und es akzeptiert die Dinge, die echte Crontabs enthalten: Monats- und Tagnamen (JAN, SUN) 7 als zweite Schreibweise des Sonntags und der Vixie 5/15 Form Bedeutung "Jeder 15 ab 5" ; Wissenswertes während Sie diese Makros von Hand übersetzen: @daily Der Job auf einem Server wird gleichzeitig ausgelöst - Mitternacht - also sind vierzig von ihnen ein nächtlicher Ladespitzensprung. Ich verstreue meine über ungerade Minuten (17 3 * * *, 43 4 * * *) aus genau diesem Grund.
Clientseitige Verarbeitung
Der Parser läuft komplett in Ihrem Browser. Nichts, das Sie einfügen, wird hochgeladen, protokolliert oder gespeichert. Das klingt nach Boilerplate-Datenschutzsprache, bis Sie sich daran erinnern, was Crontabs tatsächlich enthalten: Ihren Sicherungsplan, Ihr Abrechnungs-Timing, genau die Minute, in der Ihre Sicherheit Feuer scannt. Infrastrukturplanung sind Aufklärungsdaten. Es ist nicht Paranoia, es von anderen Leuten fernzuhalten, es ist einfach kein Problem, bei dem keiner existieren muss.
Wie man den Cron-Parser verwendet
Schritt 1: Fügen Sie Ihren Ausdruck ein oder geben Sie ihn ein
Öffne das Cron Parser und sinken Sie den Ausdruck - aus einer crontab-Datei, a schedule: Blockieren Sie in einem GitHub-Aktions-Workflow, einem Kubernetes-Cronjob-Manifest oder einem Laravel ->cron() rufen Die Standardsyntax mit fünf Feldern funktioniert wie sie ist; @daily Und seine Geschwister tun dies nicht, erweitern Sie diese also zuerst auf fünf Felder. Dann klicke auf Parse. Wenn Sie von vorne angefangen haben, anstatt zu dekodieren, können die voreingestellten Schaltflächen (jede Minute, stündlich, täglich um Mitternacht, Wochentags 9 Uhr, 1. Monat) einen Arbeitsausdruck laden, den Sie Feld für Feld ändern und während Sie erneut analysieren.
Schritt 2: Lesen Sie die Übersetzung zurück
Dies ist der Schritt, den die Leute überspringen und nicht. Lesen Sie die englische Ausgabe und vergleichen Sie sie mit dem Satz in Ihrem Kopf. Wenn Sie den Ausdruck "Jeden Montag um 9 Uhr" geschrieben haben und die Rücklesung "am 1. Monatstag 1" sagt -, haben Sie gerade den klassischen Kolumnentausch vor der Produktion gesehen. Die Rücklesung ist Ihr Unit-Test.
Schritt 3: Überprüfen Sie die nächsten Laufzeiten
Überprüfen Sie die fünf anstehenden Hinrichtungen. Landen die Daten dort, wo Sie erwarten? Ist der erste Lauf heute Abend, morgen oder nächsten Monat? Achten Sie auf die Lücke zwischen den Läufen - ein falscher Platz */ Schritt verwandelt "alle 6 Stunden" in "jede Minute jeder 6. Stunde" (* */6 * * * Vs 0 */6 * * *), und fünf Läufe eine Minute voneinander statt sechs Stunden auseinander ist schwer zu übersehen. Eine leere Liste bedeutet, dass der Zeitplan niemals ausgelöst werden kann.
Schritt 4: Zeitzone vor der Bereitstellung berücksichtigen
Der Parser sagt es dir wenn relativ zu einer Uhr; Ihr Scheduler entscheidet deren Uhr Überprüfen Sie vor der Bereitstellung, welche Zeitzone das ausführende System verwendet. GitHub-Aktionen: Immer UTC, keine Ausnahmen. Server: Was auch immer das Betriebssystem eingestellt ist, häufig UTC in Cloud-Boxen. Laravel: Ihre App-Zeitzone, es sei denn, Sie verketten ->timezone()drohen Übersetzen Sie eine nächste Laufzeit durch die Zeitstempelkonverter Wenn Sie es in Ihrer lokalen Zone oder einem Kunden sehen müssen.
Technical Deep Dive: Wie Cron-Ausdrücke tatsächlich funktionieren
Das Fünf-Feld-Format stammt von Unix Cron, standardisiert von Paul Vixie's Cron-Implementierung Ende der 1980er Jahre - das in dokumentierte in crontab(5) Und immer noch in nachkommender Form auf den meisten Linux-Systemen heute. Die Felder, von links nach rechts:
| Feld | Zulässige Werte | Notizen |
|---|---|---|
| minuti | 0–59 | |
| Stunde | 0–23 | 24-Stunden-Uhr, 0 ist Mitternacht |
| Tag des Monats | 1–31 | Hüten Sie sich Monate ohne 31. |
| Monat | 1–12 oder Jan–Dez | Namen in Vixie Cron erlaubt |
| Wochentag | 0–7 oder So-Sa | 0 und 7 sind beide Sonntag |
Jedes Feld akzeptiert * (jeder Wert), Listen (1,15), Bereiche (1-5) und Schritte (*/10 oder 20-59/5).). Das ist die ganze Grammatik. Die Komplexität liegt in der Syntax - es ist in drei Verhaltensfehlern.
Quirk One: Der Wochentag Null. per crontab(5), 0 und 7 bedeuten Sonntag. Einige ältere oder strengere Implementierungen akzeptieren nur 0. Quarz — Der von Jenkins verwendete Java-Scheduler und die Hälfte der Unternehmenssoftware — Zahlentage 1–7 ab Sonntags-, also Quarz 2 ist Montag, während Crontab 2 ist Dienstag. Wenn Sie jemals Zeitpläne zwischen Systemen migrieren, lauert diese Off-by-One. Immer analysieren, niemals transkribieren.
Quirk Two: Monatstag oder Wochentag. Hier ist derjenige, den fast niemand kennt, bis er sie beißt. wenn beide Die Felder für den Monatstag und die Wochentags sind eingeschränkt (wender *), Vixie Cron führt den Job, wenn entweder Streichhölzer - ein oder, nicht ein und. so 0 0 13 * 5 bedeutet nicht "Freitag, den 13.". Es bedeutet "jeden 13. des Monats und jeden Freitag." Dies ist dokumentiertes Verhalten in crontab(5) Und es ist zutiefst kontraintuitiv. Wenn Sie wirklich "Freitag, den 13." benötigen, benötigen Sie eine skriptseitige Datumsprüfung oder einen Scheduler mit einer reicheren Syntax.
Quirk drei: Zeitzonen und DST. Cron hat kein Zeitzonenfeld. Der Ausdruck wird in der Ortszeit des Schedulers interpretiert, was auch immer das ist. Zwei konkrete Konsequenzen:
- GitHub-Aktionen läuft
schedule:Trigger in UTC, Punkt. Ein Workflow unter geplant0 9 * * *Feuert um 9 Uhr UTC - 4 oder 5 Uhr in New York, je nach Saison, da UTC nicht die Sommerzeit beobachtet, aber die Uhr Ihres beabsichtigten Publikums. Ihr "9-Morgen-Tag" treibt zweimal im Jahr um eine Stunde, es sei denn, Sie passen den Workflow an oder bearbeiten ihn im Code. - Auf Servern, die auf eine DST-Beobachtungszone eingestellt sind, gibt es eine Nacht im Jahr die 02:00–03:00 Uhr nicht und eine Nacht passiert es zweimal. Ein um 02:30 Uhr geplanter Job überspringt oder löst je nach Implementierung entweder aus. Die langweilige, korrekte Lösung: Planen Sie kritische Jobs außerhalb von 01:00–03:00 local oder führen Sie Server auf UTC aus. Ich mache beides.
erweiterte Formate. Quarz verwendet sechs oder sieben Felder (ein führendes Sekundenfeld und ein optionales Nachfolgejahr), plus zusätzliche Operatoren wie L (letzter), W (nächster Wochentag) und # (nter Wochentag des Monats). Einige Crons unterstützen auch ein Feld für führende Sekunden. Wenn Ihr Ausdruck sechs Felder hat und Sie sich nicht sicher sind, um welchen Dialekt es sich handelt, fügen Sie ihn in den Parser ein. Ein Ausdruck mit sechs Feldern, der als Fünf-Felder interpretiert wird, erzeugt eine sichtbar falsche Ausgabe, die selbst diagnostisch ist. und @reboot, die seltsame Ente der Sondersaiten, ist kein Zeitplan: Sie läuft einmal beim Daemon-Start, was auf modernen Systemen "wenn die Box neu startet", eine Tatsache, die viele Leute von Crontab überrascht hat.
Für eine umfassendere Tour durch die Entwickler-Utilities, die mit der Planungsarbeit kombiniert werden, ist die Anleitung für die Coding-Tools Deckt die gesamte Werkzeugkiste ab.
Häufige Anwendungsfälle
Debuggen eines Laravel-Scheduler-Eintrags
Laravels Scheduler wraps Cron in fließende Methoden — ->dailyAt('03:00'), ->weeklyOn(1, '8:00') - aber die Fluchtschlüpfe, ->cron('*/5 * * * 1-5'), ist rohe Crontab-Syntax, und komplizierte Zeitpläne landen dort. Das System crontab läuft schedule:run Jede Minute entscheidet Laravel intern, was fällig ist. Wenn ein geplanter Befehl nicht ausgelöst wird, ist mein erster Schritt das Einfügen des ->cron() String in den Parser, um zu bestätigen, dass es bedeutet, was der obige Kommentar behauptet. Etwa die Hälfte der Zeit ist es nicht. Die andere Hälfte, der Fehler ist Zeitzone: Die App ist auf UTC Während der Entwickler die Ortszeit übernahm. Der Parser löst den ersten Fall in Sekunden und zeigt mit einem Finger auf den zweiten.
Entwirren von WP-Cron auf WordPress-Sites
WordPress wird mit WP-Cron geliefert, was überhaupt nicht gelungen ist - es ist ein Pseudo-Scheduler, der auf Seitenbesuchen huckepacket, so dass ein verkehrsarmer Standort "Stunden" alle vier Stunden läuft, und eine Website mit hohem Verkehrsaufkommen zahlt für jede Anfrage eine kleine Steuer. Während meiner WP-Administrationsjahre wurde ein stetiger Strom von "geplanten Beiträgen"-Berichten erzeugt. Der Standard-Fix ist das Deaktivieren von wp-cron (DISABLE_WP_CRON) und auslösen wp-cron.php Von einem echten Server-Crontab - an diesem Punkt schreiben Sie normalerweise tatsächliche Cron-Ausdrücke */5 * * * *, und der Parser verdient seine ständige Überprüfung. Wenn Sie WordPress in jedem Maßstab ausführen, lohnt sich diese Migration diese Woche, nicht eines Tages.
Überprüfen der Zeitpläne von GitHub-Aktionen
CI-Zeitpläne scheitern leise: Ein nächtlicher Build, der nicht mehr läuft, blättert nicht auf. Beim Schreiben a schedule: Trigger, ich parse den Ausdruck, schaue auf die nächsten Laufzeiten und addiere dann mental den UTC-Offset. Zwei zusätzliche Details zu Aktionen: Zeitpläne werden nur auf der Standard-Zweigstelle ausgeführt, und Läufe können während der Hochlastperioden verzögert oder gelöscht werden - die eigenen Dokumente von GitHub. Wenn das genaue Timing wichtig ist, sind cron-ausgelöste Aktionen das falsche Werkzeug; wenn das ungefähre Timing in Ordnung ist, mindestens die ungefähre Zeit einzustellen recht ungefähre Zeit.
Auditing einer geerbten Crontab
Jeder langlebige Server sammelt eine Crontab, die von Menschen geschrieben wurde, die dort nicht mehr arbeiten. Laufen crontab -l Das Einfügen jeder Zeile durch den Parser ist das schnellste Audit, das ich kenne: Innerhalb von zehn Minuten haben Sie ein Inventar mit reinem englischen Zeitplan, und Sie werden fast immer mindestens einen Job finden, an den sich niemand erinnerte - ein Backup, das zweimal ausgeführt wurde, ein Bereinigungsskript, das nie dem Tag entspricht, an dem es eigentlich sollte, ein * * * * * das hätte sein sollen 0 * * * * 60 Mal pro Stunde eine API hämmern. Beim Vergleich einer alten Crontab mit einer neuen während einer Migration wird die Text-Diff-Tool Neben dem Parser macht die Bewertung mechanisch.
Planen von Kubernetes Cronjobs
K8S Cronjobs verwenden die Standard-5-Feld-Syntax und unterstützen seit 1.27 eine explizite timeZone Field - Eine echte Verbesserung gegenüber klassischem Cron. Der Parser-Workflow ist der gleiche: Überprüfen Sie den Ausdruck, überprüfen Sie die nächste Ausführung und bestätigen Sie startingDeadlineSeconds und concurrencyPolicy Decken Sie die Fehlermodi selbst ab. Ein Ausdruck kann perfekt sein und der Job wird immer noch angehäuft, wenn ein langsamer Lauf den nächsten Auslöser überlappt; der Parser erhält den richtigen Zeitplan, sodass Sie stattdessen Ihre Aufmerksamkeit auf diese Betriebseinstellungen richten können.
Cron-Dialekte verglichen
| Vixie Cron / Crontab | GitHub-Aktionen | Quarz | Laravel-Scheduler | System-Timer | |
|---|---|---|---|---|---|
| Felder | 5 | 5 | 6–7 (Sekunden, Jahr) | 5 (über ->cron()) |
OnCalendar Syntax, nicht cron |
| Nummerierung der Woche | 0–7 (0 und 7 = Sonne) | 0–6 (0 = Sonne) | 1–7 (1 = Sonne) | folgt crontab | Namen (Mon, Tue) |
| Zeitzone | System lokal | Immer UTC | konfigurierbar | App-Zeitzone oder ->timezone() |
System lokal oder Timezone= |
| Sondersaiten | @daily, @reboot, usw. |
Nicht unterstützt | Nicht unterstützt | fließende Methoden stattdessen | OnBootSec=, Kalender-Kurzzettel |
| Sekunden Präzision | kein | Nein (min ~ 5 min praktisch) | ja | Nein (Tick pro Minute) | ja |
| am besten für | Serverjobs | CI/CD-Zeitpläne | JVM-Ökosysteme | Laravel-Apps | Moderne Linux-Dienste |
Wann verwenden: Crontab für einfache Server-Jobs, System-Timer Wenn Sie die Protokollierung und die Abhängigkeitsbehandlung unter modernem Linux kostenlos bearbeiten möchten, der Framework-Scheduler, wenn der Job ohnehin in Ihrer App lebt, und Aktionen nur für CI-Aufgaben planen, die unscharfen Timing tolerieren. Was auch immer Sie wählen, der Fünf-Felder-Ausdruck ist die Lingua Franca - weshalb ein Parser, der es spricht, fließend in Ihre Lesezeichen neben dem Rest Ihres Webentwickler-Toolkitdrohen
FAQ
Was ist ein Cron-Expression-Parser?
Ein cron-Expression-Parser ist ein Werkzeug, das die Syntax von Crontab liest */15 9-17 * * 1-5 - und übersetzt es in eine einfach englische Zeitplanbeschreibung, normalerweise neben einer Vorschau der nächsten Ausführungszeiten. Sie können überprüfen, was ein Zeitplan tatsächlich bewirkt, bevor er bereitgestellt wird, anstatt ein falsches Lesefeld zu entdecken, wenn ein Auftrag zum falschen Zeitpunkt in der Produktion ausgelöst wird.
Was bedeuten die fünf Felder in einem Cron-Ausdruck?
Von links nach rechts: Minute (0–59), Stunde (0–23), Tag des Monats (1–31), Monat (1–12) und Wochentag (0–7, wobei sowohl 0 als auch 7 Sonntag bedeuten). Jedes Feld akzeptiert * Für jeden Wert, Kommalisten, Bindestriche und / Schrittwerte. so 30 2 1 * * bedeutet 02:30 am ersten Tag eines jeden Monats.
Warum läuft mein Cron-Job zur falschen Zeit?
Die beiden häufigsten Ursachen sind Zeitzonen- und Feldverwirrung. Cron läuft in der lokalen Zeit des Schedulers - GitHub-Aktionen verwenden immer UTC, und viele Cloud-Server tun dies auch. Ein für "9 AM" geplanter Job kann Stunden von Ihrer Wanduhr abfeuern. Der andere Klassiker ist das Tauschen von Feldern, wie z. B. den Stundenwert in die Spalte "Minuten" einfügen. Das Parsen des Ausdrucks und das Überprüfen der nächsten Laufzeiten werden beides erfasst.
Sind 0 und 7 beide Sonntag in Cron?
In Vixie Cron und den meisten Linux-Implementierungen ja — crontab(5) Manpage erlaubt sowohl 0 als auch 7 für Sonntag. Dies ist jedoch nicht universell: Die Quarznummern der Tage 1–7 beginnen am Sonntag, und einige strenge Parser lehnen 7 ab. Wenn Sie Ausdrücke zwischen Systemen verschieben, überprüfen Sie das Wochentagsfeld, anstatt davon auszugehen, dass die Nummerierung überschreitet.
Was macht 0 0 13 * 5 eigentlich tun?
Nicht "Freitag der 13." Wenn sowohl der Monatstag als auch der Wochentag eingeschränkt sind, behandelt Standard Cron sie als OR: Der Job läuft jeden 13. des Monats und jeden Freitag. Dies ist dokumentiertes Vixie-Cron-Verhalten und eine der am meisten missverstandenen Regeln des Formats. Wenn Sie eine wahre und benötigen, fügen Sie eine Datumsprüfung im Skript selbst hinzu.
Wie wirkt sich die Sommerzeit auf die Cron-Jobs aus?
Auf Servern in DST-beobachtenden Zeitzonen können Jobs zwischen 01:00 und 03:00 Uhr die lokale Zeit überspringen (wenn die Uhren vorwärts springen) oder zweimal (wenn sie zurückfallen) je nach Implementierung überspringen. Die sichersten Muster sind Server auf UTC oder planen kritische Jobs außerhalb dieses Fensters. Beachten Sie, dass UTC-basierte Scheduler wie GitHub-Aktionen nicht die Läufe überspringen, sondern die Ortszeit, die zweimal im Jahr um eine Stunde entspricht.
ist @daily das gleiche wie 0 0 * * *?
Ja- @daily (und sein Synonym @midnight) exakt expandiert 0 0 * * * In Vixie Cron. Zwei Vorbehalte. Zunächst akzeptiert der Toolz.dev-Parser nur fünf Felder, also einfügen 0 0 * * * anstatt @daily Für jetzt. Zweitens jeder @daily Job wird im gleichen Moment ausgelöst, sodass ein Server mit vielen von ihnen einen Mitternachts-Ladeanstieg erhält. Wenn Sie tägliche Arbeitsplätze über gestaffelte Minuten und Stunden verteilen, wird diese selbst verursachte donnernde Herde vermieden.
Laden Sie den toolz.dev cron-Parser meine Ausdrücke hoch?
kein . das Cron Parser Läuft vollständig in Ihrem Browser – Ausdrücke werden clientseitig analysiert und niemals an einen Server gesendet, protokolliert oder gespeichert. Da crontabs betriebliche Details wie Backup-Timing und Abrechnungsläufe anzeigt, ist das Halten von Servern von Drittanbietern eine sinnvolle Standardeinstellung, und Sie können das Verhalten selbst auf der Registerkarte Netzwerk Ihres Browsers bestätigen.
Lesen Sie es zurück, bevor Sie es versenden
Fünf Wochen Verdauungs-E-Mails, die einen Tag zu spät ankommen, sind kein dramatischer Ausfall. Niemand hat mich an die Seite gewandert. Genau das macht die Planung von Fehlern teuer: Sie kündigen sich nicht an, sie tun nur leise das Falsche, bis ein Kunde es im Vorbeigehen erwähnt. Die Gewohnheit, die es für mich behoben hat, ist keine Disziplin oder ein besseres Gedächtnis für die Feldreihenfolge - es ist eine 32-Sekunden-Readback. Füge den Ausdruck ein, lies den englischen Satz, schaue dir fünf konkrete Daten an und stelle dann ein.
Halten Sie das Cron Parser Neben den Tools, nach denen Sie in derselben Debug-Sitzung greifen: Die Zeitstempelkonverter Wenn eine nächste Laufzeit zwischen Zonen verschoben werden muss (ich habe die Unix-Zeitstempelfallen der biss härteste), die Datumsdifferenzrechner für die Überprüfung der Intervalle und Text-Diff-Tool Wenn Sie eine alte Crontab während einer Migration mit einer neuen vergleichen. der Anleitung für die Coding-Tools Geht durch die Zusammenpassung des Sets und alles läuft auf der Clientseite - was für eine Datei, die genau dokumentiert, wann Ihre Sicherungen und Abrechnungen in Brand gehen, die einzig sinnvolle Standardeinstellung ist.
