Hallo miteinander, Jan Ritzerfeld schrieb:
Am Freitag, 30. November 2007 schrieb Christian Pubanz (GMX):
(...).
Über einen nicht-synchronisieren-wollenden ntp gibt es zur Zeit einen Thread auf dem englischsprachigen Pendant zu dieser Liste: http://lists.opensuse.org/opensuse/2007-12/msg00357.html
Und natürlich auch einen Bugreport: https://bugzilla.novell.com/show_bug.cgi?id=344356
Vielleicht hat das ja was mit deinem Problem gemein ...
Jein, es handelt sich wahrscheinlich um 2 Probleme. Vielleicht zunächst einige Informationen zur Funktionsweise von NTP, der Systemzeit, und einigen in diesem Thread gemachten Vermutungen. NTP und hwclock haben zunächst mal nichts miteinander zu tun. Die batteriegepufferte Uhr des Mainboards (RTC oder auch CMOS-Uhr genannt) wird nur benötigt, um die Zeit weiterzuführen, während der Rechner ausgeschaltet ist. Wenn das Betriebssystem bootet, wird die aktuelle Zeit aus der RTC gelesen und damit die Software-Uhr des Betriebssystems initial gesetzt. Das ist bei Linux, Windows und anderen aktuellen Betriebssystemen so. Danach wird normalerweise die Zeit ausschließlich als Software-Uhr weitergezählt, d.h., ein Timer auf dem Mainboard erzeugt periodische Interrupts (Timer Ticks), und bei jedem Tick wird die Zeit um einen gewissen Betrag (tickadj) weitergezählt. Beim Herunterfahren schreibt Linux die aktuelle Software-Zeit wieder zurück in die RTC, siehe Meldungen auf der Konsole. Optional kann der Kernel auch zyklisch z.B. alle paar Minuten die RTC setzen. Die Systemzeit (Software-Zeit) wird als UTC-Zeit (früher auch GMT genannt) geführt. Die auf dem Monitor angezeigte Zeit Ortszeit wird aus der UTC-Zeit berechnet, indem zu der UTC-Zeit ein Offset addiert wird, dessen Wert von der eingestellten Zeitzone abhängt und davon, ob gerade Sommerzeit ist oder nicht. Für Mitteleuropa gilt z.B.: Winterzeit MEZ = UTC + 1h Sommerzeit MESZ = UTC + 2h Unter Linux kann man den Unterschied schön sehen, wenn man an der Konsole eingibt: date; date -u Am sinnvollsten wäre es, wenn die RTC immer auf UTC-Zeit laufen würde, da das Betriebssystem dann einfach die RTC-Zeit als initiale Zeit für die Software-Uhr verwenden könnte, die dann korrekt in Ortszeit umgewandelt werden könnte. Speziell auf Multi-Boot-Systemen mit Windows (z.B. Windows 2000, aktuellere Versionen evt. nicht mehr) wird die RTC oft durch Windows auf die Ortszeit gesetzt. Wenn dann Linux gebootet wird, muss die RTC-Zeit zunächst wieder auf UTC zurückgerechnet werden. openSUSE Linux fragt bei der Installation ab, ob die RTC auf Ortszeit läuft. Um sich Probleme zu ersparen, sollte diese Option nicht markiert werden, es sei denn, ein Dual-Boot mit Windows erfordert es. Probleme mit der falschen Zeit um Beginn/Ende der Sommerzeit herum sind darauf zurückzuführen, dass entweder bei einem Multi-Boot-System das eine Betriebssysteme erwarten, dass die RTC auf Ortszeit läuft, das andere dagegen UTC erwartet, oder generell, dass die RTC auf Ortszeit läuft. Angenommen, am Abend vor der Zeitumstellung auf Winterzeit wird die RTC beim Herunterfahren mit der aktuellen Sommerzeit UTC+2h gesetzt. Am nächsten Morgen wird der Rechner wieder hochgefahren. Die RTC läuft immer noch auf UTC+2h, aber Linux "sieht", dass bereits Winterzeit ist, erwartet UTC+1h und stellt somit seine initiale Zeit um 1h verkehrt. Wenn die RTC auf UTC läuft und die Linux-Einstellung dem entspricht, können solche Probleme nicht auftreten. Zurück zur Software-Uhr und NTP. Der Quarz auf dem Mainboard, der den Timer für die Software-Uhr antreibt, weicht immer mehr oder weniger von seiner Sollfrequenz ab, d.h. die Systemzeit driftet mehr oder weniger schnell weg. Die Frequenzabweichung ist zudem stark temperaturabhängig. NTP holt sich in bestimmten Abständen die Zeit von einer Referenzzeitquelle, bestimmt dabei den Zeitoffset und auch die Frequenzabweichung, und versucht, beide so gut wie möglich zu kompensieren. Als Referenzzeitquelle kommen dabei sowohl Funkuhren/GPS-Empfänger in Frage, als auch ein oder mehrere NTP-Server im Netzwerk. Bei Letzteren versucht NTP, so gut es geht die Paketlaufzeit zu ermitteln und zu kompensieren. Ob dabei direkt die NTP-Server der PTB angesprochen werden oder die Pool-Server, spielt für die Funktionsweise grundsätzlich keine Rolle. Eine Ausnahme ist natürlich, wenn ein Pool-Server nicht korrekt arbeitet. Durch Verwendung mehrere Poolserver wie bei openSUSE 10.3 üblich wird ein "Falseticker" durch den NTP-Daemon erkannt und ignoriert. Wichtig ist, dass sich die Zeitquelle als "synchron" zu erkennen gibt, da sie sonst durch die Clients nicht akzeptiert wird. Als Zusatzfunktion arbeitet ntpd standardmäßig auch als Server, d.h. er kann seine synchronisierte Systemzeit anderen NTP-Clients im Netz zu Verfügung stellen. Um den "Abstand" zur obersten Zeitquelle anzugeben, wird der "Stratum"-Wert verwendet. Stratum-1-Server sollten eine möglichst genaue Funkuhr als Zeitquelle zur Verfügung haben. Ein Rechner, der sich auf einen Stratum-1-Server synchronisiert, wird selbst zum Stratum-2-Server, usw. Da die Weiterführung der Systemzeit im Kernel erfolgt, kann der NTP-Daemon lediglich die Korrekturwerte bestimmen. Die ermittelten Differenzen zu den Zeitquellen werden dabei durch einen ausgeklügelten Filteralgorithmus geschickt, um Ausreißer zu identifizieren und zu verwerfen. Die gefilterten Korrekturwerte werden dann an den Kernel übergeben, der dafür zuständig ist, diese anzubringen und damit die Systemzeit nachzuführen. Auf diese Weise wird die Frequenzdrift kontinuierlich derart kompensiert, dass größere Zeitabweichungen gar nicht erst auftreten. Auf welche Weise das geschieht, hängt davon ab, welches Timer Tick-Intervall verwendet wird, welcher Timer des Mainboards verwendet wird, ob der Timer durch den Kernel vollständig und korrekt unterstützt wird, usw. Bei aktuellen Chipsätzen kann es damit Probleme geben, wenn z.B. aus Energiespargründen der Takt der CPU oder des Timers heruntergesetzt wird und das beim Anbringen der Korrektur nicht korrekt berücksichtigt wird. Die ermittelte Frequenzabweichung speichert ntpd optional in dem sogenannten Driftfile, damit er beim nächsten Start wieder eingelesen werden kann und damit die Sychronisierung beschleunigt wird. Der absolute Wert im Driftfile gibt keinen Aufschluß über die Genauigkeit der Zeitnachführung, sondern zeigt lediglich, wie weit die tatsächliche Taktfrequenz des Timers vom Sollwert abweicht. Hierbei handelt es sich um ein Merkmal dieses individuellen Quarzes, d.h. er unterscheidet sich von einem Board zum anderen, je nach Quarz. Wenn die dauerhafte Zeitsynchronisierung mit einer älteren Linux-Version problemlos funktioniert hat, mit der aktuellen Version auf der gleichen Hardware aber nicht, ist das ein Indiz für unzureichende Unterstützeung des verwendeten Timers durch den Kernel. Gerade um 2.6.21 herum wurde der Timer-Code im Kernel stark verändert. Hinweise auf sderartige Probleme sind Jan's zitierte Quellen (s.o.) oder auch entsprechende Meldungen in der NTP-Newsgroup, z.B.: http://groups.google.de/groups?as_epq=opensuse+10.3&as_ugroup=comp.protocols.time.ntp Zum Problem mit NTP beim Booten von openSUSE 10.3: Es handelt sich dabei um ein Problem mit den Init-Scripten. Siehe auch: https://bugzilla.novell.com/show_bug.cgi?id=337075 Der NTP-Daemon beendet sich selbst mit einer entsprechenden Meldung im Syslog, wenn sich die Systemzeit von der Referenzzeit um mehr als ca. 1000 Sekunden unterscheidet. Da das in der Vergangenheit zu Problemen führte, wenn die initiale Systemzeit gänzlich falsch war, wurde oft vor dem Start des ntpd das Hilfsprogramm ntpdate ausgeführt, um die Systemzeit grob richtig zu setzen, bevor ntpd gestartet wurde, so dass die Grenze nicht überschritten werden konnte. Bereits vor einiger Zeit wurde der NTP-Daemon jedoch um einen Kommandozeilen-Parameter "-g" erweitert, der es erlaubt, dass die genannte Grenze nach dem Start einmalig überschritten werden darf, ohne dass ntpd sich beendet. Wenn dieser Parameter beim Start verwendet wird, ist der Aufruf von ntpdate daher überflüssig. Um die anfängliche Synchronisierung mit den externen NTP-Servern zu beschleunigen, kann weiterhin in der Datei /etc/ntp.conf die zu verwendenden Zeitserver mit dem Keyword "iburst" eingetragen werden, z.B.: server 0.pool.ntp.org iburst Wenn dieses Keyword verwendet wird, sendet ntpd zu Beginn mehrere Anfragen in kurzen Abständen an den Server, um den oben erwähnten Filter schneller aufzufüllen. Im Fall von openSUSE 10.3 wird standardmäßig noch ntpdate zur initialen Synchronisierung verwendet, wenn das Script rcntp aufgerufen wird, um den Dienst zu starten. Der erste Aufruf erfolgt dabei bereits, nachdem das Loopback-Interface initialisiert wurde, andere Netzwerk-Interfaces jedoch noch nicht. Da zu diesem Zeitpunkt keine Namensauflösung per DNS möglich ist, kann ntpdate nicht funktionieren. Später im Bootvorgang wird ntpd nochmals gestartet. Wie es aussieht, wird das rcntp-Script bei jedem "ifup" aufgerufen, um sicherzustellen, dass ntpd die Interfaces verwenden kann. Wieder wird zunächst ntpdate ausgeführt, anschließend ntpd gestartet. Dabei kann es passieren, dass eine frühere Instanz von ntpdate oder ntpd noch aktiv ist, so dass sich ntpd mit einer Fehlermeldung "another process may be running" beendet. Dadurch kann es passieren, das ntpd am Ende des Bottvorgangs nicht mehr läuft. Im Gegensatz zu früheren Versionen erkennt die aktuelle Version von ntpd jedoch auch Netzwerk-Interfaces, die nach seinem Start zur Verfügung gestellt werden. Dazu scannt ntpd zyklisch die vorhandenen Interfaces, man kann den Vorgang jedoch leider (noch) nicht durch ein externes Script auslösen. Um den Bootvorgang von openSUSE 10.3 (zumindest bei Verwendung von ifup) bezüglich ntpd zu verbessern, kann man nach meinen Erkenntnissen folgende Maßnahmen durchführen: 1.) Verhindern, dass ntpd bei jedem "ifup" neu gestartet wird 2.) Statt "ntpdate" aufzurufen, die Option "-g" verwenden 3.) Scan-Intervall für Interfaces auf kleinsten Wert ("-U 60") 4.) "iburst"-Keyword für server verwenden Für 1.) wird ein symbolischer Link in der Konfiguration für if-up gelöscht: rm /etc/sysconfig/network/if-up.d/50-ntp Für 2.) und 3.) wird die Datei /etc/sysconfig/ntp modifiziert und die angegebenen Einträge wie folgt geändert. NTPD_INITIAL_NTPDATE="" NTPD_OPTIONS="-g -U 60 -u ntp" Für 4.) wird in der Datei /etc/ntp.conf das Wort "iburst" an jede Server-Zeile gehängt, z.B.: server 0.pool.ntp.org iburst server 1.pool.ntp.org iburst server 2.pool.ntp.org iburst Ich würde mich freuen, wenn Ihr das auch testen könntet und mal schreibt, ob es für Euch ebenso funktioniert. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org