[ntp:questions] WARNING: someone's faking a leap second tonight

Martin Burnicki 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 
for this.

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 
leap second.

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.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany




More information about the questions mailing list