[ntp:questions] long time to report sync per leap indicator, when initial system time is set far into the future
stenn at ntp.org
Tue Dec 12 03:00:49 UTC 2017
"Stephan E." writes:
> I want ntpd 4.2.8p10 to sync to public servers, then serve time to a
> local network. It is running with '-g' because initial system time on
> the host can be far off. I observe that, when initial system time of
> the host was set > 5 minutes into the future, the time it will take
> ntpd to report a synced leap second to its clients approaches the time
> of that initial offset. E.g., when the initial time was erroneously
> set 24 hours into the future, ntpd will take approximately 24 hours to
> report a synced time in the LI field to its clients, and they will
> reject to sync to my host during that period.
What does this have to do with a leap second?
> Is this behavior to be expected, or is it likely that am I doing
> something wrong? I would agree that it is a weird scenario, but it can
> not be ruled out in my application.
That depends on your ntp.conf file. If you are using "server"
statments, you want to be using iburst.
> A workaround appears to be running with '-g -q' first, in which case
> ntpd will sync and exit under 1 minute; then run without either
> option, in which case the LI field will report a sync within
> approx. 300s.
That seems strange. You should not need to run '-g -q' first and then
restart ntpd. It should be better/easier to run ntpd *at cold start*
with -g. Subsequent restarts of ntpd should *not* use -g.
> Do you think the workaround is suitable, or am I inviting e.g. errors
> in leap second handling?
I'm still not seeing what this has to do with a leap second.
Harlan Stenn <stenn at ntp.org>
http://networktimefoundation.org - be a member!
More information about the questions