Hallo, 26.06.2007 16:57,, Werner Flamme wrote::
Christian Pubanz schrieb:
noname:/home/christian # /usr/sbin/ntpdc -c peers localhost remote local st poll reach delay offset disp ======================================================================= *LOCAL(0) 127.0.0.1 10 64 377 0.00000 0.000000 0.03052 =195.244.96.13 192.168.178.21 2 256 377 0.02133 -26.35310 0.15089
Hallo Christian,
was soll "ntpdc -c peers" Dir zeigen (konnte ich Arnos Mail auch nicht entnehmen)?
Das ist nur meine Variante zu prüfen ob ntpd läuft und mit Servern syncronisiert.
Ich finde "ntpq -p" nicht nur kürzer, sondern auch aussagekräftiger - vorne steht nicht das =, sondern eine Kennung, die die eingeschätzte Qualität des jeweiligen Zeitservers angibt (von *=bevorzugt bis x=scheußlich).
Ist mir meistens egal :-) ich will nur wissen welche da sind und in Frage kommen könnten. Für das aktuelle Problem scheint mir das auch nicht wichtig zu sein.
Ich bin jetzt mal testweise von den PTB-Servern auf de.pool.ntp.org umgestiegen. Dazu sind sie da ;-) Es sei denn, Du hast ein größeres Firmennetzwerk zu versorgen...
Also: 1. Müsste ich hinbekommen, dass der NTPD beim Booten startet, sich nicht beendet und die Zeit syncronisiert. 2. Dass der NTPD in regelmäßigen Abständen der die Uhrzeit überprüft und ggf. korrigiert. Das Letzere ist genau das, was Aufgabe des ntpd ist. Das mit dem Start beim Booten ist allerdings so eine Sache :-( Der Befehl "insserv ntp" sollte in den jeweiligen Runleveln die Links setzen (wie der YaST Runlevel-Editor; wobei "ntp" der Name des Scripts in /etc/init.d ist - SLES 8, SLES 9 und SLES 10 sind da z. B. unterschiedlich: xntpd, ntp, ntpd). Beim nächsten Boot (oder "init 3") sollte der Zeitserver dann starten.
Er startet jedoch *nicht*, wenn die Abweichung der gefundenen Zeitserver von seiner eigenen Zeit eine bestimmte Frist übersteigt[1] :-/.
Das wird von den SuSE-Startskripten normalerweise durch ein vorneweg durchgeführtes ntpdate gelöst. Und wenn's daran läge dürfte der ntpd auch später nicht starten mögen, ausserndem müsste er dann was loggen (IIRC).
Oder wenn er keine Netzwerkverbindung findet...
Ich *vermute* inzwischen dass das Problem da liegt. Meine Lösung bzw. meine nächsten Schritte wären folgendes: Erstmal überprüfen ob das ntp-Startscript nach dem Netzwerk gestartet werden sollte. In der Shell 'ls /etc/rc.d/rc5.d/S*netw* /etc/rc.d/rc5.d/S*ntp*' eingeben und prüfen dass die Zahl hinter dem S bei network niedriger als bei ntp ist. Ist sie das nicht, dann sind die Required-Start-Angaben in den Startskripten ungünstig. So sehe ich hier bei mir grade dass bei SuSE 9.2 network NICHT Voraussetzung für ntp ist... das ist m.E. falsch. Das liesse sich beheben wenn man in der Zeile "# Required-Start: " im ntp-Startskript noch "network" hinzufügt und mit 'insserv ntpd' den Daemon nochmal aktiviert. Hoffe ich jedenfalls :-) Wenn das obige nicht das Problem ist, dann würde ich eine Zeile mit '/sbin/ifconfig' beim Anfang vom ntp-Startskript enfügen um zu sehen ob das Netzwerk zumindest schon verfügbar ist wenn ntpd gestartet werden soll.
[1] weswegen ich meinen Firmenzeitserver nach einem Reboot immer noch mal manuell kontrolliere :-(
Tja, vor allem wichtig wenn man mehrere Zeitserver betreibt die sich gegenseitig als Server nutzen sollen ;-)
Habe eben grade noch in der Boot.log folgendes gefunden: /var/lib/ntp/var/run/ntp/ntpd.pid -u Hängt das event. damit zusammen?
Ja, evtl. ;-) Das sagt erstmal aus, dass der Zeitserver im chroot läuft. Siehe Zeile NTPD_RUN_CHROOTED="yes" in /etc/init.d/ntp
Wenn der ntp chrooted läuft, sieht er das mit CHROOT_PREFIX angegebene Verzeichnis als / an. Die Angaben in der /etc/ntp.conf müssen also "addiert" werden. Wenn dort ein "driftfile /var/lib/ntp/drift/ntp.drift" eingetragen ist, der CHROOT_PREFIX auf /var/lib/ntp zeigt, liegt das Driftfile im Ergebnis unter /var/lib/ntp/var/lib/ntp/drift/ntp.drift. Analog wird das PID-file auf "$CHROOT_PREFIX/var/run/ntp/ntpd.pid" gesetzt (in /etc/init.d/ntp).
Letztes Mal als ich guckte sah es so aus als würde das Startskript das versuchen richtig zu lösen... und wenn's daran hängt dürfte der spätere Start auch nicht klappen.
Grüße
Christian
HTH Werner
Ebenso, Arno -- Arno Lehmann IT-Service Lehmann www.its-lehmann.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org