-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Jan 25, 2018 at 04:44:13PM +0100, Ralf Mattes wrote: 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 25.01.2018 17:17, schrieb Ralf Mattes: 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