Cronjobs und Zeitzonen

[paedubucher]

Auf einem Anwendungsserver verwende ich UTC als Zeitzone. In der Sommerzeit beträgt der Unterschied zwischen meiner lokalen Zeitzone zwei Stunden zum Server, in der Winterzeit ist es nur eine Stunde.

Auf dem Server laufen einige Cronjobs, welche E-Mails versenden. Der E-Mail-Versand soll zu einem bestimmten Zeitpunkt erfolgen, z.B. auf 12 Uhr mittags und 18 Uhr abends, damit man gewissen Vorgänge vom Vormittag und Nachmittag auseinanderhalten kann. Im Winter kann man diese Cronjobs auf 11 bzw. 17 Uhr konfigurieren, im Sommer müsste es jedoch 10 bzw. 16 Uhr sein, damit die Benutzer ihre E-Mails immer um 12 bzw. 18 Uhr erhalten. (Ich hoffe, dass ich das richtig gerechnet habe.) Dadurch muss ich die Zeiten der Cronjobs zweimal pro Jahr anpassen, was zwar nicht tragisch ist, jedoch dem Automatisierungsgedanken entgegenläuft.

Nun meine Frage: Gibt es eine Möglichkeit, die Cronjobs an Sommer- und Winterzeit anzupassen, ohne die Zeitzone des Servers zu ändern?

[MSfree]

Warum stellst du bei dem Server nicht die korrekte Zeitzone ein? Damit würde sich dein Problem, die Cronjobs zweimal im Jahr anpassen zu müssen, erübrigen.

Intern läuft Linux ohnehin immer mit UTC. Die Zeitstempel im Dateisystem sind beispielsweise immer in UTC und werden von Programmen wie "ls" on-the-fly auf die eingestellte Zeitzone umgerechnet.

[paedubucher]

Warum stellst du bei dem Server nicht die korrekte Zeitzone ein? Damit würde sich dein Problem, die Cronjobs zweimal im Jahr anpassen zu müssen, erübrigen.

Die ganze Infrastruktur von ca. 60 Servern in der Cloud (an verschiedensten Orten) war immer auf UTC eingestellt. Den genauen Grund dafür kenne ich nicht, dass eine Umstellung aber ohne jegliche Konsequenzen sein wird, glaube ich jedoch nicht. Hat vielleicht jemand Erfahrung damit?

[mat6937]

Nun meine Frage: Gibt es eine Möglichkeit, die Cronjobs an Sommer- und Winterzeit anzupassen, ohne die Zeitzone des Servers zu ändern?

Ich denke das sollte mit timer-units (statt den cronjobs) möglich sein. In der timer-unit kannst Du ein "calendar event" mit Angabe der lokalen timezone benutzen. D. h. die Zeitzone des Servers bleibt auf UTC und die Ausführung der timer-unit passiert gemäß der Uhrzeit aus der (lokalen) Zeitzone Europe/Berlin (d. h. CEST/CET). Das kann man ja mal testen.

[Meillo]

Ich auch etwas doof, dass Cron die Zeitzone aus /etc/timezone liest und man sie beim Start oder ueber ein Configfile nicht von der Systemeinstellung abweichend setzen kann.

Aber vielleicht kann eine alternative Cron-Implementierung das. In diese Richtung koenntest du mal noch recherchieren.

[paedubucher]

Ja, eine Timer Unit wäre eine Alternative dazu:

Code: Alles auswählen

$ systemd-analyze calendar '12:00 Europe/Zurich'
  Original form: 12:00 Europe/Zurich
Normalized form: *-*-* 12:00:00 Europe/Zurich
    Next elapse: Tue 2023-04-04 12:00:00 CEST
       (in UTC): Tue 2023-04-04 10:00:00 UTC
       From now: 2h 59min left

Da wir eh überall systemd verwenden, wäre das sicherlich nicht verkehrt.

[JTH]

Wär ein systemd.timer eine Option? Da könnte man Zeitzonen angeben:

Code: Alles auswählen

OnCalendar=Mon *-*-* 13:37:42 Europe/Berlin

Edit: Ah, zu spät

[hikaru]

Alternative zur Timer-Unit:
Du könntest jeweils um 10 Uhr und um 11 Uhr UTC per cron ein Wrapperscript starten, das die Lokalzeit abfragt und abhängig vom Ergebnis den eigentlichen Job startet. Für 18 Uhr CE(S)T machst du dann genau das Gleiche.

[Meillo]

Alternative zur Timer-Unit:
Du könntest jeweils um 10 Uhr und um 11 Uhr UTC per cron ein Wrapperscript starten, das die Lokalzeit abfragt und abhängig vom Ergebnis den eigentlichen Job startet. Für 18 Uhr CE(S)T machst du dann genau das Gleiche.

