Der teuerste Cron-Ausdruck, den ich je geschrieben habe, war 0 0 * * 0. Es lief eine wöchentliche Digest-E-Mail für ein Laravel SaaS, das ich baute, und ich war mir absolut sicher, dass es & quot; mitternacht am letzten Tag der Woche bedeutete." Es bedeutet Mitternachtssonntag Mein mentales Modell sagte, die Woche endete am Samstag. Fünf Wochen lang bekamen Kunden ihre " Woche in review" E-Mail einen Tag zu spät, und niemand im Team fing es, weil auch niemand im Team Cron lesen konnte - wir schielen alle nur auf die fünf Felder 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 gut Deutsch, was tatsächlich passieren wird - 0 0 * * 0 Kommt zurück als & quot; Um 00:00 Uhr, am Sonntag" - plus wenn die nächsten Durchläufe ausgelöst werden Dieser Rückleseschritt ist der Unterschied zwischen dem Versand eines Zeitplans und dem Versand einer Vermutung. Ich habe den auf Toolz.dev erstellt, weil ich es satt hatte, den Kontext auf ein Terminal umzustellen, und weil das wp-cron-Mess, mit dem ich mich jahrelang in WP Adminify beschäftigt habe, mir beigebracht hat, dass Planungsfehler die geduldigsten Fehler in der Software sind.
In diesem Handbuch geht es darum, wie man den Parser verwendet, wie die fünf Felder tatsächlich funktionieren (einschließlich der beiden Macken, die die meisten Produktionsvorfälle verursachen) und wo die Cron-Syntax unterschiedlich ist crontab, GitHub-Aktionen, Quarz und Laravel.
tl; dr: Fügen Sie einen beliebigen Crontab-Ausdruck in die Toolz.dev cron Parser Und erhalten Sie eine einfache englische Übersetzung plus kommende Laufzeiten - sofort, clientseitig, keine Anmeldung Bevor Sie einen Zeitplan bereitstellen, überprüfen Sie immer zwei Dinge: die Nummerierung des Wochentags (0 und 7 sind beide Sonntag) und die Zeitzone, in der der Scheduler läuft (GitHub Actions ist immer UTC).Koppeln Sie 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 & quot; Jede 15. Minute nach Stunde 9, 10, 11, 12, 13, 14, 15, 16 und 17, am Montag, Dienstag, Mittwoch, Donnerstag und Freitag." It's ausführlich - es zählt auf, anstatt & quot;9 bis 17" zurück in einen Bereich - und diese Ausführlichkeit ist der Punkt Die Zählung ist eindeutig; Ein zusammengefasster Bereich ist eine weitere Chance, falsch zu lesen. Der Satz ist etwas, das Sie in eine Pull-Requot-Beschreibung einfügen können, lesen Sie in einem Standup, und zeigen Sie sofort einen nicht technischen Stopp-Übersetzer-Übersetzer-Kenner-Kenner-Kennsatz. 1.
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 sich auf Englisch gut liest, aber in 27 Tagen einen nächsten Lauf von & quot; produziert" weil Sie Tag des Monats mit Monat verwechselt haben, oder einer, der heute Abend um 03:00 Uhr feuert, als Sie nach dem Wochenende 03:00 meinten Ich überprüfe jetzt jedes Mal die Liste der nächsten Ausführung, selbst für Ausdrücke I & #39; bin zuversichtlich. Besonders für Ausdrücke I & #39; bin zuversichtlich, ob - sehen Sie die Eröffnungsanekdote.
Zwei Details darüber, wie diese Zeiten berechnet werden. Zunächst werden sie bewertet Die lokale Zeitzone Ihres BrowsersNicht UTC und nicht Ihr Server' s-Zone - jeder Lauf wird zweimal angezeigt, einmal als lokaler Zeitstempel und einmal als äquivalenter UTC-Zeitpunkt, sodass Sie lesen können, was Ihrem Bereitstellungsziel entspricht. Zweitens wendet der Parser echte Cron's ODER-Semantik an, anstatt 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) parsen als gültig, beschreibt sich glücklich als & quot; um 00:00 Uhr, am 30. Monatstag, im Februar, " und zeigt dann eine leere Next-Runs-Liste anLeer bedeutet nie It's korrekt, aber it's leise - ein " dieser Zeitplan wird niemals feuern" Warnung ist die offensichtliche Verbesserung und ich habe & #39; noch nicht gebaut.
Aufschlüsselung von Feld zu Feld
Der Parser teilt den Ausdruck in seine fünf Komponenten auf - Minute, Stunde, Tag des Monats, Monat, Wochentag - und zeigt an, was jeder einzelne beiträgt Das ist wichtig, denn Cronfehler sind fast immer ein Einzelfeldproblem: 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,5. Der Parser kümmert sich um alles, einschließlich der kombinierten Formen, die menschliche Leser auf den Kopf stellen. Stufenwerte über Bereiche - 8-18/2 Bedeutung & quot; alle 2 Stunden von 8 bis 18" - legal, nützlich und ohne Werkzeug nahezu unlesbar sind Wenn Sie & #39; jemals einen Crontab voll davon von einem verstorbenen Sysadmin 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 - & quot; Erwartete 5 Felder (Minutenstunde Monatstag-Woche), bekam 1" - keine Übersetzung Das Gleiche gilt 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 Es gibt überhaupt kein Fünf-Felder-Äquivalent - es ist ' Es handelt sich nicht um einen Zeitplan, er läuft einmal beim Daemon-Startup, eine Tatsache, die viele Leute überrascht hat, die Migrationen von crontab aus 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 Job auf einem Server feuert im selben Moment - Mitternacht - also vierzig von ihnen ist eine nächtliche Lastspitze Ich streue 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 den Ausdruck eingeben - 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 sollten' t. Lesen Sie die einfach-englische Ausgabe und vergleichen Sie sie mit dem Satz in Ihrem Kopf Wenn Sie den Ausdruck geschrieben haben, der " jeden Montag um 9 Uhr morgens und Kontingents; und die Rücklesung sagt & quot; Um 09:00 Uhr am Tag des Monats 1" - Glückwunsch, Sie haben gerade den klassischen Spaltentausch vor der Produktion erwischt. Die Rücklesung ist Ihr Unit-Test.
Schritt 3: Überprüfen Sie die nächsten Laufzeiten
Überprüfen Sie die fünf bevorstehenden Hinrichtungen. Landen die Termine dort, wo Sie es erwarten? Ist der erste Lauf heute Abend, morgen oder nächsten Monat? Achten Sie auf die Lücke zwischen den Läufen - ein fehlplatzierter */ 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-Felder-Format stammt von Unix cron, in der Praxis standardisiert von Paul Vixie' s cron-Implementierung in den späten 1980 er Jahren - die in dokumentierte 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' s die ganze Grammatik Die Komplexität ist ' t in der Syntax - it' s in drei Verhaltens-Mängeln.
Quirk One: Der Wochentag Null. per crontab(5), sowohl 0 als auch 7 bedeuten Sonntag Einige ältere oder strengere Implementierungen akzeptieren nur 0. Quartz - der von Jenkins verwendete Java-Scheduler und die Hälfte der Unternehmenssoftware - nummeriert Tage 17 ab dem 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 Übereinstimmungen - ein OR, kein AND. Also 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, weil UTC tut' nicht DST beobachten, aber Ihre Zielgruppe's Uhr tut. Ihr "9 AM Tagesbericht" driftet zweimal im Jahr um eine Stunde, es sei denn, Sie passen den Arbeitsablauf an oder verarbeiten 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 # (in den Wochentag des Monats).Einige Crons unterstützen auch ein Leading-Seconds-FeldWenn Ihr Ausdruck sechs Felder hat und Sie' nicht sicher sind, um welchen Dialekt es sich handelt, fügen Sie ihn in den Parser ein - ein Sechs-Felder-Ausdruck, 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
Laravel' s Scheduler wickelt cron in fließenden Methoden - ->dailyAt('03:00'), ->weeklyOn(1, '8:00')- aber die Fluchtluke ->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 ausgeliefert, das ist' t cron überhaupt - it' s ein Pseudo-Planer, der bei Seitenbesuchen huckepacks macht, also eine Site mit geringem Traffic's & quot;hourly" job könnte alle vier Stunden laufen, und eine Site mit hohem Traffic zahlt auf jede Anfrage eine kleine Steuer Während meiner WP Adminify-Jahre erzeugte dies einen stetigen Strom von " geplanten Beiträgen aren't publishing" berichtet. Der Standardfix ist die Deaktivierung von wp-cron (DISABLE_WP_CRON) und auslösen wp-cron.php Von einer echten Server-Crontab - an diesem Punkt schreiben Sie' in der Regel 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 analysiere den Ausdruck, schaue mir die nächsten Laufzeiten an, dann füge ich gedanklich den UTC-Offset hinzu Zwei extra Details spezifisch für Aktionen: Zeitpläne laufen nur auf dem Standardzweig, und Läufe können während Hochladezeiten verzögert oder fallen gelassen werden - GitHub' eigene Docs sagen das Wenn das genaue Timing zählt, sind Cron-ausgelöste Aktionen das falsche Werkzeug; wenn das ungefähre Timing in Ordnung ist, machen Sie zumindest die ungefähre Zeit zum 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 Und jede Zeile durch den Parser einzufügen ist die schnellste Prüfung, die ich kenne: Innerhalb von zehn Minuten haben Sie eine reine englische Zeitplaninventur, und Sie werden fast immer mindestens einen Job finden, der etwas erledigt, an das sich niemand erinnert hat - ein Backup, das zweimal läuft, ein Bereinigungsskript, das nie mit dem Tag übereinstimmte, an dem es hätte sein sollen, 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 Feld - eine echte Verbesserung gegenüber klassischem Cron Der Parser-Workflow ist derselbe: den Ausdruck überprüfen, nächste Durchläufe überprüfen, dann bestätigen 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 welche zu verwenden ist: crontab für einfache Server-Jobs, systemd-Timer, wenn Sie Protokollierung und Abhängigkeitsbehandlung kostenlos unter modernem Linux wünschen, der Framework-Scheduler, wenn der Job ohnehin in Ihrer App lebt, und Aktionspläne nur für CI-Aufgaben, die Fuzzy-Timing tolerieren, Was auch immer Sie auswählen, der Fünf-Felder-Ausdruck ist die Verkehrssprache - weshalb ein Parser, der ihn fließend spricht, in Ihre Lesezeichen neben den Rest Ihres Buches gehört Webentwickler-Toolkitdrohen
FAQ
Was ist ein Cron-Expression-Parser?
Ein Cron-Ausdrucksparser ist ein Tool, das die Crontab-Syntax liest - wie */15 9-17 * * 1-5- und übersetzt es in eine einfache englische Zeitplanbeschreibung, typischerweise zusammen mit einer Vorschau der nächsten Ausführungszeiten. Damit können Sie überprüfen, was ein Zeitplan tatsächlich tut, bevor Sie ihn bereitstellen, anstatt ein falsch gelesenes Feld zu entdecken, wenn ein Auftrag zur falschen Zeit in der Produktion feuert.
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 im Scheduler' s Ortszeit - GitHub Actions verwendet immer UTC, und viele Cloud-Server tun es auch - also kann ein Job, der für & quot;9 AM" Stunden von Ihrer Wanduhr abfeuern Der andere Klassiker ist das Vertauschen von Feldern, wie das Einfügen des Stundenwerts in die Minutenspalte Das Parsen des Ausdrucks und das Überprüfen der nächsten Laufzeiten fängt beide.
Sind 0 und 7 beide Sonntag in Cron?
In Vixie cron und den meisten Linux-Implementierungen ja - die 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 offenlegen, ist es eine sinnvolle Standardeinstellung, sie von Servern Dritter fernzuhalten, und Sie können das Verhalten selbst in Ihrem Browser bestätigen' s Netzwerk-Tab.
Lesen Sie es zurück, bevor Sie es versenden
Fünf Wochen Digest-Mails, die einen Tag zu spät eintreffen, sind kein dramatischer Ausfall Niemand hat mich angepiept That' s genau das, was Terminierungsfehler teuer macht: Sie don' t kündigen sich an, sie tun nur stillschweigend das Falsche, bis ein Kunde es am Rande erwähnt Die Gewohnheit, die es für mich behoben hat, ist ' t Disziplin oder ein besseres Gedächtnis für Feldreihenfolge - it' s eine zweiunddreißigste Rücklesung Fügen Sie den Ausdruck ein, lesen Sie den englischen Satz, schauen Sie sich fünf konkrete Daten an und setzen Sie ihn 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 Durchläuft, wie das Set zusammenpasst und alles clientseitig läuft - was für eine Datei, die genau dokumentiert, wann Ihre Backups und Abrechnungen ausgelöst werden, die einzig sinnvolle Standardeinstellung ist.
