[ntp:questions] Leap second bug?
martin.burnicki at meinberg.de
Fri Jan 4 10:04:16 UTC 2008
> Spoon wrote:
>> ntpd kicked my clock forward one second on January 1 at 00:19:38 UTC.
>> I also noticed that, the day before, the STA_INS (insert leap second) had
>> been set and reset several times.
>> Could this be a leap year bug? or did I just lose connectivity at the
>> wrong time and it's just a coincidence?
I don't think it's a leap year bug since NTP and the UTC system clock do
only deal with seconds after an epoche. The leap year thing comes into
effect only when those seconds are converted to human-readable calendar
Lost connectivity could not be the reason. Ntpd only passes leap second
announcement on if it has received such announcement
- from an upstream server
- from a reference clock
- from the NIST leap seconds file
Ntpd can not receive a leap second announcement from an upstream server if
the upstream server is not reachable.
A potential reason could be a bug in ntpd, in which case we had to look at
the source code of the exact version of ntpd, which is 4.2.4p0 at 1.1472
according to the ntpq output below. Since the billboard does not display a
tai value I assume a NIST leap second file is not involved here.
>> # ntpq -crv
>> assID=0 status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
>> version="ntpd 4.2.4p0 at 1.1472 Fri Mar 16 10:45:43 UTC 2007 (1)",
>> processor="i686", system="Linux/22.214.171.124-rt9", leap=00, stratum=3,
>> precision=-20, rootdelay=30.293, rootdispersion=50.341, peer=39672,
>> reftime=cb262893.e5d244fd Wed, Jan 2 2008 15:13:23.897, poll=8,
>> clock=cb262c3b.dbe5d3de Wed, Jan 2 2008 15:28:59.858, state=4,
>> offset=0.081, frequency=-6.758, jitter=0.525, noise=0.521,
> Would someone care to venture their best guess as to what caused ntpd
> to step the system clock forward in the above scenario?
This could also be due to a firmware bug in a GPS receiver. There have been
such occasions before (not with Meinberg receivers ;-).
Dave, wouldn't it be a good idea to implement a log message indicating by
which means a leap second announcement has been received? So this could be
traced back to the originally faulty time source.
More information about the questions