Stupid question: Why was this not caught? Seems pretty easy to test. Just set the clock to today (or any day with a leap second), and watch what happens.
Leap second causing Linux server crashes?
71–80 of 122 posts
Re: Leap second causing Linux server crashes?
#72It appears to be fixed in Linux 3.4 [1]. According to the original commit [2] it's been broken since 7dffa3c673fbcf835cd7be80bb4aec8ad3f51168 [3], which appeared in 2.6.26. So, kernels between 2.6.26 and 3.3 (inclusive) are vulnerable. [1] https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.... [2] https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.... [3] https://git.kernel.org/?p=linux/kernel/git/t…
Re: Leap second causing Linux server crashes?
#73POSTMORTEM fix for CPU eating softirqd threads without rebooting:
stop ntpd, run ntpdate or sntp, start ntpd
/etc/init.d/ntp stop; sntp -s ; /etc/init.d/ntp start
Unfortunately sntp / ntpdate wrapper is not shipped with squeeze for example. I've used the binary from SuSE 11.4 just fine on squeeze.
Re: Leap second causing Linux server crashes?
#74Stupid question: Why was this not caught? Seems pretty easy to test. Just set the clock to today (or any day with a leap second), and watch what happens.
> Just set the clock to today (or any day with a leap second), and watch what happens.
That won't work. The bug is only triggered when an upstream NTP server reports that a leap second was scheduled. Since leap seconds aren't predictable (and aren't even scheduled very far in advance), just setting the time back to the date of a previous leap second won't do anything.
Re: Leap second causing Linux server crashes?
#75Fear the Unix 32-bit time-becomes-negative bugs, in 2037.
We have 25 years to get ready. I still think we'll be patching at the last minute.
(Yeah, lots of systems will be 64-bit by then, but there will still be a lot of embedded crackerbox systems running 32-bit timestamps. It's all the embedded stuff I'm worried about).
Re: Leap second causing Linux server crashes?
#76It appears to be fixed in Linux 3.4 [1]. According to the original commit [2] it's been broken since 7dffa3c673fbcf835cd7be80bb4aec8ad3f51168 [3], which appeared in 2.6.26. So, kernels between 2.6.26 and 3.3 (inclusive) are vulnerable. [1] https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.... [2] https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.... [3] https://git.kernel.org/?p=linux/kernel/git/t…
Which, in summary, is pretty much every production kernel out there. Spent the last two hours recovering servers, tomorrow will be another interesting day. Whoever figured it'd be a good idea to INSERT[1] the leap-second instead of just slowing/accelerating time... [1] Clock: inserting leap second 23:59:60 UTC
Well, except for RHEL 5. That runs 2.6.18.
Re: Leap second causing Linux server crashes?
#772012. and we still have problems keeping track of time. This is both fascinating and scary. P.S. for people wanting to know more this video is simple to understand but really amazing http://www.youtube.com/watch?v=xX96xng7sAE
In this case, i believe we created a problem we did not have. Leap seconds is a dubious construct from the start, problematic with computers or space travel. We have added only 25 since 1972. Their unpredictability means they will be forever a problem with computing. We should either quit the whole idea or in the worst case allow them only every 25 years or so.
Edit: In fact there is strong indication that they may be abolished: http://en.wikipedia.org/wiki/Leap_second#Proposal_to_abolish...
Re: Leap second causing Linux server crashes?
#78It appears to be fixed in Linux 3.4 [1]. According to the original commit [2] it's been broken since 7dffa3c673fbcf835cd7be80bb4aec8ad3f51168 [3], which appeared in 2.6.26. So, kernels between 2.6.26 and 3.3 (inclusive) are vulnerable. [1] https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.... [2] https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.... [3] https://git.kernel.org/?p=linux/kernel/git/t…
[deleted]
Re: Leap second causing Linux server crashes?
#79Fear the Unix 32-bit time-becomes-negative bugs, in 2037. We have 25 years to get ready. I still think we'll be patching at the last minute. (Yeah, lots of systems will be 64-bit by then, but there will still be a lot of embedded crackerbox systems running 32-bit timestamps. It's all the embedded stuff I'm worried about).
It's 2038, not 2037.[1] (Specifically, January 19th, 2038 at 3:14:08am.) And while lots of systems will be 64-bit, many programs still won't be -- and it seems highly likely that this will be a significantly more serious and widespread problem than, say, Y2K or DST. (And certainly more serious than leap seconds, which happen relatively frequently.) Then again, I might be biased: perhaps I'm secretly hoping to spend the years leading up to 2038 paying for my retirement with high-priced consulting gigs to fix it...
Re: Leap second causing Linux server crashes?
#80Stupid question: Why was this not caught? Seems pretty easy to test. Just set the clock to today (or any day with a leap second), and watch what happens.
> Just set the clock to today (or any day with a leap second), and watch what happens. That won't work. The bug is only triggered when an upstream NTP server reports that a leap second was scheduled. Since leap seconds aren't predictable (and aren't even scheduled very far in advance), just setting the time back to the date of a previous leap second won't do anything.
True, but the question still stands, since you can still test it by just telling the kernel to insert a (fake) leap second.