Das ginge sogar generisch:

Code: Alles auswählen

0 * * * *       hourcheck 12 /path/to/programm arg1 arg2

Und dann hourcheck in etwa so:

Code: Alles auswählen

#!/bin/sh

if "$1" -ne `date +%H` ; then
	exit 0
fi
shift

"$@"

[paedubucher]

Alternative zur Timer-Unit:
Du könntest jeweils um 10 Uhr und um 11 Uhr UTC per cron ein Wrapperscript starten, das die Lokalzeit abfragt und abhängig vom Ergebnis den eigentlichen Job startet. Für 18 Uhr CE(S)T machst du dann genau das Gleiche.

Das ginge sogar generisch:

Code: Alles auswählen

0 * * * *       hourcheck 12 /path/to/programm arg1 arg2

Und dann hourcheck in etwa so:

Code: Alles auswählen

#!/bin/sh

if "$1" -ne `date +%H` ; then
	exit 0
fi
shift

"$@"

Müsste ich dann nicht `TZ=Europe/Zurich date +%H` verwenden?

[Meillo]

Müsste ich dann nicht `TZ=Europe/Zurich date +%H` verwenden?

Aeh, ja, vermutlich. Das war als Antwort zum Mitdenken gedacht. Du hast sie gemeistert.

[hikaru]

Das ginge sogar generisch:

Ja. Ich war mir aber nicht sicher ob das bei nur zwei Programmaufrufen am Tag noch "elegant" ist, denn dann rufst du das Script 20 mal am Tag völlig unnötig auf.

[MSfree]

Die ganze Infrastruktur von ca. 60 Servern in der Cloud (an verschiedensten Orten) war immer auf UTC eingestellt. Den genauen Grund dafür kenne ich nicht,

Wenn das alles Linuxkisten sind, läuft die Systemuhr sowieso immer in UTC. Die Zeitzone ist nur für Anzeigezwecke und z.B. für cron wichtig.

dass eine Umstellung aber ohne jegliche Konsequenzen sein wird, glaube ich jedoch nicht.

Doch, sie ist ohne jegliche Konsequenzen.

[Meillo]

Das ginge sogar generisch:

Ja. Ich war mir aber nicht sicher ob das bei nur zwei Programmaufrufen am Tag noch "elegant" ist, denn dann rufst du das Script 20 mal am Tag völlig unnötig auf.

Wahrscheinlich haben wir da ein bisschen aneinander vorbei geredet. Mir geht es nicht darum, wie oft das Script aufgerufen wird. D.h. Man koennte den Stundenstern in der Crontab auch einschraenken. Mir ging es stattdessen darum, dass das Wrapperscript keine Kenntnis von relevanten Stunden hat, sondern die gewuenschte Zeit als Parameter mitgegeben wird, damit alle Information nur in der Crontab liegt und das Wrapperscript selbst generisch ist. Vielleicht hattest du das auch schon so gedacht und ich dich nur anders interpretiert.


(Ergaenzung: Hundert unnoetige Aufrufe am Tag eines kleinen Scripts, das gleich wieder aussteigt, sind mir gemeinhin egal. Erst wenn das wirklich ein Performanceproblem darstellt oder die Logs spuerbar zumuellt, kuemmere ich mich darum. Sonst ist mir mehr Generalitaet, Einfachheit und Robustheit meist wichtiger. Wenn ich nur einmal einen Fehler suchen muss, weil die Zeitzone drei Stunden von UTC abweicht und ich das bei den Cron-Stunden nicht beruecksichtigt habe, dann hat es sich schon nicht mehr gelohnt, etwas Performance sparen zu wollen ... zumindest aus meiner Sicht.)

[paedubucher]

Müsste ich dann nicht `TZ=Europe/Zurich date +%H` verwenden?

Aeh, ja, vermutlich. Das war als Antwort zum Mitdenken gedacht. Du hast sie gemeistert.

Noch besser: Die Zeitzone als Kommandozeilenparameter mitgeben!

Code: Alles auswählen

hourcheck 12 Europe/Zurich /path/to/job

Nachtrag: Um noch die laufende Diskussion über konzeptionelle Schönheit aufzugreifen: Hier wäre wohl eine systemd-Timer-Unit eine sinnvolle Lösung. Andererseits verwende ich solche in unserem Deployment sonst nie, d.h. wer dieses System warten muss, kommt gar nicht auf die Idee, sich die Timer-Units anzuschauen. Von daher wäre eine Lösung mit cronjobs doch passender. Auch wenn das Ding 23 mal sinnloserweise gestartet ist, wäre das noch kein Beinbruch. Gewisse Jobs (E-Mail-Versand aus einer Queue) werden jede Minute angestossen und haben haben dann effektiv ein dutzend mal pro Tag Arbeit zu verrichten. Von daher prüfe ich gerne einmal Meillos Vorschlag in der Praxis.

