• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

ntpd synchronisiert nicht

A

achim_g

Hallo,

welche Gründe könnte es geben, dass ntpd nicht synchronisiert? Nach dem Start tut er es erstmal und dann nicht mehr.

Code: 
# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ptbtime1.ptb.de .PTB.            1 u   20   64  377   11.587  404988. 135891.
 ntps1-0.cs.tu-b .PPS.            1 u   20   64  337   12.806  451539. 194512.
 ntp1-rz.rrze.un .DCFp.           1 u   16   64  377    4.571  175525. 208020.

Achim
 
L

Leviathan

Vermutlich synced der nicht mehr, weil der Offsetwert schon zu groß ist.

Probier mal ein ntpdate -ub ptbtime1.ptb.de
und setze die Bioszeit korrekt und guck auch mal ggf. ob das ntp driftfile einen einigermaßen passablen Wert hat.

Gruß Dominik
 
Geier0815

Geier0815

Das der ntpd nicht synchronisiert hat den einfachen Grund das er für die Clients maßgebend ist, dh würde er im laufenden Betrieb die Zeit ändern, könnte es zu Schwierigkeiten mit den Clients kommen. Deswegen stellt er sich nur beim Start einmal und arbeitet dann auf seiner internen Uhr weiter.
 
panamajo

panamajo

Geier0815 schrieb:
Das der ntpd nicht synchronisiert hat den einfachen Grund das er für die Clients maßgebend ist, dh würde er im laufenden Betrieb die Zeit ändern, könnte es zu Schwierigkeiten mit den Clients kommen. Deswegen stellt er sich nur beim Start einmal und arbeitet dann auf seiner internen Uhr weiter.
Zum Vergrößern anklicken....
Die initiale Synchronisierung beim Start des ntpd erfolgt (optional) via ntpdate.
Tatsächlich ändert ntpd die Systemzeit, aber auf eine Art und Weise die die angesprochenen Probleme bei den Clients umgeht. Essentiell ist dass die Zeit stehtig fortschreitet, es also in der Zukunft immer später ist als jetzt. Dies ist nicht gewährleistet wenn man z.B. alle 10min per ntpdate die Zeit neu setzt: eine zu schnell laufende BIOS Uhr würde plötzlich in die Vergangenheit zurückgesetzt.
Vereinfacht gesagt staucht und dehnt ntpd die Systemzeit an Hand der Informationen die von den Zeitservern erhalten werden.
 
P

pallmall

panamajo schrieb:
Tatsächlich ändert ntpd die Systemzeit, aber auf eine Art und Weise die die angesprochenen Probleme bei den Clients umgeht. ...
Zum Vergrößern anklicken....

Doch wie oben beschrieben tut er dass wohl nicht, oder nicht richtig. Denn bei mir taucht das beschriebene Problem ebenfalls auf. Auf meinem Server tut es seit kurzem eine Open SUSE 10. 2, Kernel 2.6.18.2-34-default. Das ganze läuft auf einem AMD Opteron 146. Und nur beim Neustart des ntpd wird einmal die Zeit korrigiert. Ab dann läuft die Uhrzeit ca. 7 Sekunden am Tag weg. Da wird weder etwas gedehnt noch gestaucht denn das gleiche Ergebnis erhalte ich auch wenn ich den ntpd stoppe.
 
Geier0815

Geier0815

Dann wird beim Start ein ntpdate ausgeführt und der ntpd holt sich nichts von einer externen Quelle. Ich meine zwar nach wie vor das dies auch so sein muß, aber spaßeshalber könntest Du uns ja mal deine Konfig posten, evtl. kann man da ja noch was schrauben.
 
P

pallmall

Gerne^^ hier dann erst einmal die /etc/ntp.conf
Code: 
################################################################################
## /etc/ntp.conf
##
## Sample NTP configuration file.
## See package 'ntp-doc' for documentation, Mini-HOWTO and FAQ.
## Copyright (c) 1998 S.u.S.E. GmbH Fuerth, Germany.
##
## Author: Michael Andres,  <ma@suse.de>
##
################################################################################

