So that explains why the 12 cores on my Fedora workstation were maxed-out when I came to work this morning!
Critical Linux bug that leads 100% CPU (leap second)
11–20 of 45 posts
Re: Critical Linux bug that leads 100% CPU (leap second)
#12[deleted]
I hate tzdata updates with a passion, politicians should just get a grip and stop messing around with timezones. I'm all for ideas that create new jobs but this isn't one of them.
Re: Critical Linux bug that leads 100% CPU (leap second)
#13I 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
The patch that was shared on the lkml shows some insight on what is causing the issue. https://lkml.org/lkml/2012/7/1/27
Apparently the issues might be due "to the leapsecond being added without calling clock_was_set() to notify the hrtimer subsystem of the change", a possible fix being to patch kernel/time/timekeeping.c to be leapsecond aware.
Re: Critical Linux bug that leads 100% CPU (leap second)
#14[deleted]
I hate tzdata updates with a passion, politicians should just get a grip and stop messing around with timezones. I'm all for ideas that create new jobs but this isn't one of them.
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.
Re: Critical Linux bug that leads 100% CPU (leap second)
#15[deleted]
Re: Critical Linux bug that leads 100% CPU (leap second)
#16So if the leap second was handled in userspace instead of the kernel, just like a normal ntp time update, all would have been fine. Why not just do that?
Re: Critical Linux bug that leads 100% CPU (leap second)
#17I saw what is likely a related issue on one of our AWS EC2 instances, where exactly at midnight UTC there was a high percentage of 'steal' CPU time in our server monitoring charts.
I wonder if this was caused by another VM on the same physical box being hit by the bug and as a result stole CPU time from our VM.
I resolved the issue by moving to a different VM (Rebooting didn't help), to get away from my greedy neighbor.
More info here: http://blog.thinrhino.net.in/cpu-steal-time
Re: Critical Linux bug that leads 100% CPU (leap second)
#18On Sunday I noticed that Gerrit (code review, written in Java) was chewing through CPU on one of our servers. Just applied this it appears to have settled down.
Re: Critical Linux bug that leads 100% CPU (leap second)
#19well, our hadoop cluster went bonkers because of this bug....luckily it was on stage...not production!
Re: Critical Linux bug that leads 100% CPU (leap second)
#20Earlier quoted context omitted.
I hate tzdata updates with a passion, politicians should just get a grip and stop messing around with timezones. I'm all for ideas that create new jobs but this isn't one of them.
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).