Cron-Ausdrücke: häufige Fehler und Zeitzonenfallen
Monatstag und Wochentag werden mit ODER verknüpft, Schrittwerte setzen zur vollen Stunde zurück, die Falle des 31. Tags, UTC gegenüber Ortszeit und Jobs, die bei der Zeitumstellung ausfallen oder doppelt laufen.
Zeitgesteuerte Jobs (nächtlicher Abgleich, Bericht, Sicherung) sind das stille Rückgrat der meisten Integrationen. Weil ein Cron-Ausdruck kurz ist, übersieht man seine Fehler leicht: Der Ausdruck ist gültig, der Job läuft, aber nicht, wann man es erwartet. Die folgenden Fallen begegnen uns beim üblichen Ausdruck mit fünf Feldern (Minute, Stunde, Monatstag, Monat, Wochentag) am häufigsten.
1. Monatstag und Wochentag werden mit ODER verknüpft
„0 9 1 * 1“ als „09:00 Uhr, wenn der 1. ein Montag ist“ zu lesen, ist ein verbreitetes Missverständnis. Sind beide Felder eingeschränkt, verknüpft klassisches (Vixie-)Cron sie mit ODER: Der Job läuft am 1. und außerdem an jedem Montag. Ist eines davon ein Stern, wird wieder UND angewendet. Für eine Bedingung wie „der erste Montag im Monat“ reicht der Ausdruck allein nicht; der Job muss das heutige Datum selbst prüfen.
2. Ein Schrittwert setzt zur vollen Stunde zurück
„*/7 * * * *“ sieht nach „alle sieben Minuten“ aus; tatsächlich sind die Minuten 0, 7, 14, ... 56, und zur vollen Stunde folgt wieder 0. Der Abstand nach 56 beträgt also 4 Minuten. Schritte, die 60 nicht teilen (7, 8, 25 ...), laufen ungleichmäßig. Braucht man wirklich ein gleichmäßiges Intervall, wählt man einen Schritt, der 60 teilt (5, 10, 15, 20, 30), oder baut den Scheduler auf „seit dem letzten Lauf“ auf.
3. Monate ohne 31. Tag
„0 0 31 * *“ läuft nicht jeden Monat, sondern nur in den sieben Monaten mit 31 Tagen. Für „Monatsende“ wählt man meist einen sicheren Tag wie den 28., oder der Job läuft täglich und prüft, ob morgen der 1. ist. Im Februar gibt es den 30. und 31. nie, den 29. nur in Schaltjahren.
4. Zeitzone: was sagt der Server?
Die Zeitzone eines Cron-Ausdrucks ist die der Umgebung, in der der Job läuft, in den meisten Cloud-Umgebungen UTC. UTC 06:00 ist in der Türkei (UTC+3, keine Sommerzeit) 09:00. Für „jeden Morgen um 09:00“ muss der Ausdruck auf einem UTC-Server „0 6 * * *“ lauten. Wechselt die Umgebung (vom lokalen Rechner in die Cloud), wechselt auch die Zeitzone, und der Job verschiebt sich um drei Stunden. Notieren Sie daher neben dem Ausdruck, in welcher Zeitzone er geschrieben wurde.
5. Zeitumstellung
In einer Zeitzone mit Sommerzeit fehlt bei der Frühjahrsumstellung eine Stunde: In Deutschland springt die Ortszeit am letzten Märzsonntag von 02:00 auf 03:00, und „30 2 * * *“ läuft an diesem Tag womöglich nicht. Im Herbst gibt es eine Stunde doppelt, und derselbe Job kann zweimal laufen. Das Verhalten hängt vom Scheduler ab. Gegenmaßnahme: kritische Jobs in UTC planen oder den Job so schreiben, dass ein erneuter Lauf nicht schadet (idempotent).
6. Syntax anderer Systeme
Quartz und ähnliche Werkzeuge nutzen sechs oder sieben Felder mit Sekundenfeld und Sonderzeichen wie „?“, „L“ und „W“. In Standard-Cron eingefügt, ist ein solcher Ausdruck ungültig oder bedeutet etwas anderes. Beim Wochentag stehen 0 und 7 beide für Sonntag; Namen (MON, JAN) werden nicht überall unterstützt.
Vor dem Lauf ansehen
Geben Sie den Ausdruck in den Cron-Ausdruck-Erklärer ein: Er erklärt ihn in Alltagssprache, zeigt für die gewählte Zeitzone die nächsten 10 Ausführungszeiten und warnt vor Fallen wie der ODER-Regel. Zum Umrechnen von Zeitstempeln gibt es den Zeitstempel-Umrechner, für das Wiederholungsverhalten den API-Retry-Simulator. Für die Durchsicht Ihrer Integrationszeitpläne schreiben Sie uns.
Lassen Sie uns das für Ihr Werk besprechen
Weitere Notizen
Alle Notizen →- 3 Min. LesezeitSechs häufige Fehler auf UDI-Etiketten von MedizinproduktenVerpackungsebenen, Änderungen mit neuer UDI-DI, Verwechslung von Basic UDI-DI und UDI-DI, fehlende Herstellungskennung, Etikett und Barcode passen nicht zusammen, ungeprüfte Druckqualität: die häufigsten UDI-Fehler bei Medizinprodukten.
- 2 Min. LesezeitSechs Situationen, in denen die Karton-Paletten-Beziehung bei der Aggregation brichtAusgeschleuste Packungen, Teilkartons, Probenahme, manuelle Eingriffe, Doppelzuordnung und Palettenauflösung: die häufigsten Situationen, in denen Aggregationsdaten vom physischen Inhalt abweichen, und wie man sie an der Linie verhindert.
- 2 Min. LesezeitLücken und fehlerhafte Werte in SCADA-Daten: was vor der Modellierung zu tun istZeitstempel, Lücken, eingefrorene Sensoren, physikalisch unmögliche Werte, Abregelung und Wartungszeiten, Sensortausch: was in SCADA-Daten vor einem Modell für vorausschauende Wartung oder Leistungsprognose zu prüfen ist.