Warum aktualisiert ntpd die Uhrzeit auf meinem Server nicht?

Ich habe NTPD auf meinem Server ausgeführt. Dies sind alle Standardeinstellungen, mit der Ausnahme, dass ich die Fähigkeit, Server für andere Computer zu sein, auskommentiert habe:

# restrict -4 default kod notrap nomodify nopeer noquery                                                                    
# restrict -6 default kod notrap nomodify nopeer noquery   
restrict default ignore

Wenn ich renne ntpdate -q ntp.ubuntu.com, wird mir gesagt, dass die Uhr meines Rechners um 7 Sekunden abgestellt ist.

Was ist los? Wie kann ich diagnostizieren, was gerade passiert? Gibt es ein Protokoll, das ich aktivieren kann?

Weitere Infos # 1

# ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 91.189.94.4     193.79.237.14    2 u   30   64    7  108.518   -0.136   0.361

Weitere Infos # 2

So sah das aus, als ich die Frage stellte:

# ntpdate -q ntp.ubuntu.com
server 91.189.94.4, stratum 2, offset 7.191308, delay 0.13310
10 Jan 20:38:09 ntpdate[31055]: step time server 91.189.94.4 offset 7.191308 sec

Und so sieht es jetzt aus, nachdem ntpd ein paar Mal neu gestartet wurde (ich gehe davon aus, dass es das ist, was es behoben hat):

# ntpdate -q ntp.ubuntu.com
server 91.189.94.4, stratum 2, offset 0.000112, delay 0.13164
10 Jan 20:47:03 ntpdate[31419]: adjust time server 91.189.94.4 offset 0.000112 sec

Weitere Infos # 3

Ich habe ntp deinstalliert und openntpd installiert und ausgeführt. Die /usr/sbin/ntpd -dAusgabe sieht folgendermaßen aus:

reply from 64.73.32.134: offset 6.715003 delay 0.041152, next query 30s
reply from 208.53.158.34: offset 6.700224 delay 0.036263, next query 31s
adjusting local clock by 6.734120s
reply from 72.18.205.156: offset 6.708575 delay 0.035885, next query 30s
reply from 64.73.32.134: offset 6.701463 delay 0.044199, next query 33s

Was für mich ziemlich eindeutig darauf hinweist, dass ich die Zeit auf meinem Server nicht einstellen kann (obwohl es bei normalem ntp manchmal zu aktualisieren scheint ...).

Weitere Infos # 4

Mein VPS-Anbieter sagt:

Die neuesten Kernel sollten Ihr System nicht an die Uhr von dom0 binden. Zur Sicherheit können Sie in Ihrer sysctl.conf xen.independent_wallclock = 1 setzen.

Was meiner Meinung nach immer noch nicht das Problem des VPS angeht, das eine CPU benötigt, um korrekte Timing-Berechnungen durchführen zu können.

Sie können die Anmeldung in ntpd aktivieren, indem Sie Folgendes zu ntp.conf hinzufügen:

logfile /var/log/ntpd.log

Quelle: NTP-Handbuch

Wenn Sie ntpd ausschalten, können Sie die Uhr über die Befehlszeile aktualisieren? Wenn Sie den Befehl ntpdate ausführen und eine Fehlermeldung wie folgt erhalten:

# ntpdate ntp.ubuntu.com
10 Jan 23:47:57 ntpdate[26284]: Can't adjust the time of day: Operation not permitted

Dies bedeutet, dass Sie wahrscheinlich auf einem VPS arbeiten und in diesem Fall die Systemuhr nicht ändern können - dies ist nur auf dem Host-Computer möglich.

In der Zeit, seit ich diese Frage gestellt habe, habe ich ntp mit der Standardkonfiguration des Herstellers (Ubuntu 10.0.4) neu installiert und einige Tage laufen lassen. Dies ntpdate -q ntp.ubuntu.comzeigt, dass meine Zeit auf 0,000216 Sekunden genau ist. Die Probleme, die ich hatte, müssen also mit meiner angepassten Konfiguration zu tun haben (bei der ich versucht habe, externen Hosts das Abfragen meines Servers zu verunmöglichen, was ich bereits mit meiner Firewall mache, um mir keine Sorgen zu machen). Hier ist die Ubuntu 10.0.4 ntp.conf in ihrer Gesamtheit mit entfernten Kommentaren:

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 ntp.ubuntu.com

restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

restrict 127.0.0.1
restrict ::1

Ich freue mich über Feedback, wie diese Konfiguration verbessert werden könnte.

Ich habe auch ein Ticket bei meinem VPS-Anbieter gemacht und ihn um eine detaillierte Empfehlung gebeten, was am besten zu tun ist. Ich habe sie auf diesen Thread und eine andere Dokumentation verwiesen, die darauf hinweist, dass die CPU-Zuweisung möglicherweise ein Zeitproblem verursachen würde. Folgendes sagten sie:

Die neuesten Kernel sollten Ihr System nicht an die Uhr von dom0 binden. Zur Sicherheit können Sie in Ihrer sysctl.conf xen.independent_wallclock = 1 setzen. Dadurch wird sichergestellt, dass die Serverinstanz nicht der Uhr auf dem Hostserver folgt.

und:

Ich denke, Sie verstehen möglicherweise nicht genau, inwieweit sich dieses Problem auf NTP-Clients in einer virtualisierten Umgebung auswirkt. Nach meiner Erfahrung mit einem virtualisierten System auf einem Xen-Host (wie unserem Setup in der Rackspace Cloud) beträgt die Ungenauigkeit, die dadurch entstanden ist, dass keine dedizierte Systemuhr zur Verarbeitung der Interrupts vorhanden ist, selbst auf stark ausgelasteten Systemen Bruchteile von Sekunden. Diese geringfügige Ungenauigkeit kann von NTP problemlos behoben werden, selbst wenn die Serverzeit nur einmal pro Tag (oder noch seltener) aktualisiert wird.

Einer Ihrer Kommentare besagt, dass Sie auf einem vhost laufen. In diesem Fall werden Sie wahrscheinlich keinen großen Erfolg haben, da das Zeitgefühl Ihres VHosts sowohl vom tatsächlichen Host abhängt, auf dem er ausgeführt wird, als auch davon, wie beschäftigt der VHost insgesamt ist.

Abhängig von der verwendeten Virtualisierung kann es vorkommen, dass der vhost in einem bestimmten Zeitraum nicht gleichmäßig viele Interrupts empfängt. Dadurch läuft die Uhr schneller oder langsamer, als es tatsächlich geschieht. Da ntp versucht, Änderungen zu messen, unter der Annahme, dass Ihre Uhr eine feste Rate hat, die schneller oder langsamer ist als der Rest der Welt, führt diese Beschleunigung und Verlangsamung zu ntp-Anpassungen und wird wahrscheinlich irgendwann einfach aufgeben, mit dem Ergebnis das ntp -npzeigt zeitserver, die ntp als ungeeignet erachtet hat.

Ihre beste Wahl, wenn dies der Fall ist, ist wahrscheinlich eine rohe Kraft rdate -s $server, die hin und wieder (wie alle sechs Stunden) die Uhr an der Nase herumzureißen, damit sie nicht übermäßig aus der Synchronität gerät. Aber feinkörnige Genauigkeit ist wahrscheinlich unerreichbar.

Dinge, die ich in der Vergangenheit gefunden habe, als ich ntpd anstelle von openntpd verwendete:

1. Sie müssen den Zugriff auf localhost zulassen, damit ntpd ordnungsgemäß gestartet wird und tatsächlich Aufgaben ausführt

   restrict 127.0.0.1
   restrict ::1
   

2. Obwohl Sie Hostnamen für Serverregeln verwenden können, bedeutet das Öffnen von Sicherungslücken für die Kommunikation mit diesen Servern, restrictdass IP-Adressen erforderlich sind. Daher musste ich ohnehin für alles IPs verwenden.

3. Sie erwähnen nicht, dass Sie verwenden restrict, um den Zugriff auf Ihre Server zu öffnen. Das ist ein Problem. Versuchen Sie es mit Blöcken wie den folgenden:

   # ntp.xs4all.nl
   server          194.109.22.18
   restrict        194.109.22.18
   

4. Sie benötigen mehrere Peers oder Server für ntpd, da es versucht, mit Abstimmungen nach den Mehrheitsregeln gegen einen schlechten Schauspieler vorzugehen. Also mindestens 4, um noch eine Mehrheit zu haben, wenn man eine verliert, am besten 5.

