Live data from Hacker News

Leap second causing Linux server crashes?

serverfault.com

21–30 of 122 posts

Re: Leap second causing Linux server crashes?

#21

2012. 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 simultaneously have (1) system time representing the number of seconds since the epoch, and (2) system time equal to (86400 * number_of_days_since_epoch) + seconds_elapsed_today, and all the proposed methods of dealing with the problem involve preserving (2), which seems worthless to me, and throwing away (1), which I would have thought was a better model.

edit: actual system times may be in units other than seconds, but the point remains

Re: Leap second causing Linux server crashes?

#22
post #19

Earlier quoted context omitted.

Mac OS X is a BSD variant, so there's every chance.

How does that follow? OS X runs an odd hybrid kernel (XNU) which is Mach and parts of BSD, but... this is a Linux kernel bug. There's an effectively zero chance of this impacting anything but Linux.

The kernel is not the only OS component relying on time that may have not considered this.

Re: Leap second causing Linux server crashes?

#27
post #19

Earlier quoted context omitted.

How does that follow? OS X runs an odd hybrid kernel (XNU) which is Mach and parts of BSD, but... this is a Linux kernel bug. There's an effectively zero chance of this impacting anything but Linux.

The kernel is not the only OS component relying on time that may have not considered this.

This is evidently a kernel bug. The fact that both operating systems rely on time isn't particularly relevant. Could there be time bugs in OS X? Certainly. But it wouldn't be this one. Windows relies on time too, so I don't see why you bring up the fact that OS X is a BSD variant.

Re: Leap second causing Linux server crashes?

#28
post #6

That wouldn't happen if servers were Macs

Mac OS X is a BSD variant, so there's every chance.

BSD doesn't have an adjtimex syscall, so it's very unlikely for there to be a spinlock bug in the adjtimex syscall that doesn't exist.

Re: Leap second causing Linux server crashes?

#29

2012. 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…

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 relish the idea of requiring similar tables just to keep system time accurate.

Re: Leap second causing Linux server crashes?

#30
Google 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...

Post reply on HN