[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