Die Timer-Units schaue ich mir dann einmal in Ruhe an, wenn ich ein neues Setup mache.

[chrbr]

Du könntest ja auch zu den gewohnten Zeiten den hourcheck starten. Wenn die Zeit passt startest Du das Programm, das zu der Zeit laufen soll. Ansonsten startest Du es mit at eine Stunde später.

[paedubucher]

Du könntest ja auch zu den gewohnten Zeiten den hourcheck starten. Wenn die Zeit passt startest Du das Programm, das zu der Zeit laufen soll. Ansonsten startest Du es mit at eine Stunde später.

Ich nehme an, at müsste ich dann auch wieder mit einer entsprechenden Zeitzone starten, oder?

[Meillo]

Du könntest ja auch zu den gewohnten Zeiten den hourcheck starten. Wenn die Zeit passt startest Du das Programm, das zu der Zeit laufen soll. Ansonsten startest Du es mit at eine Stunde später.

Ich nehme an, at müsste ich dann auch wieder mit einer entsprechenden Zeitzone starten, oder?

Du kannst `at' mit absoluten oder relativen Zeitangaben starten:

Code: Alles auswählen

at now + 1 hour

[paedubucher]

Du könntest ja auch zu den gewohnten Zeiten den hourcheck starten. Wenn die Zeit passt startest Du das Programm, das zu der Zeit laufen soll. Ansonsten startest Du es mit at eine Stunde später.

Ich nehme an, at müsste ich dann auch wieder mit einer entsprechenden Zeitzone starten, oder?

Du kannst `at' mit absoluten oder relativen Zeitangaben starten:

Code: Alles auswählen

at now + 1 hour

Danke; mit at hatte ich bisher noch nie gearbeitet. Am besten versuche ich einmal beide Lösungen, um sie besser vergleichen zu können.

[chrbr]

Ich bin mal gespannt. Mit Linux führen viele Wege zum Ziel.

[JTH]

Danke; mit at hatte ich bisher noch nie gearbeitet. Am besten versuche ich einmal beide Lösungen, um sie besser vergleichen zu können.

Du könntest dir auch dabei eine Rechnerei mit +1h oder +2h sparen und jeden Tag um Mitternacht@UTC ein

Code: Alles auswählen

TZ=Europe/Berlin at 13:37

ausführen. Das geht natürlich nur bei Zeitzonen mit UTC+X.

Neben at gibts übrigens auch noch

Code: Alles auswählen

systemd-run --on-calendar=…

Aber wenn du da schon bist, lohnt sichs auch, auf einen systemd.timer umzusteigen.

[Meillo]

Du könntest dir auch dabei eine Rechnerei mit +1h oder +2h sparen und jeden Tag um Mitternacht@UTC ein

Code: Alles auswählen

TZ=Europe/Berlin at 13:37

ausführen.

Hast du getestet, ob das funktioniert? `at' ist meist ueber `cron' implementiert, bzw. arbeitet Cron die At-Jobs ab. Ich kann mir gut vorstellen, dass `at' die Zeiten umrechnet, bin mir aber nicht sicher.

[JTH]

Hast du getestet, ob das funktioniert?

Ja, schien mir mit zwei kurzen Probeaufrufen zu tun, was es sollte. Aber ohne Gewähr.

Also die dem at übergebene Uhrzeit sollte dann in der lokalen „Ziel“zeit sein.

[heisenberg]

Könnte ein Problem von Servern, die nicht auf UTC eingestellt sind und in verschiedene Zeitzonen laufen nicht erschwertes Debugging sein?

Sprich: Wenn Server interagieren, man möchte Vorgänge serverübergreifend nachverfolgen und dann sind in den Logs jeweils lokaler Zeit abgespeichert?

[paedubucher]

Könnte ein Problem von Servern, die nicht auf UTC eingestellt sind und in verschiedene Zeitzonen laufen nicht erschwertes Debugging sein?

Sprich: Wenn Server interagieren, man möchte Vorgänge serverübergreifend nachverfolgen und dann sind in den Logs jeweils lokaler Zeit abgespeichert?

Tatsächlich ziehen wir die Logs verschiedener Server zusammen und gehen überall von UTC aus. Von daher ist eine einheitliche Zeitzone sicherlich sinnvoll. Aber den genauen Grund für die Wahl von UTC kenne ich leider auch nicht. Ich dachte, das sei gängige Praxis...