NTP läuft nicht

[starwarsfan]

N'abend miteinander,

es wäre mir völlig neu, dass die Fritzbox Ports von innen nach aussen blockiert, das ist im Consumer-Umfeld absolut unüblich.

Anyway, /etc/ntp.conf sieht völlig korrekt aus. Was sagt denn

# service ntpd status

bei Dir? Sollte in etwa so aussehen:

# service ntpd status
ntpd (pid 1513) is running...

Auf welcher Umgebung resp. Hardware läuft denn Edomi bei Dir? Wie steht es um die Echtzeituhr des Systems? Was sagt das BIOS, wie spät es ist? Hintergrund der Frage ist, dass sich ntp bei sehr stark abweichenden Uhren durchaus beenden kann, da es nicht mehr möglich ist, die Zeit so anzugleichen, wie das ntp normalerweise tut. Der ntp-Dienst funktioniert so, dass er die interne Uhr des Systems gewissermassen langsamer oder schneller laufen lässt, um so die eigene Zeit an die Referenzzeiten anzugleichen. Damit hat man keine Sprünge in der eigenen Zeit, da der Angleich langsam und nicht schlagartig erfolgt. Wenn nun die Abweidung gross genug ist, wird dieser dynamische Abgleich nicht funktionieren und ntp beendet sich. Genau aus diesem Grund sollte der ntp-Dienst zunächst auch beendet werden, wenn man die Uhr von Hand stellen möchte.

[tger977]

also ntpd läuft:

/var/lib/ntp$ service ntpd status
ntpd (PID  1474) wird ausgeführt ...

EDOMI läuft auf einem S900. Der manuelle Abgleich mit parameter -u funktioniert auch:

/var/lib/ntp$ ntpdate -u pool.ntp.org
19 Feb 22:10:59 ntpdate[14908]: adjust time server 144.76.96.7 offset -0.269793 sec

ohne -u Parameter:

/var/lib/ntp$ ntpdate pool.ntp.org
19 Feb 22:15:10 ntpdate[17790]: the NTP socket is in use, exiting

Damit sollte die BIOS Zeit auch gleich sein, oder? Ich verstehs nicht was da schief läuft

[wintermute]

Damit sollte die BIOS Zeit auch gleich sein, oder? Ich verstehs nicht was da schief läuft

Nae, die BIOS Zeit (also die Hardware Clock) wird mittels "hwclock" gesetzt, das macht der ntpd normal nicht von allein. Vor allem wirds aber beim (sauberen) Runterfahren gemacht....

[chrisi]

Der Eintrag "fritz.box" (nutze eine Fritzbox 7390) hat leider auch keine Abhilfe gebracht. Steht genauso auf INIT...

Trag mal statt "fritz.box" die IP-Adresse der Fritzbox ein und starte dann ntp neu oder besser noch reboote das System wo Edomi oben läuft.
Die IP der Fritzbox sollte das Standardgateway für deine Hosts sein (Windows: "ifconfig" Linux: "ifconfig -a" herauszufinden).

[tger977]

Hab ich alles schon durch. Bisher funktioniert nur der manuelle Abgleich mit -u... Bin schon am überlegen ob ich einfach per Logik Edomi per shell Befehl alle 6h synchronisiere. Vielen Dank für eure Hilfe aber trotzdem.

[tger977]

so, hab nun auch nochmal mit dem hwclock Befehl und manuellem Abgleich nachgeschaut:

/var/lib/ntp$ hwclock
Mo 20 Feb 2017 19:30:24 CET  -1.017199 Sekunden
/var/lib/ntp$ ntpdate -u pool.ntp.org
20 Feb 19:33:08 ntpdate[5300]: step time server 131.188.3.220 offset -2.262553 sec
/var/lib/ntp$ hwclock
Mo 20 Feb 2017 19:33:17 CET  -0.313038 Sekunden
/var/lib/ntp$ ntpdate -u pool.ntp.org
20 Feb 19:33:25 ntpdate[5452]: adjust time server 131.188.3.220 offset -0.000816 sec
/var/lib/ntp$ hwclock
Mo 20 Feb 2017 19:33:32 CET  -0.063071 Sekunden

sollte damit auch ok sein, oder?

[starwarsfan]

