Diese Ausschrift:
root@new:~# ntpq -p
No association ID's returned
oder anders gefragt:
root@new:~# ntpq
ntpq> opeer
No association ID's returned
ntpq>
sagt etwas anderes aus als diese ..?
root@new:~# netstat -tulpan | grep ntp tcp 0 0 127.0.0.1:48316 127.0.0.1:34319 CLOSE_WAIT 7074/ntpd udp 0 0 10.136.20.99:59799 10.136.9.21:53 ESTABLISHED 7074/ntpd udp 87552 0 10.136.20.99:123 0.0.0.0:* 7074/ntpd udp 0 0 127.0.0.1:123 0.0.0.0:* 7074/ntpd udp 0 0 0.0.0.0:123 0.0.0.0:* 7074/ntpd udp6 0 0 ::1:123 :::* 7074/ntpd udp6 0 0 fe80::250:56ff:feac:123 :::* 7074/ntpd udp6 0 0 :::123 :::* 7074/ntpd
Das Problem: Der NTP Server ist zwar gestartet, findet jedoch seine Quellen nicht. Konfiguriert wurden 3 PTB Zeitserver.
less /etc/ntp.conf
Der Blick in das Syslog File verrät uns, dass der Server die DNS Namen nicht auflösen kann:
tail -f /var/log/syslog
Jun 1 09:59:48 new ntpd[5591]: Deferring DNS for ptbtime1.ptb.de 1
Nun tragen wir in die Resolv.conf einen gültigen DNS Server ein:
root@new:~# su admin Proteus> configure Proteus> configure name-server Proteus:configure:name-server> add address domain-name search-domain Proteus:configure:name-server> remove address 10.136.9.21 Proteus:configure:name-server> save Proteus:configure:name-server> add address domain-name search-domain Proteus:configure:name-server> add address 10.136.20.100 Proteus:configure:name-server> save Proteus:configure:name-server> exit Proteus> exit
NTP Server am Proteus (Network Address Manager) starten:
Pamclient node set ntp-enable=1
NTP Server am Proteus (Network Address Manager) beenden:
Pamclient node set ntp-enable=0
Diagnose mit:
root@new:~# ntpq -pcrv remote refid st t when poll reach delay offset jitter ============================================================================== *ptbtime1.ptb.de .PTB. 1 u 1059 1024 377 45.914 3.488 41.797 +ptbtime2.ptb.de .PTB. 1 u 975 1024 177 30.240 -3.048 108.086 +ptbtime3.ptb.de .PTB. 1 u 26 1024 377 63.797 13.136 139.749 associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync, version="ntpd 4.2.6p5@1.2349-o Fri Jan 17 20:46:16 UTC 2014 (1)", processor="x86_64", system="Linux/3.5.4-amd64", leap=00, stratum=2, precision=-22, rootdelay=45.914, rootdisp=92.500, refid=192.53.103.108, reftime=d736aff1.3b3b83f7 Mon, Jun 2 2014 10:10:25.231, clock=d736bc56.3b32e1f1 Mon, Jun 2 2014 11:03:18.231, peer=44042, tc=10, mintc=3, offset=2.050, frequency=39.387, sys_jitter=5.617, clk_jitter=5.631, clk_wander=0.135
Die Spalte „refid“ gibt einen Hinweis, welche Art von Zeitquelle der Server selbst benutzt. Stratum-1-Server geben hier beispielsweise .GPS. für einen GPS-Empfänger an, .DCF. deutet auf eine DCF77-Funkuhr hin, .PPS. auf eine Uhr, die einen Puls pro Sekunde erzeugt. Server höherer Strata geben als refid ihren Referenzserver an.
Im ersten Zeichen der ersten Spalte, vor dem Servernamen, kodiert ntpq den Vertrauensstatus:
- * kennzeichnet den aktuellen Referenzserver,
- + diejenigen, die in die Mittelwertsberechnung der Uhrzeit eingehen.
- # markiert ntpd einen Server, der zwar ebenfalls geeignet wäre, aber weiter hinten in der Bewertungsreihenfolge steht.
- x kennzeichnet Rechner, die über längere Zeit keine verlässlichen Werte lieferten (False Ticker).
- – = Server, die bei der letzten Abfrage eine zu weit abweichende Zeit lieferten. Falls das für einen weiter entfernt stehenden Server häufig auftritt, sollte man ihn auch aus der Liste löschen.
Nothilfemaßnahmen, wenn der NTP Dienst nicht funktionert = NTP Zeit am Host direkt setzen:
ntpdate -d -u 10.136.20.99 (-d = debug)