Vermeide Cron-Jobs um 2:00 und 3:00 Uhr (2013)

 (endpointdev.com)
5 Punkte von GN⁺ 2025-10-29 | 2 Kommentare | Auf WhatsApp teilen
  • Ein Hinweis auf Fehler bei Cron-Jobs auf Linux-Servern während der Umstellung auf die Sommerzeit (DST)
  • Zweimal im Jahr kommt es bei der Zeitumstellung sonntags um 2:00 oder 3:00 Uhr morgens dazu, dass Cron-Jobs doppelt ausgeführt oder ausgelassen werden
  • In einem realen Fall wurden in einer vixie-cron-Umgebung Jobs zwischen 3:00 und 3:01 Uhr 60-mal im Abstand von 1 Sekunde wiederholt ausgeführt, was zu einer E-Mail-Flut führte
  • Als Lösung werden das Setzen der Zeitzone auf UTC oder das Meiden von Jobs in diesem Zeitfenster sowie die Entwicklung eines besseren Open-Source-Schedulers vorgeschlagen
  • Ein Beispiel, das Serverbetreiber und DevOps-Ingenieure an die Bedeutung des Risikomanagements bei Zeitumstellungen erinnert

Konflikte zwischen Sommerzeit und Cron-Jobs

  • Wenn Cron-Jobs auf Sonntagmorgen um 2:00 oder 3:00 Uhr gelegt werden, überschneiden sie sich mit der Umstellung auf die Sommerzeit (DST) und können zu unerwarteten Ausführungsfehlern führen
    • Beim Beginn der DST springt die Uhr eine Stunde vor, beim Ende eine Stunde zurück, wodurch Stunden doppelt vorkommen oder ganz entfallen
    • Dadurch kann es dazu kommen, dass Jobs in bestimmten Zeitfenstern zweimal ausgeführt oder gar nicht ausgeführt werden
  • Besonders Jobs, die jede Woche am frühen Sonntagmorgen laufen, sind zweimal pro Jahr von der DST-Umstellung betroffen
    • Meist funktionieren sie problemlos, aber am Tag der Zeitumstellung kann es zu ungewöhnlich wiederholten Ausführungen kommen

Praxisfall: Wiederholte Ausführung in vixie-cron

  • In einer Linux-Umgebung mit vixie-cron wurde berichtet, dass beim Beginn der DST Jobs zwischen 3:00 und 3:01 Uhr etwa 60-mal im Abstand von 1 Sekunde ausgeführt wurden
    • Die einzelnen Jobs gerieten sich gegenseitig in die Quere und verursachten Chaos wie eine Flut von E-Mail-Benachrichtigungen
    • Glücklicherweise waren diese Jobs nicht kritisch, sodass kein Systemschaden entstand
  • Diese Probleme gehen auf die einfache zeitbasierte Scheduling-Struktur von Cron zurück
    • Cron erkennt Änderungen der Zeitzone oder DST-Umstellungen nicht, sondern führt Jobs schlicht zur angegebenen Uhrzeit aus

Mögliche Lösungen und Alternativen

  • Die einfachste Methode ist, keine Jobs sonntags früh um 2:00 und 3:00 Uhr zu planen
    • Wer dieses Zeitfenster meidet, kann Probleme mit mehrfacher Ausführung durch die DST-Umstellung vollständig vermeiden
  • Auch das Setzen der Server-Zeitzone auf UTC ist eine wirksame Alternative
    • UTC verwendet keine Sommerzeit, daher gibt es keine Zeitumstellungen
  • Als grundlegendere Lösung wird die Entwicklung eines intelligenteren Job-Schedulers vorgeschlagen
    • Es wird ein Open-Source-Ersatzwerkzeug benötigt, das Funktionen wie Schutz vor Doppelstarts, Begrenzung der Laufzeit und Zeitzonenbewusstsein bietet

Langfristiger Vorschlag: Abschaffung der Sommerzeit

  • Der Autor des Beitrags nennt die Abschaffung der DST auf Regierungsebene als die wünschenswerteste Lösung
    • Die zweimal jährliche Zeitumstellung verursacht sowohl im Systembetrieb als auch im Alltag unnötige Komplexität
  • Solange DST in der Praxis bestehen bleibt, müssen jedoch Systemadministratoren und DevOps-Ingenieure vorbeugende Maßnahmen ergreifen
    • Besonders bei automatisierten Batch-Jobs, Backups, Log-Rotation und anderen zeitabhängigen Aufgaben ist Vorsicht geboten

Fazit: Prinzipien für sicheres Cron-Scheduling

  • Jobs im Zeitfenster von 2:00 bis 3:00 Uhr während der DST-Umstellung sollten vermieden werden
  • Wenn möglich, sollten Server auf UTC-Basis betrieben werden, um Zeitzonenprobleme zu beseitigen
  • Die Grenzen von Cron sollten erkannt und der Einsatz robusterer Scheduling-Tools geprüft werden
  • In DevOps-Umgebungen sind Zeitzonenmanagement und verlässliche Automatisierung unverzichtbare Aufgaben

