[ntp:questions] Ruh, roh. Leap Second?

David L. Mills mills at udel.edu
Wed Jul 2 16:39:11 UTC 2008


Martin,

There can be a disconnect of serveral months between some gimmick in the 
development branch and when it appears on supermarket shelves; however, 
the current version does explicitly announce impending leaps in the 
protostats file and does take a vote among the sources on whether to 
mark the calendar for a leap. All this is overridden if the NIST 
leapseconds file is present.

Dave

Martin Burnicki wrote:
> Dave,
> 
> David L. Mills wrote:
> 
>>Peter,
>>
>>I head the same comment over the jungle telegraph. However, in the
>>distributions that leave here there is no such comment, so it would have
>>to come from somewhere else or from a modified distribution. 
> 
> 
> The message:
> 
>   Clock: inserting leap second 23:59:60 UTC
> 
> can be found in the Linux kernel sources. So this indicates ntpd has indeed
> received a leap second announcement from an upstream time source and has
> passed that announcement to the kernel which has then inserted the leap
> second. AFAIK that's the way leap seconds should be handled on systems
> which provide a kernel PLL.
> 
> The following "time reset" happened after that to undo the faulty leap
> second and step back to the correct time. 
> 
> So the basic question is from which upstream time source the faulty leap
> second announcement has been received. 
> 
> 
>>To help 
>>spot feckless fingers, recent versions have a protostats file in the
>>statistics collection and "official" reports go there, as well as the
>>system log if configured. These reports are described in the decode.html
>>page in the docuentation.
> 
> 
> I'm not familiar with the protostats file, but I assume it is only generated
> if explicitely configured in ntp.conf, similar to the other stats files.
> 
> Since such faulty leap second announcements have been reported here several
> times I'd really appreciate if there would be a log entry generated by
> default if a leap second announcement is received. That log entry should
> also indicate from which time source that announcement has been received,
> so a faulty time source could easily be identified and fixed or discarded
> in order to prevent those faults the next time.
> 
> Martin




More information about the questions mailing list