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

Martin Burnicki martin.burnicki at burnicki.net
Tue Dec 12 10:07:17 UTC 2017

Stephan E. wrote:
> 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.

Please post the contents of your ntp.conf file.

As Mike Cook already wrote, this should happen much faster if at least
one reliable NTP server can be reached.

Which OS are you running?

> 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.
> 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.
> Do you think the workaround is suitable, or am I inviting e.g. errors in
> leap second handling?

Please note that this is not "leap second handling". There are 2 leap
*bits* used as status, which are '11' after power up, meaning
'unsynchronized', and '00' after syncronization could be achieved.

Only in the rare case that a leap second has been scheduled for the end
of the current day, these bits are set to '01' for a leap second to be
inserted, or '10' for a leap second to be deleted. The latter has yet
never happened.


More information about the questions mailing list