No need to panic; this event happend a few days ago, August 1. And no one's certain, but it seems just as likely this is a bug in NTP as it is a deliberate attempt to crash unpatched Linux servers. The way ntpd manages the leap second flag is pretty complex and error prone.
There are over 10 stratum one's that advertise LI=1 as of Wed Aug 1 14:18:51 UTC 2012. Unless this changes another false leap second could occur on August 31, 2012
So yes this was happening on July 31st but may happen as well on August 31.
The fix needs backporting large patchset, yet the next leap second isn't announced. So no need to rush... just wait for a while and do QA. Typical mentality.
DateTime code bugs happen all the time, there are so much things to consider and it's hard to test, because the problem conditions might not occur for years to come. Remember this? http://news.cnet.com/new-years-hangover-for-zune-users/ (also I too am guilty of producing a similar bug in a software a few years ago)
An idea: Setup a fake NTP server that inserts leap seconds randomly (for example, once a week) (forward and backward). It could be use with test servers to test if they are working correctly, before a real leap second crash the production server.
13 comments
[ 3.3 ms ] story [ 38.1 ms ] threadLink to thread view of NTP list discussion: http://lists.ntp.org/pipermail/questions/2012-August/thread....
There are over 10 stratum one's that advertise LI=1 as of Wed Aug 1 14:18:51 UTC 2012. Unless this changes another false leap second could occur on August 31, 2012
So yes this was happening on July 31st but may happen as well on August 31.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679882