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 _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
