Am 13.02.2018 um 18:26 schrieb Handwerker, Jan (IMK):
Hallo Dirk,
beim heiteren Ursachen-Raten möchte ich mitmachen: Mich hat ntp mal überrascht, indem es _nicht_ synchronisierte, weil die Uhrzeit zu sehr (mehr als 15 min.) von der Rechneruhrzeit abwich. Sprich: Kleine Abweichungen korrigiert es, bei größeren glaubt es, es gäbe einen vernünftigen Grund für die Abweichung und synchronisiert deshalb die Uhrzeit nicht.
Ich weiß nicht mehr, ob es dafür eine lesbare Fehlermeldung gab. Ich erinnere mich nur noch blass, aber wenn's hilft, wär es ja nett :-).
Das Standard-Verhalten des ntpd ist: 1.) Wenn die Abweichung kleiner ist als 128 ms, wird die Systemzeit weich nachgeführt. Das sollte der Regelfall sein im laufenden Betrieb. 2.) Wenn die Abweichung größer ist als 128 ms, aber kleiner als 1000 s (der sogenannte "panic threshold"), wird die Systemzeit hart gesetzt. Allerdings erst, wenn die Abweichung 900 Sekunden (= 15 Minuten) lang anhält. 3.) Wenn die Abweichung größer ist als 1000 s, beendet sich der ntpd mit einer Fehlermeldung, die sinngemäß sagt, man solle die Systemzeit erstmal grob richtig setzen. "Früher" hat man dazu einmal "ntpdate" aufgerufen, bevor ntpd als Daemon gestartet wurde. Wenn ntpd neu gestartet wird und Parameter -g angegeben wurde, wird 3.) einmalig außer Kraft gesetzt, um auch bei einer initialen größeren Zeitabweichung die Systemzeit richtig zu setzen, so dass normalerweise bereits eine Genauigkeit unter 128 ms erreicht wird und man sich den Aufruf des "ntpdate" vorher spart. Mit "iburst" in der Konfiguration geht das auch recht schnell. Nur wenn *danach* nochmal eine größere Zeitabweichung auftritt, z.B. weil "root" die Systemzeit verstellt, um ntpd zu "testen", treten Fälle 2.) oder 3.) auf. Wenn die "refid" in der Ausgabe von "ntpq -pn" auf ".INIT." steht, bedeutet das, dass ntpd keine Antwort von dieser Zeitquelle bekommt, wenn ntpd die Zeitquelle erstmalig kontaktiert. Da das hier für *alle* konfigurierten NTP-Server der Fall ist, hört sich das für mich nach einem Firewall-Problem an, da von keinem server eine Antwort eintrifft.. Im Prinzip könnte es auch ein Routing-Problem sein, aber wenn ein "ping" auf die externen Server funktioniert, trifft das wohl hier nicht zu. Es wäre auch sinnvoll, mit "journalctl" nach Log-Ausgaben von ntpd zu sehen. Leider (IMO) spezifiziert Suse ja in ntp.conf ein "alternate logfile", so dass Startup-Meldungen im Syslog landen, aber weitere Meldungen des ntpd ggf. in /var/log/messages. Fürs Debugging wäre es IMO sinnvoll, die Zeile "logfile" auszukommentieren und dafür das Kommentarzeichen vor "logconfig =all" zu entfernen, um soviele Meldungen wie möglich über einen einzigen Weg (journalctl) zu bekommen. Wenn es sich aber tatsächlich um ein Firewall-Problem handelt, kommen entweder die Antworten der einzelnen Server nicht beim lokalen ntpd an, oder die Anfragen des ntpd erreichen noch nicht einmal die einzelnen Server. Da gibt es dann wohl keine hilfreichen Log-Meldungen. Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org