Cronjobs und Zeitzonen

[MSfree]

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...

Man kann Logs unabhängig von der eingestellten Zeitzone laufen lassen. rsyslog erlaubt z.B. die Definition einer eigenen Zeitzone, da kann man auch UTC vorgeben, so daß alle gelogten Zeiten dann auch in UTC angegeben sind.

Nochmal, die interne Systemuhr läuft sowieso immer in UTC. Die Zeit, die Anwendungsprogramme anzeigen, wird immer von UTC auf die selektierte Zeitzone on-demand umgerechnet.

Um dir also diese ganze Mühre mti cron zu ersparen, wäre es wirklich das einfachste, die korrekte Zeitzone einzustellen und nur im Einzelfall (z.B. beim Syslog) eine gesonderte Zeitzone in deren Konfigurationsdatei anzugeben.

Auch, wenn das bei 60 Hosts neu zu konfigurieren wäre, wäre das immer noch das bessere Vorgehen als die bisher eingesetzten Würgarounds.

[Meillo]

Um dir also diese ganze Mühre mti cron zu ersparen, wäre es wirklich das einfachste, die korrekte Zeitzone einzustellen und nur im Einzelfall (z.B. beim Syslog) eine gesonderte Zeitzone in deren Konfigurationsdatei anzugeben.

Auch, wenn das bei 60 Hosts neu zu konfigurieren wäre, wäre das immer noch das bessere Vorgehen als die bisher eingesetzten Würgarounds.

Fuer mich hoert sich das ueberzeugend an. Das Script von mir wuerde ich auch als Workaround ansehen.

Ich denke, dass der Hinderungsgrund ist, dass man in komplexen Systemen dazu neigt, moeglichst kleine und abgegrenzte Aenderungen zu machen, wegen der Unsicherheit, was groessere und grundlegende Aenderungen fuer Auswirkungen haben koennten, die man im Voraus nicht uebersehen kann. Diese Tendenz ist schlecht. Wenn sie beginnt, ist das Ende des Systems schon abzusehen, weil sich die Groesse der Aenderungen immer weiter reduzieren und die Unsicherheit immer weiter zunehmen wird. Eigentlich sollte man dieser Tendenz immer direkt entgegenarbeiten und die grundlegenden Aenderungen machen, weil man nur so das ganze System in einem jugendlich-frischen Zustand halten kann, der auch ueber lange Zeit hinweg flexibel und tragfaehig ist.

[MSfree]

Ich denke, dass der Hinderungsgrund ist, dass man in komplexen Systemen dazu neigt, moeglichst kleine und abgegrenzte Aenderungen zu machen, wegen der Unsicherheit, was groessere und grundlegende Aenderungen fuer Auswirkungen haben koennten,

Da bin ich ganz deiner Meinung.

Der Würgaround hört sich für mich aber nach einem fundamentalen Eingriff in die Betriebssystemfunktionalität an, der viel größere Auswirkungen hat, als eine korrekte Konfiguration mit richtig eingestellter Zeitzone. Daher wäre mein Vorgehen: aufräumen der Konfiguration, entfernen von unnötigem Gefrickel und Betrieb nach der vom OS vorgesehenen Methode.

[paedubucher]

Um dir also diese ganze Mühre mti cron zu ersparen, wäre es wirklich das einfachste, die korrekte Zeitzone einzustellen und nur im Einzelfall (z.B. beim Syslog) eine gesonderte Zeitzone in deren Konfigurationsdatei anzugeben.

Auch, wenn das bei 60 Hosts neu zu konfigurieren wäre, wäre das immer noch das bessere Vorgehen als die bisher eingesetzten Würgarounds.

Ich denke, dass der Hinderungsgrund ist, dass man in komplexen Systemen dazu neigt, moeglichst kleine und abgegrenzte Aenderungen zu machen, wegen der Unsicherheit, was groessere und grundlegende Aenderungen fuer Auswirkungen haben koennten, die man im Voraus nicht uebersehen kann. Diese Tendenz ist schlecht. Wenn sie beginnt, ist das Ende des Systems schon abzusehen, weil sich die Groesse der Aenderungen immer weiter reduzieren und die Unsicherheit immer weiter zunehmen wird. Eigentlich sollte man dieser Tendenz immer direkt entgegenarbeiten und die grundlegenden Aenderungen machen, weil man nur so das ganze System in einem jugendlich-frischen Zustand halten kann, der auch ueber lange Zeit hinweg flexibel und tragfaehig ist.

Das ist ein ausgezeichneter Gedanke! Ich habe diese Entwicklung schon öfters in meinem Berufsleben wahrgenommen. Man zieht sich in eine immer kleiner werdende Nische zurück, weil man sich dort noch sicher fühlt. Das ganze hat sicherlich auch viel mit der vorherrschenden Fehlerkultur in einer Organisation zu tun. Die Änderung von UTC auf CET schafft einen kleinen aber greifbaren Nutzen; die negativen Folgen, wie unwahrscheinlich sie noch sein mögen, bzw. die Aussicht auf solche mögliche Folgen, lässt mich aber vor der Änderung zurückschrecken.

Ich denke, dass der Hinderungsgrund ist, dass man in komplexen Systemen dazu neigt, moeglichst kleine und abgegrenzte Aenderungen zu machen, wegen der Unsicherheit, was groessere und grundlegende Aenderungen fuer Auswirkungen haben koennten,

Da bin ich ganz deiner Meinung.

Der Würgaround hört sich für mich aber nach einem fundamentalen Eingriff in die Betriebssystemfunktionalität an, der viel größere Auswirkungen hat, als eine korrekte Konfiguration mit richtig eingestellter Zeitzone. Daher wäre mein Vorgehen: aufräumen der Konfiguration, entfernen von unnötigem Gefrickel und Betrieb nach der vom OS vorgesehenen Methode.

Ein Kompromiss wäre natürlich der Einsatz einer systemd-Timer-Unit. Hier löst das genau ein Problem, das mit einem Cronjob nur zurechtgebastelt werden kann.

Ich muss mir das ganze noch einmal durch den Kopf gehen lassen...