Hi Liste, ich habe ein kleines Problem mit dem ntpd. Wenn eine Verbindung via PPP aufgebaut wird, benötigt der ntpd +1min um auf diesem Interface zu lauschen. Leider sind die Verbindungen kurz und in der Regel nach 1min bereits beendet. Das führt dazu, dass die Zeit nicht gesetzt wird.
Hat jemand eine Idee wie ich den ntpd dazu bewege, sofort zu reagieren ?
re, wh
Am Donnerstag, 25. Januar 2018 15:02 CET, walter harms wharms@bfs.de schrieb:
Hi Liste, ich habe ein kleines Problem mit dem ntpd. Wenn eine Verbindung via PPP aufgebaut wird, benötigt der ntpd +1min um auf diesem Interface zu lauschen. Leider sind die Verbindungen kurz und in der Regel nach 1min bereits beendet. Das führt dazu, dass die Zeit nicht gesetzt wird.
Du meinst jemand wählt sich auf dem Server ein?
Hat jemand eine Idee wie ich den ntpd dazu bewege, sofort zu reagieren ?
"Sofort" istrelativ (wie so ziemlich alles ;-) Wenn Dir "innerhalb einer genügend kurzen Zeit" reicht (z.Bsp. 20 Sek.) dann reicht ja eigentlich der '-U' Parameter des Servers, oder sehe ich das falsch? Leider hat der kein (dokumentieren) Signal Handler über den man ihn im ifup-Script anstubsen könnte. Du könntest natürlich auch ein spezielles Bridge-Interface anlegen auf welches er immer lauscht und dann dass PPP-Interface daran binden ....
Happy networking
RalfD
re, wh _______________________________________________ Freiburger Linux User Group Mail an die Liste: flug@lug-freiburg.de Mailingliste verwalten (u.a. abbestellen): https://www.lug-freiburg.de/mailman/listinfo/flug
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, Jan 25, 2018 at 04:44:13PM +0100, Ralf Mattes wrote:
Am Donnerstag, 25. Januar 2018 15:02 CET, walter harms wharms@bfs.de schrieb:
Hi Liste, ich habe ein kleines Problem mit dem ntpd. Wenn eine Verbindung via PPP aufgebaut wird, benötigt der ntpd +1min um auf diesem Interface zu lauschen. Leider sind die Verbindungen kurz und in der Regel nach 1min bereits beendet. Das führt dazu, dass die Zeit nicht gesetzt wird.
Du meinst jemand wählt sich auf dem Server ein?
Hat jemand eine Idee wie ich den ntpd dazu bewege, sofort zu reagieren ?
"Sofort" istrelativ (wie so ziemlich alles ;-) Wenn Dir "innerhalb einer genügend kurzen Zeit" reicht (z.Bsp. 20 Sek.) dann reicht ja eigentlich der '-U' Parameter des Servers, oder sehe ich das falsch?
Hat der ntpd dafür nicht die "-q" Option?
Aus der man page:
| In some cases it may not be practical for ntpd to run | continuously. A common workaround has been to run the ntpdate | program from a cron job at designated times. However, this program | does not have the crafted signal processing, error checking and | mitigation algorithms of ntpd[char46] The -q option is intended | for this purpose. Setting this option will cause ntpd to exit just | after setting the clock for the first time with the configured | servers. The procedure for initially setting the clock is the | same as in continuous mode; most applications will probably | want to specify the iburst keyword with the server configuration | command. With this keyword a volley of messages are exchanged to | groom the data and the clock is set in about 10 s. If nothing | is heard after a couple of minutes, the daemon times out and | exits. After a suitable period of mourning, the ntpdate program | may be retired.
(konnte es mir nicht verkneifen, es voll zu zitieren :)
Also nicht ständig als Dämon laufen lassen, bei Ersteinrichtung ihn mal lange die Chance geben, die Hardware-Uhr zu "disziplinieren", dann immer beim ifup mit -q starten?
Könnte ein Versuch wert sein...
lg - -- t
Am Donnerstag, 25. Januar 2018 17:11 CET, tomas@tuxteam.de schrieb:
(konnte es mir nicht verkneifen, es voll zu zitieren :)
Also nicht ständig als Dämon laufen lassen, bei Ersteinrichtung ihn mal lange die Chance geben, die Hardware-Uhr zu "disziplinieren", dann immer beim ifup mit -q starten?
Könnte ein Versuch wert sein...
Da habe ich Walther wohl falsch verstanden - Ich dachte er hatte einen Server (mit ntp-Server) bei dem sich irgendwelche "Teile" einwählen. IoT oder so (bei Walther könnte es an Skynet sein ;-) Die werden wahrscheinlich irgendetwas übermitteln (Messwerte?) und bei der Gelegenheit auch gleich ihre Zeit mit der des Servers abgleichen (als ntp-Anfrage von Client an den Server. Wenn der dann noch nicht lauscht geht das schief ...).
Gruss Ralfd
lg
- -- t
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAlpqAaEACgkQBcgs9XrR2kajBwCfVwVSBTnTOKQKAg022QmMr/FL ASQAn3OAtWKU2dnHkSFzgFi9U3ZaRzMD =PuPD -----END PGP SIGNATURE----- _______________________________________________ Freiburger Linux User Group Mail an die Liste: flug@lug-freiburg.de Mailingliste verwalten (u.a. abbestellen): https://www.lug-freiburg.de/mailman/listinfo/flug
Am 25.01.2018 17:17, schrieb Ralf Mattes:
Am Donnerstag, 25. Januar 2018 17:11 CET, tomas@tuxteam.de schrieb:
(konnte es mir nicht verkneifen, es voll zu zitieren :)
Also nicht ständig als Dämon laufen lassen, bei Ersteinrichtung ihn mal lange die Chance geben, die Hardware-Uhr zu "disziplinieren", dann immer beim ifup mit -q starten?
Könnte ein Versuch wert sein...
Da habe ich Walter wohl falsch verstanden - Ich dachte er hatte einen Server (mit ntp-Server) bei dem sich irgendwelche "Teile" einwählen. IoT oder so (bei Walter könnte es an Skynet sein ;-) Die werden wahrscheinlich irgendetwas übermitteln (Messwerte?) und bei der Gelegenheit auch gleich ihre Zeit mit der des Servers abgleichen (als ntp-Anfrage von Client an den Server. Wenn der dann noch nicht lauscht geht das schief ...).
Gruss Ralfd
Du hast das völlig korrekt verstanden. Die Stationen wählen sich ein und holen die Zeit. Der ntpd braucht aber solange dass die Verbindung schon weg ist, wenn er es merkt. Ich hatte gehofft, es gibt ein Option dieses zu beschleunigen, habe aber selber nichts gefunden.
Nachdem ich kurz erwogen hatte einen Patch zu schreiben der auf ein Signal die Interfaces scant, und dabei entdeckt habe, dass SIGHUB für einlesen von leapsecunden schon verwendet wird, ist mir eingefallen das es rdate auch noch gibt ...
re, wh