Ouch! My Debian GNU/Linux 6.0 is still standing Oh well, reading the issue, the machine date is Sat Jun 30 16:11:31 EDT 2012 Stopped ntpd just in case
[deleted]
Leap second causing Linux server crashes?
31–40 of 122 posts
Re: Leap second causing Linux server crashes?
#32Not surprising. In spite of all press that Y2K was just a silly waste of money, its events like these that makes me suspect it would have been a much bigger deal if everyone had ignored it and fixed it after things where shown to break.
A lot of engineers[1] spent a lot of time successfully fixing Y2K bugs.
Because nothing well known blew up, many people wrongly assumed that Y2K was never a real problem to begin with.
[1] I moved a Fortune 100 manufacturing company's database off an ancient mainframe that would've been disastrous come Y2K. It went smoothly and was thus a thankless job. They paid well though (mid six figures - those were the days).
Re: Leap second causing Linux server crashes?
#33My Ubuntu servers seem unaffected thus far.
Unfortunately I can confirm that Ubuntu 10.04 is vulnerable. We're proceeding with the fixtime.pl workaround.
Re: Leap second causing Linux server crashes?
#34Google uses a "leap smear" and slowly accounts for the leap second before it happens.[1] As long as you are not doing any astronomical calculations or constrained by regulatory requirements I think google has the right idea. [1] http://googleblog.blogspot.com/2011/09/time-technology-and-l...
As part of Google Compute Engine we provide an NTP server to the guest which is based on Google Production time. As such our VMs get to take advantage of this leap second smearing implementation. I was going to mention this at my talk at IO but forgot.
Re: Leap second causing Linux server crashes?
#35Earlier quoted context omitted.
From discussion of this same issue in prior threads, my takeaway was (a) it's really not at all difficult to handle leap seconds, but (b) the POSIX standard specifically disallows them, by specifying that a day must contain exactly 86400 seconds. (Analogously, imagine if leap days occurred as normal, but a "year" by definition contained exactly 365 days.) The existence of leap seconds means that it's not possible to…
It's harder than leap days, because leap seconds aren't inserted on a regular schedule. Leap days follow a predictable pattern of insertion. Leap seconds are inserted whenever the IERS decides to insert them. The problem of leap seconds is therefore closer to that of time zone definitions -- which are a total mess, because they depend on keeping rapidly changing system tables up to date. I can see why people don't re…
How are systems being notified of the leap seconds now, that wouldn't immediately enable them to update their hypothetical leap second table?
It seems like we already have a much bigger lead time for notification than we could possibly need.
> I can see why people don't relish the idea of requiring similar tables just to keep system time accurate.
But the 'solution' we're using now is to make system time less accurate, not more accurate. Accurate would be if leap seconds incremented the system clock like normal seconds do. If the accuracy you're worried about is displaying a clock time rather than time since the epoch, you already need a time zone to do that.
Re: Leap second causing Linux server crashes?
#362012. 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
From discussion of this same issue in prior threads, my takeaway was (a) it's really not at all difficult to handle leap seconds, but (b) the POSIX standard specifically disallows them, by specifying that a day must contain exactly 86400 seconds. (Analogously, imagine if leap days occurred as normal, but a "year" by definition contained exactly 365 days.) The existence of leap seconds means that it's not possible to…
Interesting analysis. Preserving (2) means that systems that don't handle leap seconds (or don't have a leap seconds table updated in the last six months) have a POSIX time at most 1 second away from systems that do. Dropping (2) would mean a more complicated formula to convert system times to times of day, but it would also make the failures and missing leap tables immediately noticeable, rather than a one-in-a-few-years event. Which would have made it the better choice; bugs encountered during development are easily handled, bugs that happen years later on production systems are inconvenient.
Re: Leap second causing Linux server crashes?
#37Now facing this issue... By using 'adjtimex' command, you can clear the problematic INS bit.
At first, you can confirm the status flag like this.
$ ./adjtimex --print | grep status
status: 8209
$ ruby -e 'p 8209.to_s(2)'
"10000000010001"
$ ruby -e 'p 8193.to_s(2)'
"10000000000001"
$ adjtimex --status 8193Re: Leap second causing Linux server crashes?
#38Not surprising. In spite of all press that Y2K was just a silly waste of money, its events like these that makes me suspect it would have been a much bigger deal if everyone had ignored it and fixed it after things where shown to break.
Why does everyone always say Y2K wasn't an issue ? I'm sure there were a lot of consultant making too much money with little work - however _alot_ of bug fixes were done, that would have caused problems. So because it was taken seriously , stuff were fixed and issues didn't happen because of that.
Personally, I fixed 3 Y2K bugs back then, 2 of them would have brought down a rather critical business support to simply crash every time new data arrived.
Re: Leap second causing Linux server crashes?
#39Google uses a "leap smear" and slowly accounts for the leap second before it happens.[1] As long as you are not doing any astronomical calculations or constrained by regulatory requirements I think google has the right idea. [1] http://googleblog.blogspot.com/2011/09/time-technology-and-l...
As part of Google Compute Engine we provide an NTP server to the guest which is based on Google Production time. As such our VMs get to take advantage of this leap second smearing implementation. I was going to mention this at my talk at IO but forgot.
Marco's blog post (linked) had a similar idea - running ntp with -x for a day so it smears time.
Re: Leap second causing Linux server crashes?
#40Hey, I'm running Ubuntu 12.04 . Could someone guide me through what I can do to detect/prevent this from crippling my server? Thanks.