##
## Radio and modem clocks by convention have addresses in the
## form 127.127.t.u, where t is the clock type and u is a unit
## number in the range 0-3.
##
## Most of these clocks require support in the form of a
## serial port or special bus peripheral. The particular
## device is normally specified by adding a soft link
## /dev/device-u to the particular hardware device involved,
## where u correspond to the unit number above.
##
## Generic DCF77 clock on serial port (Conrad DCF77)
## Address:     127.127.8.u
## Serial Port: /dev/refclock-u
##
## (create soft link /dev/refclock-0 to the particular ttyS?)
##
# server 127.127.8.0 mode 5 prefer

##
## Undisciplined Local Clock. This is a fake driver intended for backup
## and when no outside source of synchronized time is available.
##
server 127.127.1.0		# local clock (LCL)
fudge  127.127.1.0 stratum 10	# LCL is unsynchronized

##
## Outside source of synchronized time
##
## server xx.xx.xx.xx		# IP address of server

##
## Miscellaneous stuff
##

driftfile /var/lib/ntp/drift/ntp.drift # path for drift file

logfile   /var/log/ntp		# alternate log file
# logconfig =syncstatus + sysevents
# logconfig =all

# statsdir /tmp/		# directory for statistics files
# filegen peerstats  file peerstats  type day enable
# filegen loopstats  file loopstats  type day enable
# filegen clockstats file clockstats type day enable

#
# Authentication stuff
#
# keys /etc/ntp.keys		# path for keys file
# trustedkey 1 2 3 4 5 6 14 15	# define trusted keys
# requestkey 15			# key (7) for accessing server variables
# controlkey 15			# key (6) for accessing server variables

server ntp1.stratoserver.net
server ntp2.stratoserver.net
server ntps1-0.cs.tu-berlin.de
restrict default ignore
restrict 127.0.0.1

ich weiß nicht ob es Sinn macht die /etc/init.d/ntp auch hier zu posten, die ist ja ein bisschen lang. An der hab ich aber auch nicht geschraubt, die ist noch im Ursprungszustand. Erwähnenswert ist vielleicht noch der Eintrag NTPD_INITIAL_NTPDATE="AUTO-2" darin.

Wenn ich den ntpd neu starte bekomme ich folgende Ausgabe:
serverx:~ # rcntp restart
Shutting down network time protocol daemon (NTPD) done
Try to get initial date and time via NTP from ntps1-0.cs.tu-berlin.dedone
Starting network time protocol daemon (NTPD) done

in den logs ist folgendes zu lesen:
Aug 25 13:55:20 serverx ntpdate[25292]: step time server 130.149.17.21 offset -30.703547 sec
Aug 25 13:55:20 serverx ntpd[25301]: ntpd 4.2.2p4@1.1585-o Sat Nov 25 18:44:34 UTC 2006 (1)
Aug 25 13:55:20 serverx ntpd[25302]: precision = 1.000 usec
Aug 25 13:55:20 serverx ntpd[25302]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
Aug 25 13:55:20 serverx ntpd[25302]: Listening on interface wildcard, 0.0.0.0#123 Disabled
Aug 25 13:55:20 serverx ntpd[25302]: Listening on interface lo, 127.0.0.1#123 Enabled
Aug 25 13:55:20 serverx ntpd[25302]: Listening on interface eth0, 85.214.71.149#123 Enabled
Aug 25 13:55:20 serverx ntpd[25302]: kernel time sync status 0040
Aug 25 13:55:20 serverx ntpd[25302]: frequency initialized 0.000 PPM from /var/lib/ntp/drift/ntp.drift



serverx:~ # /etc/init.d/ntp status ergibt:
Checking for network time protocol daemon (NTPD): running


Ergo kann der ntpd den Timeserver abfragen, logisch denn beim restart wird die Zeit ja korrekt gestezt. Nur dann tut sich nie wieder was und die Uhr driftet wieder ab.
 
T

Tooltime

Bei Problemen mit ntp ist die Ausgabe von ntpq -p ein guter Einstieg. Damit die interne Uhr synchronisiert wird muss ntp den externen Zeitquellen erst einmal vertrauen. Dazu bewertet er die einzelnen Quellen gegen einander und gegen die interne Uhr. Dieser Vorgang kann beim ersten Mal bis zu einer Stunde dauern und wird immer kontinuierlich fortgesetzt, wobei die aktuellen Werte im Drift-File gespeichert werden. Genau diese Informationen kann man mit obigen Befehl abfragen.
 
