it-swarm.com.de

NTP läuft, Systemuhr noch nicht rechtzeitig - was gibt es?

Auf einem Debian Stable (5.0.3) -Server wird ntpd ausgeführt und eine Verbindung zum Internet hergestellt. Trotzdem ist die Systemuhr etwa 5 Minuten falsch.

$ /etc/init.d/ntp status
NTP server is running..

Relevante Teile (glaube ich) von /etc/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 0.europe.pool.ntp.org
server 1.europe.pool.ntp.org
server 2.europe.pool.ntp.org
server 3.europe.pool.ntp.org

Ich weiß, dass NTP nicht unbedingt die Uhr sofort einstellt. Dennoch, wie viele Stunden oder Tage Sie warten müssen, um vernünftigerweise zu erwarten, dass NTP hat seinen Job gemacht und die Uhr synchronisiert?

Fehlt mir eine andere Konfigurationsdatei oder Option oder mache ich einfach etwas falsch? Ist ntp (anstelle von z. B. ntpdate ) das richtige Werkzeug dafür? Gibt es eine schnelle Möglichkeit zu überprüfen, ob die Konfiguration korrekt ist und ob die ausgewählten NTP Server) die richtige Zeit zurückgeben?

Edit : Ausgabe von ntpq -p ist:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ns1.nexellent.n .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 dnscache-madrid .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 sinister.wzw.tu .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 dnscache-frankf .INIT.          16 u    - 1024    0    0.000    0.000   0.000

Bearbeiten 2 : Stellt sich heraus ntpdate -u 0.europe.pool.ntp.org Befehl ( vorgeschlagen von brent ) gibt zurück

17 Dec 17:37:29 ntpdate[14195]: no server suitable for synchronization found

... obwohl auf anderen Maschinen dieser Befehl gut funktioniert. Wir werden uns also die Netzwerk-/Firewall-Einstellungen für diesen bestimmten Server ansehen (der sich in einem anderen Netzwerk befindet und über VPN zugegriffen wird).

Lösung : Der Schuldige war nicht die lokale Firewall auf unserem Server, sondern die Firewall-Einstellungen irgendwo im umgebenden Netzwerk. Deshalb haben wir den Server-Hosting-Anbieter gebeten, NTP für unsere Computer) zuzulassen, und jetzt funktioniert es einwandfrei. Zum Beispiel ntpq -p kehrt jetzt zurück:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ns1.eunet.fi    192.36.144.23    2 u   10   64    1    1.043    0.258   0.001
 ns2.eunet.fi    62.142.10.44     2 u    9   64    1    0.671    0.135   0.001
 ns3.eunet.fi    62.142.10.44     2 u    8   64    1    0.750    0.277   0.001

(Wir haben auch auf eunet.fi-Server umgestellt, die von der Hosting-Firma neu gestartet wurden, aber das ist nicht der Punkt.) Die Befehle in Antwort von brent waren hilfreich, weil mir klar wurde, dass das Problem im Netzwerkzugriff auf die liegt NTP Server, nicht in NTP Konfiguration selbst. Vielen Dank an alle!

27
Jonik

Stoppen Sie ntpd und führen Sie ntpdate -u 0.europe.pool.ntp.org 3 mal, starte ntpd, überprüfe ntpq -p, Verzögerung, Offset und Jitter sollten ungleich Null sein.

24
brent

Wenn ich raten müsste, warum und unter der Annahme, dass Sie über eine Netzwerkverbindung verfügen und Ihren NTP Host) problemlos sehen können, haben Sie möglicherweise einen großen Wert erreicht. Wenn der Zeitunterschied größer ist als X (Entschuldigung, ich erinnere mich nicht, was X auf Anhieb ist), wird eine Warnung gedruckt und die Zeit wird nicht synchronisiert. Sie können Ihre Syslog-Nachrichten auf Fälle überprüfen.

Wenn dies der Fall ist, stoppen Sie NTP, führen Sie ntpdate Host aus und starten Sie das NTPD neu. Dadurch wird eine Zeitsynchronisierung erzwungen und die Synchronisierung wird fortgesetzt. Wenn Sie weiterhin so stark driften, liegt möglicherweise ein Hardwareproblem vor.

1
Gary Steven

Die "Reach" -Spalten, die 0 sind, deuten darauf hin, dass es nicht möglich war, mit den Servern zu sprechen. Nach und nach werden Bits verschoben, um zu zeigen, wie die letzten 8 Versuche verlaufen sind (also 377 ist gut, 0 ist schlecht).

1
araqnid