[ntp:questions] long time to report sync per leap indicator, when initial system time is set far into the future

Stephan E. public-se at innominate.com
Tue Dec 12 08:36:09 UTC 2017

On 12/12/2017 04:00 AM, Harlan Stenn wrote:
> "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?

The only connection I am drawing to leap seconds is from my ntpd sending packets with LI=3, "leap indicator unknown / not synced"

>> 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.

yes, I am using both

>> 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.

More information about the questions mailing list