ntpd zu schnell für ISDN-Verbindung
hallo alle, wenn ich "ntpd" aktiviere, wählt sich der Dämon zwar beim Neustart (mit kinternet - K ISDN Watch - xibod - Dial on Demand) zwar beim Provider ein, aber der Server antwortet nicht. Darum habe ich "ntpd" deaktiviert und unter .Kde/Autostart eine Verknüpfung zu Programm mit Befehl: " rcxntpd start" eingerichtet. Aber auch hier startet zwar "ntpd", aber der Server wird auch hierbei nicht erreicht. Die Kontrolle auf Konsole ergibt: ro999:~ # rcxntpd start Try to get initial date and time via NTP from 141.20.40.11 failed Starting network time protocol daemon (NTPD) done ro999:~ # ro999:~ # rcxntpd stop Shutting down network time protocol daemon (NTPD) done ro999:~# Nach dem "stop" habe ich mich dann e r s t beim Provider eingewählt und erst dann folgenden Befehl aufgerufen: ro999:~ # rcxntpd start Try to get initial date and time via NTP from 141.20.40.11 done Starting network time protocol daemon (NTPD) done ro999:~ # Und siehe da, alles OK. Es scheint so, als wenn "ntpd" für den Einwahl-Modus zu schnell ist. Wie kann ich erreichen, dass "ntpd" erst startet, wenn die Einwahl erfolgt ist und die Internet-Verbindung steht? Was müßte ich dafür tun, wenn ich den ntpd mit Yast aktiviere? Für alle Hilfen besten Dank im voraus Gruß Rolf
Vielleicht pingst Du erst einmal den Zielrechner an, bis er verfügbar ist (oder nach einer endlichen Anzahl von pings eben gar nicht) und startest den ntpd dann erst? So als Workaround ... keine Ahnung, ob es beim ntpd noch Timeouts gibt, die man ändern kann ... Am Dienstag, 16. August 2005 18:09 schrieb Rolf Hoff:
hallo alle,
wenn ich "ntpd" aktiviere, wählt sich der Dämon zwar beim Neustart (mit kinternet - K ISDN Watch - xibod - Dial on Demand) zwar beim Provider ein, aber der Server antwortet nicht.
Darum habe ich "ntpd" deaktiviert und unter .Kde/Autostart eine Verknüpfung zu Programm mit Befehl: " rcxntpd start" eingerichtet. Aber auch hier startet zwar "ntpd", aber der Server wird auch hierbei nicht erreicht.
Die Kontrolle auf Konsole ergibt:
ro999:~ # rcxntpd start Try to get initial date and time via NTP from 141.20.40.11 failed Starting network time protocol daemon (NTPD) done ro999:~ #
ro999:~ # rcxntpd stop Shutting down network time protocol daemon (NTPD) done ro999:~#
Nach dem "stop" habe ich mich dann e r s t beim Provider eingewählt und erst dann folgenden Befehl aufgerufen:
ro999:~ # rcxntpd start Try to get initial date and time via NTP from 141.20.40.11 done Starting network time protocol daemon (NTPD) done ro999:~ #
Und siehe da, alles OK.
Es scheint so, als wenn "ntpd" für den Einwahl-Modus zu schnell ist. Wie kann ich erreichen, dass "ntpd" erst startet, wenn die Einwahl erfolgt ist und die Internet-Verbindung steht? Was müßte ich dafür tun, wenn ich den ntpd mit Yast aktiviere?
Für alle Hilfen besten Dank im voraus Gruß Rolf
-- Heiko Nardmann (Dipl.-Ing. Technische Informatik) secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de), Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50
Am Dienstag, 16. August 2005 18:09 schrieb Rolf Hoff:
wenn ich "ntpd" aktiviere, wählt sich der Dämon zwar beim Neustart (mit kinternet - K ISDN Watch - xibod - Dial on Demand) zwar beim Provider ein, aber der Server antwortet nicht. (...).
rcxntpd holt sich ständig die Zeit, daher sehe ich bei einer DoD-Verbindung wenig Sinn in dessen Benutzung.
Es scheint so, als wenn "ntpd" für den Einwahl-Modus zu schnell ist. Wie kann ich erreichen, dass "ntpd" erst startet, wenn die Einwahl erfolgt ist und die Internet-Verbindung steht?
Dafür gibt es mehrere Möglichkeiten. Da du den xntpd schon korrekt eingerichtet hast (sprich XNTPD_INITIAL_NTPDATE in /etc/sysconfig/xntp enthält die Server) genügt es in /etc/sysconfig/network/providers/provider0 (der Dateiname kann von "provider0" abweichen) dafür zu sorgen, daß dort RUN_POLL_TCPIP='yes' vorkommt. Allerdings werden dann auch bei Mails und News abgeholt und Mails verschickt falls du fetchmail/fetchnews/sendmail konfiguriert hast (/etc/ppp/poll.tcpip angucken wie das genau festgestellt wird). Die andere Möglichkeit ist ein einfaches bash script in /etc/ppp/ip-up.d/ zu erstellen, welches damit nach erfolgreicher Einwahl gestartet wird, z. B. als root folgende 3 Zeilen als /etc/ppp/ip-up.d/xntpd speichern und mit chmod +x /etc/ppp/ip-up.d/xntpd ausführbar machen: #!/bin/bash /usr/sbin/rcxntpd ntptimeset
Was müßte ich dafür tun, wenn ich den ntpd mit Yast aktiviere?
Wenn du den aktivierst wirst du Probleme bekommen: linux:~ # rcxntpd ntptimeset Can't set time while ntpd is running failed Gruß, Jan -- Hindsight is an exact science.
Jan Ritzerfeld schrieb:
Am Dienstag, 16. August 2005 18:09 schrieb Rolf Hoff:
hi Jan [ . . . .]
rcxntpd holt sich ständig die Zeit, daher sehe ich bei einer DoD-Verbindung wenig Sinn in dessen Benutzung.
Nun ja, wenn ich es richtig sehe, dann kann mit DoD die Zeit nicht ständig geholt werden. Ich will aber wenigstens beim täglichen Neustart die Zeit prüfen/korrigieren lassen.
Es scheint so, als wenn "ntpd" für den Einwahl-Modus zu schnell ist. Wie kann ich erreichen, dass "ntpd" erst startet, wenn die Einwahl erfolgt ist und die Internet-Verbindung steht?
Dafür gibt es mehrere Möglichkeiten. Da du den xntpd schon korrekt eingerichtet hast (sprich XNTPD_INITIAL_NTPDATE in /etc/sysconfig/xntp enthält die Server) genügt es in /etc/sysconfig/network/providers/provider0 (der Dateiname kann von "provider0" abweichen) dafür zu sorgen, daß dort RUN_POLL_TCPIP='yes' vorkommt. Allerdings werden dann auch bei Mails und News abgeholt und Mails verschickt falls du fetchmail/fetchnews/sendmail konfiguriert hast
Damit hab ich keine Probleme, weil ich nur Mozilla verwende.
(/etc/ppp/poll.tcpip angucken wie das genau festgestellt wird).
siehe weiter unten
Die andere Möglichkeit ist ein einfaches bash script [ . . . . .]
Vielen Dank für Deine Anregungen. Dadurch angespornt zum Probieren, habe ich in /etc/ppp/poll.tcpip die Zeile 45 "/usr/sbin/rcxntpd try-restart-iburst || /usr/sbin/rcxntpd ntptimeset" deaktiviert und ersetzt durch "/usr/sbin/rcxntpd restart;/usr/sbin/rcxntpd restart" (ohne "") Bei nur einem restart, kann/wird der Aufruf (wie bisher) fehlschlagen. Bei doppeltem Aufruf und einem "failed" beim ersten restart, tut's dann aber der 2. Aufruf. Und schaden tut's ja nicht, den Befehl zu wiederholen. Mit "ntpdtimeset" funzt das nicht, weil für diesen Befehl ntpd womöglich erst deaktiviert werden muss. Außerdem wird bei dem Original-Eintrag (siehe oben) der Teil der Zeile hinter "||" gar nicht ausgeführt. Damit ist mein Problem gelöst. Nochmals vielen Dank Gruß Rolf
Am Mittwoch, 17. August 2005 18:16 schrieb Rolf Hoff:
Jan Ritzerfeld schrieb:
Am Dienstag, 16. August 2005 18:09 schrieb Rolf Hoff:
hi Jan [ . . . .]
rcxntpd holt sich ständig die Zeit, daher sehe ich bei einer DoD-Verbindung wenig Sinn in dessen Benutzung.
Nun ja, wenn ich es richtig sehe, dann kann mit DoD die Zeit nicht ständig geholt werden.
Aber das versucht xntpd dann trotzdem die ganze Zeit. Da ich kein DoD benutze weiß ich nicht, ob sich dein Rechner dann nicht auch dauernd versucht einzuwählen. Sieh dir auf jeden Fall mal /var/log/ntp an. Ich meine mich daran erinnern zu können, daß bei einem Wechsel der IP keine Zeit mehr geholt werden kann (DSL hier). Und "xntpdc -p" als root zeigt dir den momentanen Synchronisationsstatus an. Ich mußte außerdem noch Port 123/udp in der Firewall freischalten. chrony ist für Dial-Up-Verbindungen gedacht, aber ich weiß nicht, wo man das als SUSE-RPM herbekommt.
Ich will aber wenigstens beim täglichen Neustart die Zeit prüfen/korrigieren lassen.
Also nicht erst, wenn der Rechner ins Netz geht? Das wird doch wahrscheinlich sogar noch öfters sein, oder?
(...).
Dafür gibt es mehrere Möglichkeiten. Da du den xntpd schon korrekt eingerichtet hast (sprich XNTPD_INITIAL_NTPDATE in /etc/sysconfig/xntp enthält die Server) genügt es in /etc/sysconfig/network/providers/provider0 (der Dateiname kann von "provider0" abweichen) dafür zu sorgen, daß dort RUN_POLL_TCPIP='yes' vorkommt. Allerdings werden dann auch bei Mails und News abgeholt und Mails verschickt falls du fetchmail/fetchnews/sendmail konfiguriert hast
Damit hab ich keine Probleme, weil ich nur Mozilla verwende.
Gut, ich dachte aber auch daran, sinnlose Anfragen ins Netz zu sparen. :)
(...). Vielen Dank für Deine Anregungen. Dadurch angespornt zum Probieren, habe ich in /etc/ppp/poll.tcpip die Zeile 45
Ich würde diese Datei nicht einfach ändern. Sie wird wahrscheinlich zu irgendeinem Paket gehören: "rpm -qf /etc/ppp/poll.tcpip" Und wenn das mal geupdatet werden muß wird die entweder überschrieben oder nicht geupdatet. Ich würde dann eher RUN_POLL_TCPIP auf 'no' setzen und den Weg über ein bash script /etc/ip-up.d/ gehn, so habe ich das wegen der 24h-DSL-Trennung gemacht.
"/usr/sbin/rcxntpd try-restart-iburst || /usr/sbin/rcxntpd ntptimeset"
Oh, du benutzt SL 9.3? Mein 9.2 rcxntpd kennt try-restart-iburst nämlich gar nicht. X-)
deaktiviert und ersetzt durch
"/usr/sbin/rcxntpd restart;/usr/sbin/rcxntpd restart" (ohne "")
Bei nur einem restart, kann/wird der Aufruf (wie bisher) fehlschlagen. Bei doppeltem Aufruf und einem "failed" beim ersten restart, tut's dann aber der 2. Aufruf. Und schaden tut's ja nicht, den Befehl zu wiederholen.
Naja, es ist nur unschön! :) Aber /etc/ppp/poll.tcpip wird doch erst ausgeführt wenn die Verbindung sicher steht, bei SL 9.2 sind dort auch nochmal 5 Sekunden Pause drin. Der erste Aufruf sollte also nicht fehlschlagen wie vorher, weil die Verbindung schon längst steht! (/etc/ppp/poll.tcpip wird /nach/ jedem Verbindungsaufbau gestartet)
Mit "ntpdtimeset" funzt das nicht, weil für diesen Befehl ntpd womöglich erst deaktiviert werden muss.
Klar! Aber da ein laufender xntpd bei DoD IMHO nicht sinnvoll ist, würde ich den eh deaktivieren. ntpdtimeset wird ja trotzdem funktionieren und du hast keinen nutzlosen Service im Hintergrund laufen.
Außerdem wird bei dem Original-Eintrag (siehe oben) der Teil der Zeile hinter "||" gar nicht ausgeführt.
D.h. aber try-restart-iburst ist erfolgreich! Funktioniert es denn trotzdem nicht wie gewünscht? Guck mal in ntp logfile, was da schief geht.
Damit ist mein Problem gelöst. Nochmals vielen Dank
Keine Ursache, Jan -- Goto: A programming tool that exists to allow structured programmers to complain about unstructured programmers.
Jan Ritzerfeld schrieb:
Am Mittwoch, 17. August 2005 18:16 schrieb Rolf Hoff:
Jan Ritzerfeld schrieb:
Am Dienstag, 16. August 2005 18:09 schrieb Rolf Hoff:
hi Jan [ . . . .]
rcxntpd holt sich ständig die Zeit, daher sehe ich bei einer DoD-Verbindung wenig Sinn in dessen Benutzung.
Nun ja, wenn ich es richtig sehe, dann kann mit DoD die Zeit nicht ständig geholt werden.
Aber das versucht xntpd dann trotzdem die ganze Zeit.
Das trifft jetzt auch bei mir zu, laut /var/log/ntp z.B. wie folgt: "19 Aug 16:35:35 ntpd[7776]: sendto(130.149.17.21): \ Invalid argument"
Da ich kein DoD benutze weiß ich nicht, ob sich dein Rechner dann nicht auch dauernd versucht einzuwählen. Sieh dir auf jeden Fall mal /var/log/ntp an.
s. o. - Es kommt aber nicht zu einer Internetverbindung [ . . . .]
deaktiviert und ersetzt durch
"/usr/sbin/rcxntpd restart;/usr/sbin/rcxntpd restart" (ohne "")
Bei nur einem restart, kann/wird der Aufruf (wie bisher) fehlschlagen. Bei doppeltem Aufruf und einem "failed" beim ersten restart, tut's dann aber der 2. Aufruf. Und schaden tut's ja nicht, den Befehl zu wiederholen.
Naja, es ist nur unschön! :)
Wie ich inzwischen in den xntp-doc's nachgelesen habe, ist mein vorstehender Vorschlag wohl doch nicht so problemlos hinnehmbar. Ich habe es deshalb rückgängig gemacht. [ . . . . ]
Bei weiterem Forschen nach meinem Fehler habe ich dann gemerkt, dass der von mir mit Google gesuchte Time-Server die Probleme machte. Als ich den dann gelöscht hatte und stattdessen einen aus der Liste von ntp gewählten Server konfiguriert habe, war der ganze Spuk wirklich vorbei. Nochmals besten Dank für alle Hilfen Gruß Rolf
participants (3)
-
Jan Ritzerfeld -
Nardmann, Heiko -
Rolf Hoff