4 ms·
Why this year's leap second crashed more systems?
According to Wikipedia (http://en.wikipedia.org/wiki/File:Leapsecond.ut1-utc.svg) , this is not the first year leap second is being inserted. Why so many systems crashed now, but not in, say, 2009?
- Piskvorrr 14y ago(And a corollary: why so many systems are so woefully unprepared for such quirks in the calendar system, even though such quirks are well documented and anticipated - albeit not always regular? I mean, even leap years manage to knock down servers, even though they happen regularly, approximately every four years...)
- nicktelford 14y agoI'd surmise that the main reason leap years continue to break systems is that new software is developed within the time between leap years that fail to account for them. Date/time handling is notoriously difficult to get right, and leap years are an edge case that's triggered very rarely, so it's easy for novice developers to fail to handle it.
- Piskvorrr 14y agoIn other words, All Software Sucks. (I mean, shouldn't I already have come to terms with that?)
- nicktelford 14y agoFrom what I've heard the majority of the problems we saw this time around were caused by a deadlock in NTP in a number of Linux kernels (2.6.21 until 3.3 I think, although that might be wrong). [source: http://www.mail-archive.com/git-commits-head@vger.kernel.org/msg15039.html http://www.mail-archive.com/git-commits-head@vger.kernel.org...] I know that CentOS/RHEL 6 was affected, but CentOS/RHEL 5.5 (kernel 2.6.18) was not. So I guess it's just a coincidence, a bug was introduced in a code path that's rarely executed and so lay dormant for some time, gaining more and more victims as time went by and people adopted kernels containing said bug.