Verwandte Beiträge

2 Kommentare

 
semjei 2025-10-29

Seit ich selbst Probleme mit einem auf 2 Uhr nachts angesetzten Job hatte (mal wurde er zweimal ausgeführt, mal gar nicht), vermeide ich diese Zeit unbedingt.
 
GN⁺ 2025-10-29
Hacker-News-Kommentare

  • Ich halte DST (Sommerzeit) für ein komplett verfehltes System.
    Es löst keinerlei Probleme und verursacht stattdessen nur Unannehmlichkeiten.
    Man sollte einfach dauerhaft bei der Standardzeit bleiben und stattdessen die Arbeitszeiten im Sommer um eine Stunde vorverlegen.
    Zum Beispiel könnten Geschäfte statt um 7 Uhr schon um 6 Uhr öffnen und statt um 10 Uhr bereits um 9 Uhr schließen.
    Man muss sich ohnehin zweimal im Jahr anpassen, also könnte man es auch einfach einmalig ändern.
    Ich möchte nach Feierabend lieber mehr Tageslicht haben. Im Winter gilt das umso mehr, und es ist mir egal, ob auf dem Arbeitsweg die Sonne scheint.
    Ich werde ohnehin 9 Stunden drinnen festsitzen, also möchte ich das Sonnenlicht dann sehen, wenn ich Freizeit habe.

    • Alle hassen DST, aber die vorgeschlagenen Alternativen wurden bereits ausprobiert.
      Zum Beispiel gab es 1973–1975 in den USA ein Experiment mit ganzjähriger DST.
      Anfangs war die Zustimmung wegen Energieeinsparungen und sinkender Kriminalität hoch,
      aber nach Unfällen auf dem dunklen Schulweg am Morgen kippte die Stimmung schnell, und die Regelung wurde wieder abgeschafft.
      (Wikipedia-Zitat)
    • Ich frage mich, ob es nicht am Ende auf dasselbe hinausläuft, wenn man statt die Uhren umzustellen einfach die Geschäftszeiten ändert.
      Eigentlich klingt das so, als wolle man am Ende nur eine noch größere Zeitverschiebung.
    • Den Begriff „Winterzeit“ gibt es eigentlich gar nicht.
      Es gibt nur Standardzeit und Sommerzeit.
      Die Formulierung, man wolle „Winterzeit“ dauerhaft beibehalten, wirkt psychologisch nicht besonders attraktiv.
    • DST ist letztlich nur ein Provisorium, um sich an die Zeit des Sonnenaufgangs anzupassen.
      Menschen möchten ihren Tag beginnen, wenn es bereits hell ist.
      Programmierer leiden zwar unter DST, aber ich denke, das ist vor allem ein Problem sauberer Edge-Case-Behandlung.
    • Die Debatte über Standardzeit oder Sommerzeit entsteht letztlich daraus, dass es zu wenig Freiheit bei der Wahl der Arbeitszeiten gibt.
      Menschen haben unterschiedliche Schlafrhythmen; wenn jeder passendere Arbeitszeiten wählen könnte, gäbe es weniger Konflikte.

  • Als wir früher die reddit-Server eingerichtet haben, waren sie alle auf die Zeitzone von Arizona gestellt.
    Arizona verwendet keine DST, daher beträgt der Unterschied zu Kalifornien nur eine Stunde.
    Wir haben nicht UTC verwendet, weil es beim Lesen von Logs „einfacher ist, 1 statt 8 abzuziehen“.
    Inzwischen gibt es ein globales Team, daher wurde alles auf UTC umgestellt.

    • Ich habe einmal eine ähnliche Entscheidung getroffen und musste später mühsam aufräumen.
      Es ist besser, von Anfang an alles einheitlich auf UTC zu setzen.
    • Aber auch bei Arizona besteht das Risiko, dass sich die Zeitzonendefinition ändert.
      Solche Änderungen passieren weltweit häufig, und aus Sicht von Kalender-App-Entwicklern ist das wirklich unerquicklich.
    • Mich stört, dass die UI des Log-Viewers das 12-/24-Stunden-Format anhand der Browserspracheinstellung erzwingt.
      Wenn jemand UTC auswählt, sollte man davon ausgehen können, dass diese Person das Format YYYY-MM-DD mit 24-Stunden-Zeit versteht.
    • In Java kann man die Standardzeitzone auf JVM-Ebene setzen,
      aber weil in der Organisation jeder sie für sich auf PST umgestellt hatte, entstand Verwirrung, da die Zeiten in den Logs unterschiedlich waren.
      Am Ende griff der Leiter ein und vereinheitlichte alle Anwendungen und Datenbanken auf PST.
    • Dass sich beim Lesen von Logs in UTC das Datum nicht ändert, ist für mich immer noch verwirrend.
      Trotzdem interpretiere ich UTC inzwischen fast instinktiv.

  • Früher hatten wir Firmenserver auf BST (Britische Sommerzeit) eingestellt und viele cron-Jobs laufen lassen,
    und zweimal im Jahr gab es wieder dieselbe Verwirrung.
    Bis die Firma unterging, haben wir das Problem nicht behoben.
    Die Lehre ist simpel: Verwendet UTC, wenn es keinen besonderen Grund dagegen gibt.

    • Ich habe eine analoge UTC-Uhr auf dem Schreibtisch und nutze sie als Referenz beim Lesen von Logs.
    • Manchmal verwendet man lokale Zeitzonen, weil der Kunde eben nicht in UTC lebt.
      Zum Beispiel laufen Nutzungslimit-Resets oder Abrechnungs-Batchjobs nach regionaler Zeit.
    • Ich finde, man sollte cron selbst möglichst vermeiden und stattdessen einen Scheduler verwenden, der Daten und Kundeneinstellungen berücksichtigt.
    • Manche Berichte werden in lokaler Zeit benötigt.
      Ein Bericht für 8 Uhr in Großbritannien entspricht je nach DST einer anderen UTC-Zeit.
      Deshalb reicht UTC allein nicht aus; man muss auch die Zeitzoneninformation speichern.
    • In Bereichen wie dem Finanzsektor, in denen Marktöffnungszeiten wichtig sind, reicht UTC allein ebenfalls nicht.

  • In einigen Ländern (Kuba, Ägypten, Libanon) erfolgt die DST-Umstellung um Mitternacht.
    (passender Link)

    • Es hat mich überrascht, dass DST-Änderungen nicht überall außerhalb von Mitternacht stattfinden.
      In Brasilien war es üblich, dass die Umstellung in Zeiträume wie 00:00–01:00 oder 00:00–23:00 fiel.
    • Zeitzonenregeln führen wirklich oft zu völlig unvorhersehbaren Situationen.

  • Es gibt Studien, laut denen an Tagen mit DST-Umstellung Sterblichkeit und Notaufnahmebesuche stark ansteigen.
    (ScienceAlert-Artikel)
    Das geht weit über cron-Probleme hinaus; DST ist auch gesundheitlich schädlich.

  • Dieses Problem wurde schon vor langer Zeit bei OpenBSD und Debian gelöst.
    Im cron(8)-Handbuch von Debian wird die Logik zur Behandlung von Zeitsprüngen unter 3 Stunden bei DST-Umstellungen beschrieben.
    (Patch-Link,
    Handbuch,
    Bugreport)

    • Dann scheint der Autor des Originaltexts wohl eine Distribution ohne diesen Patch verwendet zu haben.

  • Der Rat lautet, keine Jobs exakt um Mitternacht (00:00) zu planen.
    Weil das Datum leicht für Verwirrung sorgt, ist es besser, krumme Uhrzeiten wie 00:01 oder 01:45 zu verwenden.

    • Ich setze meine cron-Jobs ebenfalls auf Zeiten wie XX:13, XX:23, XX:42.
      So lässt sich leichter nachvollziehen, was passiert ist, wenn das System zu bestimmten Zeiten seltsam reagiert.
    • 00:00 war bei mir fast nie ein Problem.
      In Umgebungen mit 12-Stunden-Uhr kann es allerdings zu Verwirrung kommen.

  • Bevor ich mit Zeitzonenproblemen zu tun hatte, wusste ich nicht,
    dass es auf der Welt nicht existierende und mehrdeutige Uhrzeiten gibt.
    Wenn zum Beispiel die Zeit von 2 auf 3 Uhr springt, existiert 2:30 nicht,
    und wenn die Uhr zurückgestellt wird, kommt 2:30 zweimal vor.
    Da jedes Land die DST zu einer anderen Uhrzeit umstellt, kann wie in Chile sogar Mitternacht verschwinden.
    (passender Blog)
    Ich erinnere mich daran, dass Java und Ruby diese Situation unterschiedlich behandelt haben und das in meinen frühen Tagen bei Stripe dreimal hintereinander zu Vorfällen führte.

  • Bei cron-Jobs sollte man volle Stunden vermeiden und sie nach Möglichkeit nach 4 Uhr morgens oder vor Mitternacht planen.
    Auf gemeinsam genutzter Infrastruktur ist der Wettbewerb um Ressourcen zur vollen Stunde besonders stark.

    • Mit der Option RandomizedDelaySec von systemd lassen sich Kollisionen verringern.
    • Man kann dem cron-Befehl auch Code wie sleep $(( $(od -N1 -tuC -An /dev/urandom) % 60 ))m ; voranstellen,
      um eine zufällige Verzögerung von 0 bis 59 Minuten einzubauen.

  • Wichtige geplante Jobs sollten nach Möglichkeit idempotent (sicher bei mehrfacher Ausführung) gestaltet sein.
    Gerade wenn ein Queue-System beteiligt ist, ist ein solches Design entscheidend zur Vermeidung von Problemen.