nptd synchronisiert nicht

[rMarkus]

Hallo,

damals ist u.A. auch durch eine Diskussion hier im Forum folgender Wiki-Artikel entstanden: Wiki Zeit synchronisieren mit ntp

Gerade stelle ich fest, dass ntpd zumindest unter FreeBSD 5.5 die Uhrzeit mit der dort vorgestellten Konfiguration die Uhrzeit nicht synchronisiert.

Dies beobachte ich auf mindestens 2 meiner Maschinen:

   ntpdate -q ptbtime1.ptb.de
Looking for host ptbtime1.ptb.de and service ntp
host found : ptbtime1.ptb.de
server 192.53.103.108, stratum 1, offset 307.883234, delay 0.10355
 3 Feb 12:36:02 ntpdate[10067]: step time server 192.53.103.108 [COLOR="Red"]offset 307.883234 sec[/COLOR]

Der ntpd-Prozess startet dort richtig und gibt beim Starten nur folgende Information ab:

Feb  3 10:17:45 tiuz ntpd[368]: ntpd 4.2.0-a Fri Aug  4 11:46:58 CEST 2006 (1)

(Die andere Maschine hat übrigens schon 35 Tage uptime, d.h. dort sollte ntpd langsam mal die Zeit korrigiert haben)

• Also was ist an der Konfiguration falsch bzw. wie muss der Wiki-Artikel korrigiert werden?
  
• Kann man irgendwo sehen, was ntpd die ganze Zeit treibt? Sollte es nicht normalerweise in die /var/log/messages seine Synchronisationstaten schreiben?
  
• Das Verzeichnis /etc/ntp/ ist bei mir leer, müsste er nicht irgendwo so "Merkdatein" ablegen, bei der er sich den systematischen Fehler der PC-Uhr merkt?

PS: Hier meine Konfiguration noch mal im Schnellüberblick

/etc/rc.conf

ntpd_enable="YES"
ntpd_flags="-g"

/etc/ntp.conf

server ptbtime1.ptb.de prefer
server ptbtime2.ptb.de
server de.pool.ntp.org

 

[Kamikaze]

-g hat nur bei der esrten Synchronisation (normalerweise beim Systemstart) einen effekt und wird üblicherweise mit
ntpd_sync_on_start="YES"
gesetzt. In der ntpd Manpage steht, dass die Korrektur einer Sekunde Abweichung 2000s dauert.

 

[marzl]

NTPD ist etwas träge
Lasst zuerst ntpdate laufen, und danach direkt den ntpd. Dann passt meistens ziemlich schnell und dauerhaft. Aber NTPD ist und bleibt eine Bitch.

 

[0815Chaot]

Bevor man ntpd(8) aufruft, sollte man zunächst ntpdate(8) verwenden (bzw. den dazu äquivalenten Schalter von ntpd(8), siehe Manpages). Also bitte mal folgendes von Hand ausführen und die Ausgabe hier posten:

> ntpdate ptbtime1.ptb.de
> ntpd &
> ntpq -p
[10 Minuten warten]
> ntpq -p

Im Übrigen ist es ziemlich unhöflich, den Stratum 1 (!) der PTB anzuzapfen, sofern man nicht selbst einen öffentlich verfügbaren NTP-Server bereitstellen will. Die meisten Provider bieten eigene NTP-Server an, bei denen man dann sogar bessere Latenzzeiten haben sollte. T-Online-Kunden sollten z.B. ntp1.t-online.de bevorzugen.

 

[mike]

Vl. hast du auch ne zu hohe Kernel security. Über 1 gehts auch nit - war damals mein Fehler

 

[0815Chaot]

Laut init(8) wird das aber geloggt und dort hat der OP wohl schon nachgesehen.

 

[rMarkus]

Zum Thema "ntpd ist etwas träge":

a@bragi:[~]% ntpdate -q ptbtime1.ptb.de
Looking for host ptbtime1.ptb.de and service ntp
host found : ptbtime1.ptb.de
server 192.53.103.108, stratum 1, [COLOR="Red"]offset 309.649384[/COLOR], delay 0.10437
 3 Feb 18:05:08 ntpdate[10756]: step time server 192.53.103.108 offset 309.649384 sec
a@bragi:[~]% uptime
 6:05PM  up [COLOR="Red"]35 days[/COLOR],  1:40, 10 users, load averages: 0.00, 0.00, 0.00

Wenn er nach 35 Tagen die Zwei nicht synchronisiert hat, dann wäre das etwas zu träge ;-)
Und ja, der ntpd läuft seit dem Systemstart.

 

[rMarkus]

@Kamakize

ntpd_sync_on_start war auch damals Thema des Threads hier.
Zumindest bei FreeBSD 5.5 ist das anscheinend zwar eine reservierte Variable, aber es gibt kein Skript oder Programm, das das auswertet.

Kann es sein, dass Statum 1 mich irgendwie nicht mehr ranlässt, aber das sollte doch in den Messages auftauchen?

 

[rMarkus]

Nachtrag:

Ich habe gerade das ntpd_flags="-g" aus meiner Konfiguration entfernt und wollte ntpd mit "/etc/rc.d/ntpd restart" neu starten.
Das Skript hat aber kein pid-File fuer den noch laufenden ntp-Prozess gefunden.
Das scheint immer der Fall zu sein, wenn die ntpd über den init gestartet wird. Starte ich das von Hand, wird ein pid-file angelegt.

:-S

 

[Zoi]

offset 309.649384

Ich weiß es nicht mehr genau, denke aber mal gehört (vielmehr hier gelesen ) zu haben, daß ntpd bei Differenzen > 5 Minuten aufgibt.

Vielleicht ist das das Problem. Oder Deine RTC ist ungenauer wie 1s Diff./2000s, dann hat er ja auch keine Chance.

 

[Hardliner]

Hi, wegen dem pid-file; evtl. in der /etc/rc.conf

ntpd_flags="-p /var/run/ntpd.pid -f /var/db/ntpd.drift"

Schalter f, naja, man loggt hier halt so manches.
gruss

 

[rMarkus]

Also ohne ntpd_flags="-g" hat ntpd gerade die Uhrzeit gesetzt:

eb  3 18:11:41 bragi ntpd[10815]: ntpd 4.2.0-a Sat Oct 21 01:07:44 CEST 2006 (1)
Feb  3 18:21:09 bragi ntpd[10815]: time reset +309.678010 s
Feb  3 18:21:09 bragi ntpd[10815]: kernel time sync disabled 2041
Feb  3 18:31:48 bragi ntpd[10815]: kernel time sync enabled 2001

Also wenn ich das Skript unter /etc/rc.d/ntpd richtig verstehe, dann sollten die rc.subr schon dafür sorgen, dass ein pid-file angelegt werden. Das wird alles über die rc-Standard-Routinen abgefangen.

Das Skript führt nur ein paar Befehle aus, wenn es als chroot läuft.

 

[rMarkus]

Trotz der ganzen o.g. Veränderungen synchronisiert ntpd nach ein paar Tagen Uptime immer noch nicht.

Zuletzt habe ich eplizit ein Driftfile angegeben (siehe Wiki).

Gibt es vielleicht irgendwelche Probleme, wenn man ntpd hinter einer Firewall betreibt (z.B. tcp/udp-NAT-timeouts? ).

Ich habe das Problem sowohl hinter eine PF-Firewall (FreeBSD 5.5) und ipfw (M0n0wall) mit Standardeinstellungen betreffend von NAT-Timeouts?

Habt ihr vielleicht irgendwelche Ideen?

Wenn das immer noch nicht will, dann versuche ich mich wirklich mal an openntpd.

Gruss
Markus

PS: mit ntpq -p kann man prüfen, wie lange NTPD nicht mehr synchronisiert hat:

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ptbtime1.ptb.de .INIT.          16 u  43h 1024    0    0.000    0.000 4000.00
 ptbtime2.ptb.de .INIT.          16 u  43h 1024    0    0.000    0.000 4000.00
 cable-192-102.i .INIT.          16 u  43h 1024    0    0.000    0.000 4000.00

 

[rMarkus]

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ptbtime1.ptb.de .INIT.          16 u  49h 1024    0    0.000    0.000 4000.00
 ptbtime2.ptb.de .INIT.          16 u  49h 1024    0    0.000    0.000 4000.00
 cable-192-102.i .INIT.          16 u  49h 1024    0    0.000    0.000 4000.00

Ich habe mal den Inhalt dieser Statusausgabe zusammengefasst:

Sie zeigt die drei eingetragenen Time-Server.

- Die ST-Spalte zweigt einen Stratum-Wert von 16 an, was sehr schlecht ist. Das ist in etwa vergleichbar mit einem Hopcount.
- Das letzte Mal wurde vor 49 Stunden synchronisiert
- Es sollte alle 1024 Sekunden synchronisiert werden
- Keine der Server war bei den letzten 8 Versuchen erreichbar (reach-Spalte, eine 1 wird "durchgeshiftet")
- delay, offset, jitter zeigen keine Werte an, weil keiner der Server kontaktiert werden konnte.

Normalerweise sollte in der ersten Spalte auch ein "*" für den vertrauenswürdigsten Server stehen und dann ein "+" für die Backup-Server, falls der erste ausfällt.



Ein anderer Rechner, der erst ein paar Tage Uptime hat, gibt folgendes aus:

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ptbtime1.ptb.de .PTB.            1 u  839 1024  377  110.210  -23.043  11.518
+ptbtime2.ptb.de .PTB.            1 u  947 1024  377   99.119  -16.790  11.527
+rat.de.20six.ne 84.78.100.194    3 u  918 1024  377   61.393  -19.925   9.490

Hier war der Timeserver die letzten 8 Versuche erreichbar. delay, offset und jitter haben auch vernünftige Werte (die Angaben sind in Millisekunden).
Hier ist alles in Ordnung.


Also was läuft nach ein paar Tagen Uptime falsch?
Ich habe schon vermutet, dass die Timeserver evtl. nach zu vielen Anfragen einfach dicht machen, aber nach einem Neustart von ntpd oder einem manuellen ntpdate bekomme ich immer sofort eine Zeit.