There was a leap second 23:59:60 on the 31st december of 2008 - right before the new year
started. If you were in the "GMT±0" timezone, you hopefully remembered
that, and didn't start
your fireworks too early. If you were in a different timezone, you didn't have that problem,
because the leap second happened either hour(s) before or past midnight for you.
I'm pretty sure you always wondered, but never dared to ask, how that looks from a
computer point of view. Well, the problem is that neither the NTP nor the unix (epoch)
timestamps know the concept of leap seconds - the same timestamp exists twice,
once for 23:59:60 and once for 0:00:00. In fact, here is what a ntp server with
a refclock in germany saw during this leap second:
| timecode | refclock_time | refclock_status |
|---|
01.01.09; 4; 00:59:59; +01:00; A ; |
cd0685ff.00000000 Wed, Dec 31 2008 23:59:59.000 |
LEAP ADD WARNING; TIME CODE; PPS; POSITION; (LEAP INDICATION; PPS SIGNAL; POSITION) |
01.01.09; 4; 00:59:60; +01:00; L; |
cd068600.00000000 Thu, Jan 1 2009 0:00:00.000 |
LEAP SECOND; TIME CODE; PPS; POSITION; (LEAP INDICATION; PPS SIGNAL; POSITION) |
01.01.09; 4; 01:00:00; +01:00; ; |
cd068600.00000000 Thu, Jan 1 2009 0:00:00.000 |
TIME CODE; PPS; POSITION; (LEAP INDICATION; PPS SIGNAL; POSITION) |
As it is in GMT+1, the leap happens at 1 in the morning instead of midnight. The reference clock
knows there is a leap second coming up from decoding of the GPS signal that it has as input. NTP will
pass this information on to the linux kernel and to its clients, which then hopefully do
the proper thing to handle it. However, in linux they apparently weren't so proper - a race condition
was discovered that would freeze heavily loaded machines, because the code that printed the warning
inserting leap second 23:59:60 UTC could cause a deadlock. This should be
fixed in kernel 2.6.29, and the next leap second comes in 1-3 years, so you have hopefully
upgraded to a kernel that does not have this problem by then.
|