Irgendwie hat das denn Anschein, als ob Deine Uhr auf dem Board sehr schnell abweicht. Mach doch mal ein kleines Script das ntp stoppt, den Abgleich macht, dann bspw. 30 Minuten wartet und dann nochmal den Abgleich macht. Dann solltest Du sehen, Wieviel die Uhr in dieser Zeit aus dem Ruder läuft. Evtl. kann ich das nachher auch mal bei mir machen, nur um einen Vergleich zu haben (wenn auch auf anderer Hardware).

[starwarsfan]

N'abend miteinander,

so, hier der Einzeiler:

service ntpd stop ; ntpdate -u pool.ntp.org ; sleep 10m ; ntpdate -u pool.ntp.org ; service ntpd start

Bei mir sieht das so aus:

root@edomi { ~ } # service ntpd stop ; ntpdate -u pool.ntp.org ; sleep 10m ; ntpdate -u pool.ntp.org ; service ntpd start
Shutting down ntpd: [ OK ]
20 Feb 20:33:23 ntpdate[16856]: 62.12.173.11 rate limit response from server.
20 Feb 20:33:24 ntpdate[16856]: adjust time server 192.33.96.102 offset -0.001121 sec
20 Feb 20:43:25 ntpdate[29319]: adjust time server 212.51.144.44 offset 0.000136 sec
Starting ntpd: [ OK ]
root@edomi { ~ } #

Damit ist zu sehen, dass die Uhr meiner VM nach zehn Minuten 0,000136s voraus ging. Ich bin gespannt, wie das bei Dir aussieht.

PS: Nicht vom Aussehen des Prompt irritieren lassen, ich verwende eine andere Shell.

[tger977]

hier das Ergebnis:

/var/lib/ntp$ service ntpd stop ; ntpdate -u pool.ntp.org ; sleep 10m ; ntpdate -u pool.ntp.org ; service ntpd start
ntpd beenden: [  OK  ]
20 Feb 21:42:28 ntpdate[21240]: 193.200.241.66 rate limit response from server.
20 Feb 21:42:28 ntpdate[21240]: adjust time server 138.201.16.225 offset -0.225299 sec
20 Feb 21:52:29 ntpdate[27447]: 129.70.132.34 rate limit response from server.
20 Feb 21:52:29 ntpdate[27447]: 176.9.31.215 rate limit response from server.
20 Feb 21:52:29 ntpdate[27447]: adjust time server 176.9.31.215 offset 0.047194 sec
ntpd starten: [  OK  ]

Ist zwar deutlich mehr Abweichung als bei Dir, aber was mir das nun bei meinem eigentlichen Socket Problem hilft ist mir noch unklar.

[starwarsfan]

Hoi Andi,

na das ursprüngliche Thema des Threads ist doch, dass ntp bei Dir offenbar nicht (richtig) läuft. So wie das oben aussieht, liegt das nicht an irgendwelchen blockierten Ports sondern an einer extrem stark abweichenden Uhr Deines Boards, so dass der ntp-Dienst diese nicht synchron halten kann. Wenn da Ports blockiert wären, würdest Du die Uhr mit ntpdate auch nicht stellen können.

Die Abweichung ist bei Dir ca. 350mal grösser als bei mir! Falls Du noch so ein Board hast, steck doch die Platte mal da dran und schau was ntp macht. Ich gehe stark davon aus, dass dort alles ok ist denn sonst würden hier noch viel mehr Leute mit einem solchen Board von diesem Problem berichten.

[tger977]

Hi Yves,

Ich glaube schon daß es irgendwas mit Ports/Sockets zu tun hat, da ich ja mit dem normalen ntpdate Befehl die Uhr auch nicht stellen kann sondern nur mit dem ntpdate -u der eben genau einen anderen port zulässt/nutzt ("unpriv port" laut Beschreibung):