P

pallmall

Die Ausgabe von ntpq -p sieht so aus:
Code: 
serverx:~ # ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*LOCAL(0)        .LOCL.          10 l   33   64  377    0.000    0.000   0.001
 dhcp30.rl.b.rz- .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 dhcp20.rl.b.rz- .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 ntps1-0.cs.tu-b .INIT.          16 u    - 1024    0    0.000    0.000   0.000

Im driftfile steht lediglich eine 0.000. Seltsam, /var/lib/ntp/drift/ntp.drift tragt als Datumsstempel den Tag der Serverneuinstallation :???: Müßte das Verzeichnis /var/lib/ntp/ nicht dem User ntp als Besitzer zuordnet sein und nicht root? Hmm... werd das mal ausprobieren!
 
T

Tooltime

a)
Keiner der Zeitserver ist erreichbar bis auf die lokale Uhr (Spalte reach = 0).

b)
Daher übernimmt die lokale Uhr die Führung (* vor Zeitservername in Spalte remote)

c)
Die Zeitserver entsprechen nicht denen in der oben dargestellten Konfiguration.

Also ist es nicht verwunderlich das die Genauigkeit exakt der internen Uhr entspricht!
Wie sieht den die Configdatei in der chroot-Umgebung (/var/lib/ntp/etc/ntp.conf) aus?
Scheint als würde per DHCP die NTP-Konfiguration übergebügelt.
 
T

Tooltime

Habe keine 10.3 zur Hand, daher kann es sein das die Bezeichnungen nicht exakt stimmen.
YaST -> Netzwerkdienste -> NTP-Client
unter
Komplexe Konfiguration
nach schauen ob
NTP-Daemon über DHCP konfigurieren
aktiviert ist?
 
P

pallmall

Yast sagt mit hierzu:
Code: 
[x] NTP-Daemon in Chroot-Jail ausführen
[ ] NTP-Daemon über DHCP konfigurieren

Synchronisierungstyp             │Adresse
Server                           │ntp2.stratoserver│
Server                           │ntps1-0.cs.tu-ber-
 
T

Tooltime

nslookup ntp1.stratoserver.net ergibt:
Code: 
Non-authoritative answer:
ntp1.stratoserver.net   canonical name = ntp1.rz-ip.net.
ntp1.rz-ip.net  canonical name = dhcp30.rz-ip.net.
dhcp30.rz-ip.net        canonical name = dhcp30.rl.b.rz-ip.net.
Name:   dhcp30.rl.b.rz-ip.net
Address: 85.214.7.20
Also scheinen die unterschiedlichen Namen für die Zeitserver normal zu sein.

Verbindung testen mit ping dhcp30.rl.b.rz-ip.net.

Läuft auf dem Rechner eine Firewall, dann
YaST -> Netzwerkdienste -> NTP-Client
unter
Komplexe Konfiguration
nach schauen ob
Firewall-Port öffnen
aktiviert ist und mit Button
Firewall-Details
kontrollieren ob auch die richtige Netzwerkschnittstelle ausgewählt ist.
 
P

pallmall

Das ping zeigt Erreichbarkeit:
--- dhcp30.rl.b.rz-ip.net ping statistics ---
55 packets transmitted, 55 received, 0% packet loss, time 54024ms
rtt min/avg/max/mdev = 0.362/0.628/8.807/1.118 ms
Zum Vergrößern anklicken....

Die Firewall ist derzeit deaktiviert da ich Probleme mir deren Config gleich ausschließen wollte so lange der ntpd seinen Dienst verweigert. Und selbst wenn sie aktiv wäre sollte durch den Eintrag FW_SERVICES_EXT_UDP="123" in der Config der Firewall der entsprechende Port frei sein.
 
P

pallmall

Das ist noch jene welche nach der Installation von SuSE10.2 vorhanden war. Da es von Anfang an nie funktioniert hatte hab ich lediglich zum testen den Zeitserver der TU-Berlin manuell hinzu gefügt.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben