Hallo Community Mitglieder,
hat jemand eine Idee warum die Zeitsynchronisation nach einem Update von etch auf lenny nicht mehr funktioniert, bzw. nur einmalig kurz nach dem Neustart von ntpd? Danach laeuft die Zeit auseinander. Die ntp.conf hab ich unveraendert von etch nach lenny uebernommen.
ntpdc -pn zeigt mir das hier an
remote local st poll reach delay offset disp
=======================================================================
=85.214.47.70 192.168.2.30 3 64 377 0.06276 -909.0207 0.07280
=192.53.103.104 192.168.2.30 1 64 377 0.06689 -915.0814 0.06100
=192.53.103.108 192.168.2.30 1 64 377 0.06557 -916.2856 0.05058
=85.10.240.253 192.168.2.30 2 64 377 0.04779 -916.8994 0.04552
=87.139.126.233 192.168.2.30 1 64 377 0.09480 -914.0923 0.06619
Demnach sind die ntp Server erreichbar, aber keiner wird zur Synchronisation verwendet?
Hallo,
was sagt das Log?
Ist das ne virtuelle Maschine?
NTP-Info -> http://www.linuxaria.com/howto/clock-ntp-linux?lang=en
Hallo,
im Log steht nur diese eine, erste Synchronisation
ntp.log
13 Oct 21:27:00 ntpd[4863]: synchronized to 78.46.194.186, stratum 2
13 Oct 21:16:00 ntpd[4863]: time reset -659.478197 s
13 Oct 21:16:00 ntpd[4863]: kernel time sync status change 0001
sonst erscheint nichts mehr. Man koennte meinen der ntpd ist mit “-q” gestartet, aber der laeuft weiter, wie ps -ef|grep ntp zeigt:
ntp 5407 1 0 Oct13 ? 00:00:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -u 108:108 -g
Das ist auf 3 Maschinen das gleiche, 2 Embedded und ein Desktop Rechner, keine virtuellen Rechner. Einer der Embedded Rechner war zusaetzlich der ntp Server in LAN.
Wenn ich das richtig verstehe, synchronisiert das Gerät und hat eine Abweichung von 0,06 – bis 0,08 Sekunden.
Gleichen sich denn alle 3 Geräte mit einem NTP Server im Internet ab? (Sieht für mich nach pool.ntp.org aus)
Oder fungiert ein Gerät als zentraler NTP Server mit dem die anderen synchronisieren?
Wie stark sind denn die Abweichungen zwischen den Geräten?
Notfalls würde ich es einmal mit sudo dpkg-reconfigure -plow ntpd versuchen und sicher gehen das nicht ntpdate irgend wo dazwischen funkt.
Sorry. Mein Fehler!
Habe mich in den Spalten geirrt, Die Maschine dürfte mehr als 10 Minuten in der Zukunft sein.
Mich würde es nicht wundern wenn der NTPd hier eine Synchronisierung verweigern würde, aber laut dem Log hat er einfach brutal die Systemzeit richtig gestellt.
Jetzt stellt sich die Frage ob die Maschinen in kurzer Zeit so stark vorgehen können, oder ob ntpd zwar sagt er habe es getan, aber es doch nicht geklappt hat. Mir fehlen hier die Erfahrungswerte, da ich noch nie Ärger mit dem Dienst hatte.
Wird denn die Zeit mit ntpdate richtig gestellt?
Wenn ich den ntpd beende, kann ich mit
# ntpd -q -c ntp.conf
ntpd: time set -4.004165s
oder
#ntpdate ntp1.ptb.de
14 Oct 20:19:36 ntpdate[11611]: adjust time server 192.53.103.108 offset -0.337071 sec
die Zeit manuell synchronisieren. An der Log-Zeit oder mit date sieht man das er das auch macht.
Der ntpdate kann eigentlich nicht Schuld sein, weil der Port 123 von ntpd belegt ist, solange ntpd laeuft, kommt bei ntpdate die Meldung
# ntpdate ntp1.ptb.de
14 Oct 20:25:59 ntpdate[11645]: the NTP socket is in use, exiting
Ich hab mittlerweile festgestellt, dass es auf 4 Debian Lenny Rechnern das gleiche Problem mit der Zeitsynchronisation gibt.
Auf 2 anderen opensuse Rechnern gibt es das Problem nicht, die laufen zeitsynchron, sh.
# ntpdc -pn
remote local st poll reach delay offset disp
=======================================================================
*89.238.71.130 192.168.2.18 2 128 377 0.05504 -0.005016 0.05476
=127.127.1.0 127.0.0.1 10 64 377 0.00000 0.000000 0.03035
Als ntp server hab ich schon die alle durch probiert:
server de.pool.ntp.org
server 0.debian.pool.ntp.org iburst dynamic
server 1.debian.pool.ntp.org iburst dynamic
server 2.debian.pool.ntp.org iburst dynamic
server 3.debian.pool.ntp.org iburst dynamic
server ntp1.ptb.de
server ntp2.ptb.de
und wenn ich den lokalen eintrage synchronisiert er sich mit sich selbst und die Abweichung wird laufend groesser.
Ist zwar bei Nutzung von ntp etwas abwegig, aber vielleicht ist /etc/adjtime schuld. Diese Datei enthält eine Art Korrekturfaktor für zu langsam bzw. zu schnell laufende Uhren. Wenn man innerhalb kurzer Zeit mehrmals die Systemuhr stellt, kann dieser Wert sehr groß werden und die Uhr beginnt z.B. zu rennen.
Weicht die Systemzeit zu stark von der des ntp-Server ab, kann es dann passieren, dass die Synchronisation verweigert wird, weil offensichtlich etwas nicht stimmt.
Lösche also einfach mal die Datei /etc/adjtime.
Hallo,
ich hab die Datei /etc/adjtime geloescht, ohne Erfolg.
Dann hab ich openntpd installiert und genau das gleiche Problem, aber hier kam die Meldung im log
adjusting local clock by -122.988563s
und nichts passiert, d.h. die Zeit ist immer noch falsch.
Also nochmal die Manualseite zu ntpd durchsucht, da faellt mir auf, dass bei SEE ALSO adjtime(2) erwaehnt wird.
Komisch die Manualseite ist aber nicht da, deswegen Paket gesucht, Paket adjtimex gefunden, aber es nicht installiert (?), also installiert und siehe die Zeitdifferrenz laeuft nicht weiter auseinander, sondern wird langsam geringer.
Danke an alle, und besonders fuer den indirekten Hinweis auf adjtime.
Ich haette allerdings gedacht, dass notwendige Pakete fuer ntpd automatisch mitinstalliert werden. Was steht im openntpd Paket? Aha, ist nicht von adjtimex abhaengig, ist nicht so ganz optimal.
Hallo,
zur Kontrolle bitte tickadj aufrufen, Sollte einen Wert von 10000 ausgeben.
Danach versuchen wir es mit einer minimalistischen Konfiguration in /etc/ntp.conf:
server 192.53.103.104
server 127.127.1.0
driftfile /var/lib/ntp/ntp.drift
Ein driftfile darf nicht vorhanden sein (löschen), Das Verzeichnis /var/lib/ntp muß für den Nutzer ntp schreibbar sein.
Den ntp-daemon bitte stoppen.
Die Uhrzeit korrigieren mit
ntpdate 192.53.103.104
Den ntp-daemon wieder starten.
Dann 1* pro Minute für die nächsten 5 Minuten ntpq -p aufrufen.
Damit kann man ermitteln, wie die lokale Zeit driftet. Die offsets sind hier in millisekunden.
Ist der Fehler größer als 0.0005, dann korrigiert dies der NTP daemon nicht.