[ntp:questions] The libntp resumee...

Kay Hayen kayhayen at gmx.de
Sun Sep 7 08:36:59 UTC 2008


Hello Harlan,

you wrote:

> If you use iburst in your config files and have a "good" value in the
> ntp.drift file, ntpd should sync up and be ready to go in about 11 seconds.
>
> Please see:
>
>  https://support.ntp.org/bin/view/Support/ConfiguringNTP
>
> and
>
>  https://support.ntp.org/bin/view/Support/StartingNTP

I wasn't aware of "ntp-wait" yet. Seems to do (almost) what we might want:

Quote :

----
If you have services (like some database servers) that require that the time 
is never "stepped" backwards, run: 
   ntp-wait -v

as late as possible in the boot sequence, before starting these time-sensitive 
services.
----

In effect that is what we want to do before the start of our application. But 
it doesn't solve the problem fully for us. We would want on our "other hosts" 
to have it check remote ntpd. That way we would have:

External NTPs <-> Entry Hosts <-> Other Hosts

The "entry hosts" would do simply local ntp-wait before starting the 
application, but otherwise behave as normal. They only need to iburst and 
then use default poll values.

The "other hosts" would do 2 ntp-wait on the 2 entry hosts. Only once either 
of them finishes, the ntpd is started and boot sequence continued.

Et voila, our simultaneous initialization problems would be gone. Checking the 
man page of ntp-wait on my Debian Testing here (4.2.4p4) it seems we would 
have to enable the query of remote hosts first, but that sounds like a rather 
simple patch.

The fundamental issue is that the "iburst" of the "other" hosts gets done 
before it is entirely useful (the entry hosts are only just synchronizing at 
best) and a remote ntp-wait could solve that.

Best regards,
Kay Hayen

PS: Addressing the support suggestion too. We will consider it definitely. So 
far only our customers have had such contracts for their operational use. But 
as we start to provide a NTP monitoring middleware as well, the situation 
will be entirely different. There we don't control the NTP setup at all, but 
only monitor it and raise alarms that will frequently result in support 
questions to us. We would like to have a partner for these, I presume. I will 
raise the issue in a meeting next week.




More information about the questions mailing list