/var/lib/ntp$ service ntpd stop
ntpd beenden: [  OK  ]
/var/lib/ntp$ ntpdate pool.ntp.org
21 Feb 21:38:41 ntpdate[6885]: no server suitable for synchronization found
/var/lib/ntp$ ntpdate -u pool.ntp.org
21 Feb 21:38:57 ntpdate[7118]: step time server 85.220.190.246 offset -2.312325 sec
/var/lib/ntp$ service ntpd start
ntpd starten: [  OK  ]
/var/lib/ntp$ ntpdate pool.ntp.org
21 Feb 21:40:17 ntpdate[7975]: the NTP socket is in use, exiting
/var/lib/ntp$ ntpdate -u pool.ntp.org
21 Feb 21:40:28 ntpdate[8078]: adjust time server 85.220.190.246 offset 0.000110 sec
/var/lib/ntp$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.10.10.1      .INIT.          16 u    -  512    0    0.000    0.000   0.000
 185.28.157.12   .INIT.          16 u    -  512    0    0.000    0.000   0.000
 185.77.199.1    .INIT.          16 u    -  512    0    0.000    0.000   0.000
 213.136.86.203  .INIT.          16 u    -  512    0    0.000    0.000   0.000
 136.243.177.133 .INIT.          16 u    -  512    0    0.000    0.000   0.000

Die 10.10.10.1 ist meine Fritzbox die ich nun auch mal in die Konfig aufgenommen habe.

Aber ich gebe Dir natürlich Recht: Die Systemuhr ist da schon sehr arg daneben. Nur leider habe ich kein weiteres Board / S900 um das weiter zu testen. Eigentlich dachte ich (wie Du vmtl. ja auch ) daß ich längst schon den Zielrechner Timberwolf am laufen hätte, daher war der S900 für mich eigentlich nur eine "Übergangslösung" um mit EDOMI mal loslegen zu können.

Und: da ich ja nun schon mehrfach die manuelle Synchronisation gemacht habe und trotzdem kein NTP Sync funktioniert glaube ich das da doch eher irgendwas an meinem Netzwerk nicht passt, nur leider hab ich da zu wenig Ahnung wo ich da nun weiter suchen soll.

[ChrisChros]

Hallo,
ich stehe aktuell vor dem gleichen Problem das meine Systemzeit relativ schnell aus dem Ruder läuft. Es sieht bei mir eigentlich genau so aus wie tger977.
gibt es dazu schon einen Lösungsansatz außer Neuinstallation?

[root@Edomi ~]# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 192.168.1.1     .INIT.          16 u    -   64    0    0.000    0.000   0.000
 185.13.148.109  .INIT.          16 u    -   64    0    0.000    0.000   0.000
 94.23.0.110     .INIT.          16 u    -   64    0    0.000    0.000   0.000
 2a03:b0c0:0:101 .INIT.          16 u    -   64    0    0.000    0.000   0.000
 81.3.27.46      .INIT.          16 u    -   64    0    0.000    0.000   0.000
 176.9.42.91     .INIT.          16 u    -   64    0    0.000    0.000   0.000

[root@Edomi ~]# ntpdate -u pool.ntp.org
18 Feb 12:57:46 ntpdate[29277]: adjust time server 79.142.192.4 offset -0.053689 sec

[root@Edomi ~]# ntpdate pool.ntp.org
18 Feb 13:01:46 ntpdate[1720]: the NTP socket is in use, exiting

[root@Edomi ~]#

Habe auch alle hier beschriebenen Maßnahmen getestet, leider ohne Erfolg.
Gruß Christian

[starwarsfan]

Hallo Christian

gibt es dazu schon einen Lösungsansatz außer Neuinstallation?

Neuinstallation ist völlig witzlos in solch einem Fall. Wenn die Uhr schnell aus dem Ruder läuft, dann ist das ein Hardwareproblem und das hast Du auch noch, wenn Du den Rechner hundert mal neu installiert hast.

Von daher bleiben eigentlich nur zwei Möglichkeiten:

1. Die Zeit periodisch hart setzen, wenn es der normale ntp nicht mehr schaft.
2. Das Board zum Elektroschrott bringen und ein neues/anderes Board verwenden.

[ChrisChros]

kann das auch mit der Batterie auf dem Board zusammen hängen, das die eventuell leer ist?
Da der S900 ja immer am Strom hängt, würde man eine leere Batterie nicht wirklich bemerken oder?

[starwarsfan]

Nein, damit hat das eher wenig zu tun. Die Batterie auf dem Board ist nur dafür da, die Uhr weiterlaufen zu lassen, wenn der Rechner aus ist resp. gar nicht am Strom hängt.