[ntp:questions] WARNING: someone's faking a leap second tonight
martin.burnicki at meinberg.de
Thu Aug 2 14:20:03 UTC 2012
Jeffrey Lerman wrote:
> How are the leap-second flags meant to be cleared after a leap second?
> Is it supposed to be automatic? Is there a bug in some code (ntpd or
> elsewhere) that is failing to clear the flag in (some versions of) ntp
> server software?
I've just run some tests. On a test machine:
- configured ntpd to use the current leap second file
- configured the local clock as only ref time source
- set the system date/time to 2012-06-30 23:59:45 UTC
- started ntpd
On a different machine:
- ran a test program which sends 4 requests/s to the test machine
and prints the contents of the reply packets, including leap status
Found that with both the current stable version (4.2.6p5) and a current
dev version (4.2.7p290) the leap second warning in the reply packets
already disappeared shortly *before* the leap second actually occurred.
This means if this server sends a reply to a client shortly before the
leap second the leap warning may have already been turned off, and thus
the client might *disarm* the leap second shortly before the leap second
occurs. This sounds like a bug to me, so I'm going to file a bug report
Anyway, this does *not* seem to be directly related to the actual
problem where the leap bit is not reset at all, or is set again if
there's a time source which still has the bit set immediately after the
For completeness I've repeated the same test with the latest version of
the 4.2.4 branch, namely 4.2.4p8. This version of ntpd resets the leap
warning bit in the leap status sent to clients a few seconds *after* the
leap second, so this could be a possible issue for clients accepting a
new leap warning immediately after a leap second has occurred.
> I did check earlier this morning and I was unable to
> find a bug filed against ntpd regarding this issue - does anyone know if
> we should go ahead and file a bug? It'd be nice to have more
> information on whether this is really an ntpd issue.
I'm sure a bug will be filed, but eventually we should first find out
more details so we can write an appropriate summary of the issue.
More information about the questions