Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Critical Linux bug that leads 100% CPU (leap second)

blog.wpkg.org

Post reply on HN
Print view View original

31–40 of 45 posts

Re: Critical Linux bug that leads 100% CPU (leap second)

#33

Post by mikeash »

MichaelGG wrote: post #25
wmf wrote: post #20

Earlier quoted context omitted.

Leap seconds aren't needed at all. I'd rather let them accumulate until there's a leap hour that can be rolled into DST (although DST may not exist that far in the future).

DST doesn't exist in UTC, so that's irrelevant. A one-hour UTC shift would totally, utterly, screw stuff up. But, at the current rate, a one-hour "leap" would happen in thousands of years, so maybe it's not such a bad idea after all. But I think the reason for leap seconds has to do with keeping UTC in sync with other clock systems, and that probably overrides any inconvenience to software.

A one-second UTC shift seems to be pretty good at totally screwing stuff up already. At least a one-hour shift would happen once every few centuries instead of once every few years.

Re: Critical Linux bug that leads 100% CPU (leap second)

#35

Post by ajays »

pilif wrote: post #4

I would love to see what's really causing this bug. We read so many times over the weekend to either reboot or just run that date command - but nobody is telling us what's causing the problem. Also, seeing that other threaded applications had similar problems, I doubt this is a java issue - more likely a pthread, glibc or even kernel issue

This seems like the best explanation I've found so far: https://lkml.org/lkml/2012/7/1/203

Re: Critical Linux bug that leads 100% CPU (leap second)

#36

Post by michaelt »

wmf wrote: post #20
streptomycin wrote: post #14

Earlier quoted context omitted.

If you come up with a way of predicting when leap seconds will be needed (hint: it's not a constant regular time interval), let us all know. Until then, there will need to be adjustments.

Leap seconds aren't needed at all. I'd rather let them accumulate until there's a leap hour that can be rolled into DST (although DST may not exist that far in the future).

You don't think the leap-hour will be a new millennium bug?

When you look at how much people crap their pants over the leap second - a relatively common thing - I dread to think how unprepared people would be for something 3,600 times less common.

Re: Critical Linux bug that leads 100% CPU (leap second)

#37

Post by wmf »

michaelt wrote: post #36
wmf wrote: post #20

Earlier quoted context omitted.

Leap seconds aren't needed at all. I'd rather let them accumulate until there's a leap hour that can be rolled into DST (although DST may not exist that far in the future).

You don't think the leap-hour will be a new millennium bug? When you look at how much people crap their pants over the leap second - a relatively common thing - I dread to think how unprepared people would be for something 3,600 times less common.

Yes, it would be similar to Y2K. Hopefully politicians could agree decades in advance so people would have plenty of time to prepare. Also, since you're only changing the tzdata and not UTC, much less would break and most of the breakage would be purely cosmetic. Right now we have several tzdata changes per year and they cause much less disruption than leap seconds.

Re: Critical Linux bug that leads 100% CPU (leap second)

#39

Post by agwa »

gaius wrote: post #8
pilif wrote: post #4

I would love to see what's really causing this bug. We read so many times over the weekend to either reboot or just run that date command - but nobody is telling us what's causing the problem. Also, seeing that other threaded applications had similar problems, I doubt this is a java issue - more likely a pthread, glibc or even kernel issue

There is a good explanation here: http://serverfault.com/q/403732/58037

That's predominantly about the kernel crash, not the high-CPU futex issue. One of the most maddening things about this is that there have been several different issues related to leap seconds on Linux, making it all the harder to get information.

Re: Critical Linux bug that leads 100% CPU (leap second)

#40

Post by wmf »

phaker wrote: post #29
wmf wrote: post #20

Earlier quoted context omitted.

Leap seconds aren't needed at all. I'd rather let them accumulate until there's a leap hour that can be rolled into DST (although DST may not exist that far in the future).

If you want something that looks like UTC minus the leap second trouble, then there is TAI. Right now TAI and UTC differ by about 30 seconds.

I can't switch to TAI because then I'd be 30 seconds off from everybody else. And everybody can't switch to TAI because that disruption would be even larger than what we saw this weekend. IMO the solution is to leave the leap seconds that were already added but not add any more.
Post reply on HN