5. Um den Standardzugriff zu sperren, könnte ich Folgendes verwenden:

   restrict default notrust nomodify
   

   um noch abfragen zu können, aber ich habe am Ende verwendet, restrict default ignorewie Sie es tun, wenn NTPD 4.2 die Bedeutung von änderte notrust. Seufzer

6. Wenn Sie anderen keinen Zeitdienst anbieten, benötigen Sie wahrscheinlich nicht die volle Leistung von normalem ntpd und sollten openntpdstattdessen darüber nachdenken . Geschrieben von der OpenBSD-Crew, handelt es sich um eine weitaus minimalere Implementierung, die Privilegientrennung und eine viel einfachere Konfigurationsdatei verwendet. Es wird angeblich nicht die hochpräzise Zeit liefern, die ntpd liefert, aber es ist leicht genug für einen normalen Server oder eine Workstation.

• Wenn ntpd keine Verbindung zum Remote-Server herstellen kann, wird für diesen Server kein Offset angezeigt.
• Wenn ntpq von ntpd blockiert wird, wird eine eindeutige Fehlermeldung von ntpq angezeigt.
• Wenn ein anderer Dienst auch die Zeit einstellen würde (wie vmware tools), würde ein Sprungoffset für den Server angezeigt (führen Sie ntpq -p alle 70 Sekunden aus).

Die reach 7Ausgabe in ntpq zeigte an, dass Sie ntpd nur ca. 4 Minuten laufen lassen. 7 ist 111 binär, was bedeutet, dass der Server bereits dreimal erreicht wurde. ntp erreicht alle 64 Sekunden ( pollWert) und hat bereits 30 Sekunden ( whenWert) seit dem letzten Kontakt gewartet .

Das offset -0.136zeigt an, dass das System bereits synchronisiert ist. Nur ntpd hat den Server noch nicht als Quelle markiert. Geben Sie ihm einfach mehr Zeit und es erscheint ein kleiner Stern.

Tatsächlich synchronisierte Ihr NTPD. Aber ntpd synchronisiert normalerweise nicht mit einem großen Sprung (wie ntpdate), sondern versucht die Zeit langsam anzupassen und sorgt über mehrere Zyklen dafür, dass die Zeit stabil ist.

PS: Mir ist bewusst, dass die Frage sehr alt ist. Aber das Thema ist zeitlos. Und all die anderen Antworten sind meiner Meinung nach nur irreführend. ntpd wird sogar von VMWare empfohlen, um die Zeit synchron zu halten.

Ich fand mein System ausgeschaltet und wunderte mich, warum die HW-Uhr bei einem sauberen Herunterfahren nicht mit der Systemuhr synchronisiert wurde. Es scheint, dass es in sysconfig eine NTP-Einstellung gibt, die bearbeitet werden muss, um dies zu ermöglichen.

In /etc/sysconfig/ntpd:

# Set to 'yes' to sync hw clock after successful ntpdate
SYNC_HWCLOCK=no

Ich setze das auf yes. Stellen Sie zunächst sicher, dass Sie einen soliden NTP-Server haben und Ihre Systemuhr zuverlässig ist.

Ich wusste, dass es das war - mein Zeitversatz betrug 47 Sekunden und meine HW-Uhr war auch 47 Sekunden ausgeschaltet. Bingo! Mein erster Hinweis waren Kerberos-Fehler in den Protokollen. Kerberos und viele NAS funktionieren einfach nicht, wenn der Zeitversatz zu groß ist.

Einen schönen Tag noch!

wenn Sie vhost auf vmware überprüfen Sie die folgende article..it shuld Hilfe laufen Sie http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf

Hai ..

Sehen Sie sich diese Referenz an, um zu sehen, ob sie bei der Behebung Ihres Problems hilfreich sein kann:

http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_: Ch24 : _The_NTP_Server

Vielleicht möchten Sie den Inhalt Ihrer Datei ntpd.conf veröffentlichen, die Ausgabe der Debug-Befehle wie ntpq -p

Und überprüfen Sie Ihr Datum / Ihre Uhrzeit?

Und überprüfen Sie dies auch, führen Sie ntpdate aus und starten Sie ntpd. Ist die Zeit synchron?

mit besten Grüßen