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

Martin Burnicki martin.burnicki at meinberg.de
Wed Aug 1 19:51:01 UTC 2012

Hi all,

Marco Marongiu wrote:
> Hi all
> This is just to warn you that there are now some NTP servers around the
> globe spreading a leap second announcement for tomorrow 00:00:00 UTC
> (so, basically, in a few hours now).
> If you didn't take action before the leapocalypse last month, you better
> hurry now.

Right after the real leap second we had some reports from customers who had
observed that the internal leap bits on their NTP servers had not been
cleared after the leap second had occurred.

It turned out this happened with some older versions of ntpd when the
customers had installed e.g. 3 or 4 servers for redundancy, and each NTP
server had the other ones configured as upstream server (personally I know
this is not a good configuration, but they did it anyway). This
configuration seemed to result in a kind of feedback loop for the leap

I'm assuming e.g. an NTP server didn't clear the internal leap status
immediately after the leap second, and when another server polled this one
it still received the leap warning from its upstream server and thus kept
it. The next one received the leap warning from the other two servers, and
so on.

This state was persistant for several days after the leap date, and of
course even if ntpd was restarted on only one server it immediatedly
received the leap warning from the other servers again.

The only fix we found was to kill ntpd on *all* involved servers first, so
no ntpd service was available anymore, and then restart the daemons on all
servers one after the other. This caused just a short interruption of the
NTP service for other clients in their networks, but obviously broke up the
leap warning feedback loop.

I didn't expect such behaviour since usually the stratum should have been
used to avoid timing loops, which I would expect to include leap warning
loops, and especially I wouldn't expect that current versions of ntpd
(4.2.6 and newer) could behave this way since they need a majority of
upstream servers providing a leap warning to accept this warning. Hmm, on
the other hand, if all servers have the leap bits set then there *is* a
majority ...

Anyway, in my opinion it sounds plausible that NTP servers which have hit
such a state will cause the insertion of another leap seconds at the end of
every month, unless the feedback loop is interrupted, especially if this
should happen with NTP versions where the plausibility check for a leap
second only checks for the end of a month (like in current versions) and
not for the end of June or December (like in earlier versions of ntpd).

Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont

More information about the questions mailing list