Zeitsynchronisation unter Debian Etch mit chrony
PCs speichern ihre Uhrzeit mithilfe eines kleinen Chips: der Realtime Clock (RTC). Häufig ist dies ein sehr billiges Bauteil, das keine hohe Genauigkeit bietet. Läuft so ein Server nun einige Monate, weicht die Uhrzeit stark von der tatsächlichen Uhrzeit ab.
Wer viele mehrere Server zu administrieren hat, muss aber überall die richtige Uhrzeit haben um vernünftig mit Logfiles oder Backups arbeiten zu können. Linux bietet hier verschiedene Lösungen, um die Zeit übers Internet zu synchronisieren. Die bekannteste ist mit Sicherheit der NTP Daemon. Nachteil ist, dass hier die Zeit auf einen Schlag auf die richtige Uhrzeit gebracht wird. Dadurch kann es zu seltsamen Erscheinungen im System und lückenhaften Logfiles kommen. Das Tool chrony schafft hier Abhilfe, indem die Zeitdifferenz langsam ausgeglichen wird.
Unter Debian lässt sich chrony ganz einfach über das Paketmanagement installieren:
[sourcecode language="css"]aptitude install chrony[/sourcecode]
Schon startet der chrony Daemon und vergleicht die Systemzeit mit einem zufälligen NTP Server im Internet. Gleich darauf wird die Differenz festgestellt und der Angleichungsprozess gestartet. Dies sieht im Log wie folgt aus:
[sourcecode language="css"]chronyd version 1.21 starting
Initial txc.tick=10000 txc.freq=0 (0.00000000) txc.offset=0 =>
hz=100 shift_hz=7
set_config_hz=0 hz=100 shift_hz=7 basic_freq_scale=1.28000000
nominal_tick=10000 slew_delta_tick=833 max_tick_bias=1000
Linux kernel major=2 minor=6 patch=18
calculated_freq_scale=0.99902439 freq_scale=0.99902439
Could not open driftfile /var/lib/chrony/chrony.drift for reading
Source 212.93.228.69 online
Source 82.135.28.90 online
Source 82.230.52.122 online
Selected source 212.93.228.69
System clock wrong by 716.992200 seconds, adjustment started
Selected source 82.135.28.90[/sourcecode]
Nach kurzer Zeit ist die Zeit angepasst und stimmt mit der tatsächlichen überein. Der Daemon prüft regelmäßig die aktuelle Zeit und passt diese gegebenenfalls an.
Links:
chrony Homepage
Interessanter Artikel zum Thema: Hilfe, bei mir tickt es nicht richtig!
Der Adminblogger
Das ist so nicht korrekt, dass der ntpd die Uhrzeit nicht langsam angleichen kann.
Standardmässig wird die Uhrzeit hart gesetzt, wenn die Abweichung zu gross ist, man kann aber auch den Schwellenwert konfigurieren.
Ich nutze die Kombination aus ntpd und ntpdate – beim Bootvorgang wird die Uhrzeit hart gesetzt via ntpdate und im laufenden Betrieb von ntpd immer wieder angepasst.
Es geht also auch ohne chrony
Gruss,
Marcel.
matthias
Ok, das mag sein. Aber chrony macht es halt in der Standardkonfiguration bereits out-of-the-box und ich hab ja auch nirgends geschrieben, dass ntpd das nicht kann
Hast du mal irgendwo eine kurze Anleitung oder die passende Config-Zeile zur Hand? Ich würd das dann ganz gerne noch mit aufnehmen in den Beitrag. Danke!
morph
Man kann den ntpd sicherlich mit Schwellenwert konfigurieren, obwohl ich das noch nie wirklich gebraucht habe.
Mein Problem war jedoch immer, dass der Daemon nach einer gewissen Zeit fehlerhafte Anftragen an die Zeitserver abgesetzt hat, die dann mit Invalid Argumentzurückgewiesen wurden. So musste ich den ntpd-server dann per cron.daily stoppen und wieder neu starten, was ich aber für eine sehr unsaubere Lösung halte.
Ich werde mir diesen chrony einmal anschauen.
matthias
Stoppen und wieder neu starten per Cronjob ist ja auch keine Lösung. Ich mag solche hingefummelten Lösungen auf Dauer nicht, da diese nicht die Ursache bekämpfen. Zwar hab ich das hier und da auch schon mal gemacht, um kurzzeitig das Problem zu “lösen”, aber auf Dauer ist doch eine saubere und echte Lösung besser.
Und bisher hatte ich mit chrony noch keine Probleme
Cryptronic
ich nehm da doch immer das noch einfachere ntpdate:
$ ntpdate rrzntp.uni-regensburg.de wrzx03.rz.uni-wuerzburg.de
und für cron dann mit
$ ntpdate -s rrzntp.uni-regensburg.de wrzx03.rz.uni-wuerzburg.de
fg
Craig
Von “langsamer Angleichung” der Zeit halte ich nichts, die Logfiles sind dann noch weniger aussagekräftig als wenn man eine “harte” Zeitänderung hat, wenn man nämlich die Zeitdifferenz im Log stehen hat, kann man notfalls zurückrechnen.
Wenn die interne Uhr so schlecht ist, dass sie bereits nach mehreren Stunden Abweichungen hat, sollte man vielleicht alle 10 Minuten synchronisieren. Manche Distributionen haben auch totale Zeitprobleme, wenn man sie in VMWare laufen läßt, ist ziemlich “tricky” (wie Matze sagen würde) das richtig hinzubekommen, denn die Uhr geht schon nach ein paar Sekunden falsch!
Ich verwende privat auch nptdate, in der Firma xntpd (SLES), habe auch einen Synchronisationsserver mit DCF77-Funkuhr aufgesetzt *gg
matthias
Diese langsame Zeitangleichung geschieht in der Regel ja nur einmal bei der größten Abweichung. Danach wird immer wieder die Uhrzeit des Systems mit der eines NTP Servers verglichen. Hierbei sind die Zeitabstände aber nicht mehr so extrem, so dass eine Verfälschung nicht mehr stattfindet.
Nunja, einig sind wir uns ja alle: Zeitsynchronisierung ist wichtig. Aber wie immer führen viele Wege nach Rom, chrony ist einer davon
morph
Bezugnehmend auf Craigs Post, muss ich sagen: “Das VMWare Problem kenne ich.”
Den Zeitrahmen von “zehn” würde ich sogar auf fünf Minuten herunterschrauben! Vor allem dann, wenn mehrere virtuelle Maschinen auf einem Server laufen.
Ich muss aber auch gestehen, dass ich schlussendlich auf Xen umgestiegen bin.
Johannes
Hi
Das VMWare Problem kenn ich auch, kommt aber nur bei Gast-Systemen mit 2.6er Kernel vor.
Man kann dem aber mit ein paar Boot-Optionen gegensteuern.
Aber wie gesagt, ntpdate im Cron wirkt wunder
Craig
Die Boot-Optionen helfen aber leider nicht bei allen Kerneln, das hatte ich (natürlich) schon versucht.
Zum Thema XEN: wir überlegen in der Firma auch umzusteigen, ich habe extra einen neuen Desktop (Core 2 Duo E6600, 2GB RAM) bekommen um damit umfangreiche Test durchzuführen. Bisher habe ich nur ein Windows XP virtualisiert, das lief aber wirklich EXTREM gut, sogar einiges schneller als auf den meisten unserer “Standart”-Desktops; ich muss sagen, ich bin schon sehr beeindruckt!
sunny_admin
Am besten ist es, wenn man den Zeitversatz mit ntpdate “hart” abgleicht und anschließend den ntpd laufen lässt, dem mindestens zwei Zeitserver aus dem Inet bekannt sind. (Noch besser ist natürlich ein Gerät das das DCF77 Signal direkt abgreift.)
matthias
Mittlerweile nutze ich auch auf den meisten Maschinen ntpdate (insbesondere unter FreeBSD). So hat man überall die gleiche Software.
Für mich reicht die Genauigkeit eines NTP Servers vollkommen aus – DCF77 Signal benötige ich nicht