Hallo Leute!
Bei mir zu Hause ist auf dem Gateway (Debian Linux) einen NTP-Server für die ganze Geräte im Haus installiert. Mein Rechner, wie die andere, nutzt also diesen NTP-Server.
Seit gestern habe ich plötzlich das Problem, dass die Zeit des PCs rennt und innerhalb von wenigen Stunden ist der Unterschrieb zum NTP-Server mehrere Minuten. Auch die Nutzung von öffentlichen NTP-Servern hat nichts gebracht.
Im Log finde ich oft:
Aug 9 22:02:21 localhost ntpd[26890]: kernel reports TIME_ERROR: 0x4041: Clock Unsynchronized
Sonst nichts anderes...
Hat jemand eine Ahnung, was es passiert ist und wie ich das lösen kann? Wie gesagt, es ist plötzlich passiert, zum allerersten Mal und ich habe an der Konfiguration von NTP seit lange nichts geändert...
Danke Luca Bertoncello (lucabert@lucabert.de)
Am Donnerstag, 10. August 2023, 07:34:04 CEST schrieb Luca Bertoncello:
Hallo Leute!
Bei mir zu Hause ist auf dem Gateway (Debian Linux) einen NTP-Server für die ganze Geräte im Haus installiert. Mein Rechner, wie die andere, nutzt also diesen NTP-Server.
OK.
Seit gestern habe ich plötzlich das Problem, dass die Zeit des PCs rennt und innerhalb von wenigen Stunden ist der Unterschrieb zum NTP-Server mehrere Minuten.
vermutlich besser: _eines_ PC. (Was machen andere Rechner?)
Aug 9 22:02:21 localhost ntpd[26890]: kernel reports TIME_ERROR: 0x4041: Clock Unsynchronized
Sonst nichts anderes...
Hat jemand eine Ahnung, was es passiert ist und wie ich das lösen kann? Wie gesagt, es ist plötzlich passiert, zum allerersten Mal und ich habe an der Konfiguration von NTP seit lange nichts geändert...
Ich vermute ein Hardwareproblem des betroffenen Rechners. Die Zeit wird von einer "hochfrequenten" Quelle gestützt (TSC, HPET ...) und über NTP korrigiert. Kernelinterne Uberwachungen stellen (besonders beim Booten) sicher, dass diese Quelle wenigstens einigermaßen zuverlässig ist. Also spielte vermutlich die Quelle verrückt und diese Überwachung hat zugeschlagen. Der Workaround wäre eine (andere, bessere) Quelle (per Kernel-Bootoption?) festzulegen. (Ich habe hier und jetzt keinen Zugriff auf die Kernelquellen.) Manchmal hiflt bei bekannten Hardware-Quirks auch ein neuerer Kernel.
Bernhard
Danke Luca Bertoncello (lucabert@lucabert.de)
Am 10.08.2023 um 09:02 schrieb Bernhard Schiffner:
Moin!
Seit gestern habe ich plötzlich das Problem, dass die Zeit des PCs rennt und innerhalb von wenigen Stunden ist der Unterschrieb zum NTP-Server mehrere Minuten.
vermutlich besser: _eines_ PC. (Was machen andere Rechner?)
Die andere Rechner (gleiches System, gleiche Kernel!) funktionieren einwandfrei...
Ich vermute ein Hardwareproblem des betroffenen Rechners.
Mist... die Kiste ist nagelneu...
Die Zeit wird von einer "hochfrequenten" Quelle gestützt (TSC, HPET ...) und über NTP korrigiert. Kernelinterne Uberwachungen stellen (besonders beim Booten) sicher, dass diese Quelle wenigstens einigermaßen zuverlässig ist. Also spielte vermutlich die Quelle verrückt und diese Überwachung hat zugeschlagen. Der Workaround wäre eine (andere, bessere) Quelle (per Kernel-Bootoption?) festzulegen. (Ich habe hier und jetzt keinen Zugriff auf die Kernelquellen.) Manchmal hiflt bei bekannten Hardware-Quirks auch ein neuerer Kernel.
Jetzt, dass du das sagst, die Probleme kamen seit einer Kernelaktualisierung, von 4.19.0-24 nach 4.19.0-25... Aber, wie gesagt, die andere Rechner, immer mit dem Kernel 4.19.0-25, haben keine Probleme... Der Hardware ist allerdings nicht gleich...
Danke Luca Bertoncello (lucabert@lucabert.de)
Manche Programme (z.B. hwclock, ntpd) versuchen, das driften der Uhren auszugleichen. Wenn hier falsche Werte in den entsprechenden Konfigurationsdateien eingetragen sind, wird falsch korrigiert (z.B. hwclock) oder der Taktgeber falsch konfiguriert (z.B. ntpd). Ich weiß jetzt nicht, was Du alles installiert hast. Es lohnt sich auf alle Fälle, sämtliche Konfigurationen auf Driftkorrekturen abzusuchen.
Am 10.08.23 um 09:07 schrieb Luca Bertoncello:
Am 10.08.2023 um 09:02 schrieb Bernhard Schiffner:
Moin!
Seit gestern habe ich plötzlich das Problem, dass die Zeit des PCs rennt und innerhalb von wenigen Stunden ist der Unterschrieb zum NTP-Server mehrere Minuten.
vermutlich besser: _eines_ PC. (Was machen andere Rechner?)
Die andere Rechner (gleiches System, gleiche Kernel!) funktionieren einwandfrei...
Ich vermute ein Hardwareproblem des betroffenen Rechners.
Mist... die Kiste ist nagelneu...
Die Zeit wird von einer "hochfrequenten" Quelle gestützt (TSC, HPET ...) und über NTP korrigiert. Kernelinterne Uberwachungen stellen (besonders beim Booten) sicher, dass diese Quelle wenigstens einigermaßen zuverlässig ist. Also spielte vermutlich die Quelle verrückt und diese Überwachung hat zugeschlagen. Der Workaround wäre eine (andere, bessere) Quelle (per Kernel-Bootoption?) festzulegen. (Ich habe hier und jetzt keinen Zugriff auf die Kernelquellen.) Manchmal hiflt bei bekannten Hardware-Quirks auch ein neuerer Kernel.
Jetzt, dass du das sagst, die Probleme kamen seit einer Kernelaktualisierung, von 4.19.0-24 nach 4.19.0-25... Aber, wie gesagt, die andere Rechner, immer mit dem Kernel 4.19.0-25, haben keine Probleme... Der Hardware ist allerdings nicht gleich...
Danke Luca Bertoncello (lucabert@lucabert.de)
Am 10.08.2023 um 14:50 schrieb Tobias Schlemmer:
Hallo Tobias
Manche Programme (z.B. hwclock, ntpd) versuchen, das driften der Uhren auszugleichen. Wenn hier falsche Werte in den entsprechenden Konfigurationsdateien eingetragen sind, wird falsch korrigiert (z.B. hwclock) oder der Taktgeber falsch konfiguriert (z.B. ntpd). Ich weiß jetzt nicht, was Du alles installiert hast. Es lohnt sich auf alle Fälle, sämtliche Konfigurationen auf Driftkorrekturen abzusuchen.
Wie gesagt, die Konfiguration der Programme hat sich nicht geändert... Hier mein ntp.conf:
---------------------- driftfile /var/lib/ntp/ntp.drift
statistics loopstats peerstats clockstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable
server gw.lucabert.intra iburst
restrict -4 default kod notrap nomodify nopeer noquery restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1 restrict ::1 ---------------------- Ist es falsch? Auf den anderen Rechner im Netz ist die Datei identisch und dort habe ich kein Problem...
Grüße Luca Bertoncello (lucabert@lucabert.de)
Am 10.08.2023 um 15:07 schrieb Tobias Schlemmer:
Am 10.08.23 um 15:02 schrieb Luca Bertoncello:
driftfile /var/lib/ntp/ntp.drift
Was steht in /var/lib/ntp/ntp.drift? Hast Du diese Datei mal umbenannt?
Bei mir steht aktuell (15 Minuten nach einem Neustart von NTP!):
lucabert@frodo:~$ cat /var/lib/ntp/ntp.drift 3.440
Und schon sind 6 Sekunden Unterschied zu den anderen Rechner im Netz... :/
Grüße Luca Bertoncello (lucabert@lucabert.de)
lug-dd@mailman.schlittermann.de
-
Bernhard Schiffner -
Luca Bertoncello -
Tobias Schlemmer