ntpd stellt Uhrzeit nicht ein

Herakles

Herakles

Profifragensteller
Moin!

Der ntpd läuft auf meinem OpenBSD 5.3 nicht korrekt. Die Zeit hängt um fast einen Tag daneben. Siehe folgende Einträge in /var/log/daemon am 30.06.2015 um ca. 9:20 Uhr:

Code: 
(...)
May 29 18:53:05 little-willie ntpd[15072]: adjusting local clock by 2729882.686803s
May 29 18:53:20 little-willie dhcpd[7091]: DHCPDISCOVER from 84:eb:18:93:7c:17 via vr2
May 29 18:53:20 little-willie dhcpd[7091]: DHCPOFFER on 192.168.123.216 to 84:eb:18:93:7c:17 via vr2
May 29 18:53:20 little-willie dhcpd[7091]: DHCPREQUEST for 192.168.123.216 from 84:eb:18:93:7c:17 via vr2
May 29 18:53:20 little-willie dhcpd[7091]: DHCPACK on 192.168.123.216 to 84:eb:18:93:7c:17 via vr2
May 29 18:53:36 little-willie ntpd[15072]: adjusting local clock by 2729882.546189s

Die Zeit stimmt nicht, und er versucht zwei mal die Uhrzeit anzupassen, bekommt das aber offenbar nicht hin. Die aktuelle Information hinsichtlich des Datums lautet wie folgt:

Code: 
# date
Fri May 29 19:06:40 CEST 2015

In der Prozesstabelle taucht der ntpd auf:

Code: 
27419 ??  Ss  0:36.55 ntpd: ntp engine (ntpd)
29914 ??  Is  0:00.05 ntpd: dns engine (ntpd)
15072 ??  Is  0:01.14 ntpd: [priv] (ntpd)

In der /etc/ntpd.conf findet sich folgendes:

Code: 
listen on *
server 0.de.pool.ntp.org
server 1.de.pool.ntp.org
server 2.de.pool.ntp.org
server 3.de.pool.ntp.org

Wo könnte mein Fehler liegen?

Viele Grüße
Herakles
 
Die Differenz ist zu groß. ntp darf iirc die Zeit nur anpassen, wenn es 1 oder 2 Stunden sind. Setze einmal die Zeit manuell, dann sollte ntp funktionieren.

HTH
 
Das hatte ich mir gedacht. Nur leider geschieht das immer wieder. Ich stelle dann manuell die Zeit ein und nach einigen Woche ist es wieder schief.

Andere Ideen?
 
Noch was: Ich habe vor einer guten halben Stunde die Zeit mal manuell per "date" neu gestellt. Seitdem stellt er die Zeit alle paar Minuten neu - und zwar um einen nicht unerheblichen Faktor:

Code: 
Jun 30 11:16:50 little-willie ntpd[15072]: adjusting local clock by 12.114205s
Jun 30 11:18:24 little-willie ntpd[15072]: adjusting local clock by 23.742498s
Jun 30 11:22:07 little-willie ntpd[15072]: adjusting local clock by 22.658072s
Jun 30 11:25:18 little-willie ntpd[15072]: adjusting local clock by 21.727910s
Jun 30 11:27:22 little-willie ntpd[15072]: adjusting local clock by 21.140235s
Jun 30 11:30:00 little-willie ntpd[15072]: adjusting local clock by 20.365507s
Jun 30 11:33:43 little-willie ntpd[15072]: adjusting local clock by 19.302027s
Jun 30 11:40:24 little-willie ntpd[15072]: adjusting local clock by 17.374332s
 
Ich tippe darauf, dass ein Hardwaredefekt vorliegt. Es ist jedenfalls nicht normal, dass nach 7 Minuten die Zeit um 20 Sekunden falsch geht.
 
Stoppe den ntpd einmal, lösche /var/db/ntpd.drift und starte ntpd wieder. Achte darauf, dass ntpd_flags="-s" in /etc/rc.conf.local ist.

Wenn dann immer noch die großen Sprünge auftreten, scheint wirklich was defekt zu sein.

Edit: ntpq ist Teil des "offiziellen" ntpd. OpenBSD verwendet OpenNTPD und hat das nicht. Stattdessen gibt es ntpctl -s all, welches den Status anzeigt.
 
@Rob: Das ist keine VM, sondern ein ALIX-Board, wie von TCM mit dem Hinweis auf die vr2 schon angedeutet.

@TCM: Ich würde gern den "ntpctl -s all"-Befehl absetzen, den kennt das System aber ebensowenig. Und ja, "-s" ist in den Startoptionen drin...
 
Die Timecounter der Alix-Boards waren noch nie die besten und inzwischen kommen die Schaltungen merklich in die Jahre. Der korrekte Weg in solchen Situationen ist, die Abweichung zwischen angegebenen und realen Takt des Timecounter soweit wie möglich händisch vorzukorrigieren und NTP lediglich die letzten Nanosekunden zu überlassen. Ich habe keine Ahnung, wie es unter OpenBSD geht. Unter FreeBSD würde man die Ungenauigkeit bestimmen, beispielsweise über den "Drift" des NTP-Clients. Anschließend lässt man sie Taktrate des Timecounter in Hertz ausgeben, zum Beispiel "sysctl kern.timecounter.tc.HPET.frequency". Nun kann man ausrechnen, um wie viel die angegebene Taktrate von der Realität abweicht. Daraus bestimmt man den realen Takt und schreibt ihn in das Sysctl.

Bevor man sich so einen Aufwand macht, kann man allerdings erst einmal probieren, ob ein anderer Timecounter vielleicht hilft. Die x86-CPU/Plattform hat davon ja gleich eine ganze Reihe, wovon zumindest HPET, ACPI-fast und TSC-low grundsätzlich in Ordnung sind. In der Praxis wird Taktsignal aber oft aus einer Quelle auf alle Timecounter verteilt, weshalb sie ähnliche Abweichungen besitzen.
 
Herakles schrieb:
@TCM: Ich würde gern den "ntpctl -s all"-Befehl absetzen, den kennt das System aber ebensowenig. Und ja, "-s" ist in den Startoptionen drin...
Zum Vergrößern anklicken....

Das kam dann wohl nach 5.3.

Ich habe selber zwei ALIX-Boards, die seit nem knappen Jahrzehnt klaglos tun sowie ein WRAP, wo ich solche Probleme auch noch nie gesehen hab.

Hat das Board eine Batterie? (Meine haben allesamt keine)

Edit: Ansonsten hilft nur PCEngines fragen, ob die dazu was wissen.
 
Hallo in die Runde!

Ich habe mich mit Absicht einige Tage lang nicht mehr gemeldet, um den Fortgang des Systems weiter zu beobachten. Stand heute: Es gibt gar keine Einträge zum ntpd mehr in /var/log/daemon und die Uhrzeit stimmt ebenfalls.

Warum das vor einer Woche so war wie beschrieben und wieso das jetzt nicht mehr so auftritt - keine Ahnung!

Danke jedenfalls für Eure Hinweise, ich werde das weiterhin im Auge behalten.

Viele Grüße
Herakles
 
Auch keine "adjusting clock frequency by ..."? Das wäre auch wieder merkwürdig.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben