NTP nach einem Reboot/Disconnect

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
J

Jumper99

Neuer User
Mitglied seit
7 Jun 2010
Beiträge
81
Punkte für Reaktionen
0
Punkte
6
Hallo,

nachdem ich meinen W920V boote, geht die Uhr grundsätzlich um genau 9 Sekunden vor. Nachdem ich OpenNTP einsetze, weigert dieser sich, ca. 8 Stunden lang (so lange dauert es, bis die Zeit angegelichen wurde), als Zeitdienst zu fungieren. Da die Box nicht DHCP Server spielt und um Konflikte mit OpenNTPD zu vermeiden, ist die AVM-Zeitsynchronisation deaktiviert.

Wie kann ich das Problem beheben? ntpdate oder 'ntpd -q' ist ja nicht verfügbar.

Danke und Gruß, Helmut

Jun 15 13:12:55 ipv4-gw ntpd[2542]: adjusting local clock by -9.004679s
Jun 15 13:12:55 ipv4-gw ntpd[2542]: skew change -4064.584 exceeds limit
Jun 15 13:22:05 ipv4-gw ntpd[2542]: adjusting local clock by -9.072223s
Jun 15 13:26:14 ipv4-gw ntpd[2542]: adjusting local clock by -8.932351s
Jun 15 13:30:30 ipv4-gw ntpd[2542]: adjusting local clock by -8.878100s
Jun 15 13:34:49 ipv4-gw ntpd[2542]: adjusting local clock by -8.770439s
Jun 15 13:39:01 ipv4-gw ntpd[2542]: adjusting local clock by -8.660766s
Jun 15 13:43:17 ipv4-gw ntpd[2542]: adjusting local clock by -8.552637s
Jun 15 13:47:31 ipv4-gw ntpd[2542]: adjusting local clock by -8.480907s
Jun 15 13:51:47 ipv4-gw ntpd[2542]: adjusting local clock by -8.377005s
Jun 15 13:56:06 ipv4-gw ntpd[2542]: adjusting local clock by -8.279279s
Jun 15 14:00:26 ipv4-gw ntpd[2542]: adjusting local clock by -8.176400s
Jun 15 14:04:34 ipv4-gw ntpd[2542]: adjusting local clock by -8.115681s
Jun 15 14:08:51 ipv4-gw ntpd[2542]: adjusting local clock by -7.942272s
Jun 15 14:13:08 ipv4-gw ntpd[2542]: adjusting local clock by -7.913012s
Jun 15 14:17:25 ipv4-gw ntpd[2542]: adjusting local clock by -7.791212s
Jun 15 14:21:40 ipv4-gw ntpd[2542]: adjusting local clock by -7.701445s
Jun 15 14:25:58 ipv4-gw ntpd[2542]: adjusting local clock by -7.592091s
Jun 15 14:30:12 ipv4-gw ntpd[2542]: adjusting local clock by -7.496187s
Jun 15 14:34:28 ipv4-gw ntpd[2542]: adjusting local clock by -7.419048s
Jun 15 14:38:40 ipv4-gw ntpd[2542]: adjusting local clock by -7.303498s
Jun 15 14:42:58 ipv4-gw ntpd[2542]: adjusting local clock by -7.206120s
Jun 15 14:47:18 ipv4-gw ntpd[2542]: adjusting local clock by -7.109059s
Jun 15 14:51:35 ipv4-gw ntpd[2542]: adjusting local clock by -7.010837s
Jun 15 14:55:52 ipv4-gw ntpd[2542]: adjusting local clock by -6.905489s
Jun 15 15:00:07 ipv4-gw ntpd[2542]: adjusting local clock by -6.843063s
Jun 15 15:04:28 ipv4-gw ntpd[2542]: adjusting local clock by -6.745643s
Jun 15 15:08:40 ipv4-gw ntpd[2542]: adjusting local clock by -6.611116s
Jun 15 15:12:55 ipv4-gw ntpd[2542]: adjusting local clock by -6.550543s
Jun 15 15:17:09 ipv4-gw ntpd[2542]: adjusting local clock by -6.418577s
Jun 15 15:21:22 ipv4-gw ntpd[2542]: adjusting local clock by -6.327525s
Jun 15 15:25:42 ipv4-gw ntpd[2542]: adjusting local clock by -6.244159s
Jun 15 15:25:43 BSDHelmut ntpd[34377]: reply from 192.168.124.1: not synced (alarm), next query 3104s
Jun 15 15:29:55 ipv4-gw ntpd[2542]: adjusting local clock by -6.171392s
Jun 15 15:34:11 ipv4-gw ntpd[2542]: adjusting local clock by -6.059209s
Jun 15 15:38:31 ipv4-gw ntpd[2542]: adjusting local clock by -5.970834s
Jun 15 15:42:50 ipv4-gw ntpd[2542]: adjusting local clock by -5.867437s
Jun 15 15:47:06 ipv4-gw ntpd[2542]: adjusting local clock by -5.760568s
Jun 15 15:51:22 ipv4-gw ntpd[2542]: adjusting local clock by -5.637003s

Meine ntpd.conf:

listen on 0.0.0.0
server 0.de.pool.ntp.org
server 1.de.pool.ntp.org
server 2.de.pool.ntp.org
server 3.de.pool.ntp.org
 
TIK hat hier die Tage ein Update für openntpd eingestellt. Vielleicht kannst du das mal testen, wenn es funktioniert wird es in den trunk aufgenommen.

Gruß
Oliver

edit: Bitte code-Tags benutzen!
 
Bei Freetz wird ntpd mit der Option -s gestartet, die besagt, dass die Zeit nach der ersten Synchronisierung sofort gesetzt werden soll.

Du solltest mal herausfinden, wer die Zeit falsch setzt, und warum openntpd die Zeit beim Neustart nicht setzt.

Wie rufst Du den ntpd auf, und wie sieht dessen Ausgabe von Anfang an aus?
 
olistudent schrieb:
TIK hat hier die Tage ein Update für openntpd eingestellt. Vielleicht kannst du das mal testen, wenn es funktioniert wird es in den trunk aufgenommen.
Zum Vergrößern anklicken....

Der Patch mag mit dem Trunk nicht:

Code: 
applying patch file make/openntpd/patches/002-save_freq_drift.patch
patching file ntpd.h
patching file ntpd.c
patching file openbsd-compat/port-linux.c
----------------------------------------------------------------------
applying patch file make/openntpd/patches/openntpd-3.9p1_ext1.0.patch
patching file openntpd-3.9p1/client.c
Hunk #1 FAILED at 27.
Hunk #2 FAILED at 36.
Hunk #3 FAILED at 54.
Hunk #4 FAILED at 118.
Hunk #5 FAILED at 134.
Hunk #6 FAILED at 165.
Hunk #7 FAILED at 190.
Hunk #8 FAILED at 206.
Hunk #9 FAILED at 235.
Hunk #10 FAILED at 256.
Hunk #11 FAILED at 275.
Hunk #12 FAILED at 314.
12 out of 12 hunks FAILED -- saving rejects to file openntpd-3.9p1/client.c.rej
patching file openntpd-3.9p1/ntp.c
Hunk #1 FAILED at 54.
Hunk #2 FAILED at 71.
Hunk #3 FAILED at 103.
Hunk #4 FAILED at 193.
Hunk #5 FAILED at 206.
Hunk #6 FAILED at 219.
Hunk #7 FAILED at 244.
Hunk #8 FAILED at 280.
Hunk #9 FAILED at 297.
Hunk #10 FAILED at 320.
Hunk #11 FAILED at 329.
Hunk #12 FAILED at 383.
Hunk #13 FAILED at 493.
Hunk #14 FAILED at 514.
Hunk #15 FAILED at 526.
15 out of 15 hunks FAILED -- saving rejects to file openntpd-3.9p1/ntp.c.rej
patching file openntpd-3.9p1/ntpd.c
Hunk #1 FAILED at 43.
Hunk #2 FAILED at 74.
Hunk #3 FAILED at 101.
Hunk #4 FAILED at 110.
Hunk #5 FAILED at 225.
Hunk #6 FAILED at 282.
Hunk #7 FAILED at 327.
Hunk #8 FAILED at 351.
8 out of 8 hunks FAILED -- saving rejects to file openntpd-3.9p1/ntpd.c.rej
patching file openntpd-3.9p1/ntpd.h
Hunk #1 FAILED at 61.
Hunk #2 FAILED at 119.
Hunk #3 FAILED at 131.
Hunk #4 FAILED at 227.
Hunk #5 FAILED at 251.
5 out of 5 hunks FAILED -- saving rejects to file openntpd-3.9p1/ntpd.h.rej
patching file openntpd-3.9p1/parse.y
Hunk #1 FAILED at 43.
Hunk #2 FAILED at 57.
Hunk #3 FAILED at 66.
Hunk #4 FAILED at 178.
Hunk #5 FAILED at 195.
Hunk #6 FAILED at 229.
Hunk #7 FAILED at 372.
Hunk #8 FAILED at 413.
Hunk #9 FAILED at 424.
9 out of 9 hunks FAILED -- saving rejects to file openntpd-3.9p1/parse.y.rej
patching file openntpd-3.9p1/util.c
Hunk #1 FAILED at 32.
Hunk #2 FAILED at 87.
2 out of 2 hunks FAILED -- saving rejects to file openntpd-3.9p1/util.c.rej
----------------------------------------------------------------------
ERROR: modpatch: Error in patch-file make/openntpd/patches/openntpd-3.9p1_ext1.0.patch
make: *** [source/target-mipsel_uClibc-0.9.29/openntpd-3.9p1/.unpacked] Error 2
 
RalfFriedl schrieb:
Bei Freetz wird ntpd mit der Option -s gestartet, die besagt, dass die Zeit nach der ersten Synchronisierung sofort gesetzt werden soll.

Du solltest mal herausfinden, wer die Zeit falsch setzt, und warum openntpd die Zeit beim Neustart nicht setzt.
Zum Vergrößern anklicken....

Das ist ja das lustige, das macht eben niemand:

Code: 
root@ipv4-gw:/var/mod/root# ntpd -s -d -f /mod/etc/ntpd.conf
listening on 0.0.0.0
ntp engine ready
reply from 78.46.108.116: offset -4.169501 delay 0.026648, next query 7s
reply from 83.169.43.165: offset -4.188298 delay 0.029461, next query 6s
reply from 87.118.86.27: offset -4.167311 delay 0.039779, next query 8s
reply from 83.169.43.165: offset -4.186857 delay 0.027123, next query 5s
reply from 87.118.86.27: offset -4.165114 delay 0.041137, next query 7s
reply from 78.46.108.116: offset -4.165360 delay 0.026298, next query 5s
reply from 83.169.43.165: offset -4.186221 delay 0.029572, next query 8s
reply from 87.118.86.27: offset -4.162056 delay 0.040249, next query 5s
reply from 78.46.108.116: offset -4.163600 delay 0.026624, next query 8s
peer 83.169.43.165 now valid
reply from 83.169.43.165: offset -4.181987 delay 0.027324, next query 6s
peer 87.118.86.27 now valid
reply from 87.118.86.27: offset -4.160155 delay 0.040761, next query 6s
peer 78.46.108.116 now valid
reply from 78.46.108.116: offset -4.160317 delay 0.026467, next query 9s
reply from 83.169.43.165: offset -4.181076 delay 0.030058, next query 9s
reply from 87.118.86.27: offset -4.157986 delay 0.040707, next query 8s
reply from 78.46.108.116: offset -4.156970 delay 0.026455, next query 8s
reply from 83.169.43.165: offset -4.176223 delay 0.027108, next query 7s
reply from 87.118.86.27: offset -4.154773 delay 0.040782, next query 7s
reply from 78.46.108.116: offset -4.154198 delay 0.026874, next query 7s
reply from 83.169.43.165: offset -4.175268 delay 0.030491, next query 32s
reply from 87.118.86.27: offset -4.152148 delay 0.040322, next query 34s
reply from 78.46.108.116: offset -4.151263 delay 0.026479, next query 31s
reply from 83.169.43.165: offset -4.162892 delay 0.030334, next query 34s
reply from 87.118.86.27: offset -4.139096 delay 0.040623, next query 31s
reply from 78.46.108.116: offset -4.139889 delay 0.026404, next query 32s
adjusting local clock by -4.167311s
interval 0.000 skew 0.000 total skew -5.000
reply from 83.169.43.165: offset -4.148927 delay 0.027094, next query 34s
reply from 87.118.86.27: offset -4.127681 delay 0.040822, next query 31s
reply from 78.46.108.116: offset -4.127647 delay 0.026592, next query 32s
ntp engine exiting
Terminating

Code: 
adjusting local clock by -4.167311s

Macht es aber nicht... :(

RalfFriedl schrieb:
Wie rufst Du den ntpd auf, und wie sieht dessen Ausgabe von Anfang an aus?
Zum Vergrößern anklicken....

ps -w sagt: ntpd -s -f /mod/etc/ntpd.conf
 
Jumper99 schrieb:
Der Patch mag mit dem Trunk nicht:
Zum Vergrößern anklicken....
mit dem aktuellen trunk hab ich den patch nicht getestet. hat sich denn hier bei openNTPD was geändert? du kannst auch die 3.9 von der webseite laden, den patch darauf anwenden und die 6 modifizierten files dann kopieren...

ansonsten läuft openNTPD auf deiner box korrekt (was die logs angeht). deine uhrzeit wird halt nur sehr langsam korrigiert. das liegt nicht am NTPD sondern am kernel oder an der RTC. der patch kann dein problem nur mit einschränkungen lösen...
probier mal in der config dann zusätzlich:
Code: 
sync every 5m

folgendes macht mich doch noch stutzig in deinen logs:
Code: 
Jun 15 15:25:42 ipv4-gw ntpd[2542]: adjusting local clock by -6.244159s
Jun 15 15:25:43 BSDHelmut ntpd[34377]: reply from 192.168.124.1: not synced (alarm), next query 3104s
laufen hier doch 2 ntpd?
 
Zuletzt bearbeitet:
ipv4-gw (192.168.124.1) ist die Box, BSDHelmut der Loghost, der sich die Zeit von der Box holt.
 
ok. mir sind noch 2 sachen eingefallen:
  • den genannten patch kannst du nicht auf die download version "openntpd-3.9p1.tar.gz" anwenden. du musst zuerst diese patches ausführen
  • möglicherweise arbeiten auf deiner box das korrigieren der zeit und das korrigieren der RTC frequenz gegeneinander. das geht zwar aus dem log nicht hervor, aber wer weiss. du könntest zum test einfach in "defines.h" folgendes auskommentieren:
    Code: 
    # define adjtime(a,b)  (_compat_adjtime((a),(b)))
    das würde die frequenz-korrektur deaktivieren. vor den test solltest du die box neu starten, damit die frequenz-korrektor auf 0 gesetzt wird.
 
Zuletzt bearbeitet:
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 672 (Mitglieder: 27, Gäste: 645)

Neueste Beiträge

Statistik des Forums

Themen
246,298
Beiträge
2,249,704
Mitglieder
373,903
Neuestes Mitglied
INFI1978
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück