Odd, I didn't see anything amiss
|
| Author | Content |
|---|---|
| herzeleid Jul 03, 2012 8:27 PM EDT |
We've got about 50 linux servers running here and the only indication I had of the leap second affair was a line of dmesg output: Clock: inserting leap second 23:59:60 UTC |
| chalbersma Jul 03, 2012 9:35 PM EDT |
Modern kernels have fixed this. It's mainly old kernels that have a problem. |
| vagabondo Jul 03, 2012 10:42 PM EDT |
> Modern kernels have fixed this. It's mainly old kernels that have a problem. Wrong. You have to read the update/follow up article , http://www.h-online.com/open/news/item/Leap-second-bug-in-Li... and check out esp. the link to the LKML. https://lkml.org/lkml/2012/7/1/27 et seq. This issue appeaers to affect vulnerable syste running kernels >= 2.6.22. A fix has been proposed, and patches should appear before the next leap second is due (1 Jan 2014). There has been some confusion with bugs found and patched following previous leap-seconds. The commercial distros have presumeably been keeping their customers advised; e.g. http://www.novell.com/support/kb/doc.php?id=7010351 |
| herzeleid Jul 03, 2012 11:17 PM EDT |
We must not have had any apps using futexes - |
| Steven_Rosenber Jul 04, 2012 12:35 AM EDT |
I think you had to be running ntp. |
| herzeleid Jul 04, 2012 2:51 PM EDT |
Yes, all our linux servers run ntp, and so do my desktops - I consider that a pretty basic linux housekeeping task. |
| Steven_Rosenber Jul 04, 2012 3:48 PM EDT |
I can't explain it. I suspended my desktop system overnight, resumed it the next day. By the evening, running Chrome or Firefox caused both CPU cores to hit 100%. Quitting and restarting the apps had no effect. I shut down that night. Turned on the next day, all was fine. |
| gus3 Jul 04, 2012 5:34 PM EDT |
Hmmm, does that also explain why XFterm causes X to increase CPU load? No futexes involved, AFAIK. |
| JaseP Jul 05, 2012 9:37 AM EDT |
Wouldn't the usual cron/anachron job for syncing with time servers fix something like this? After all, that typically re-sets the time... |
| mbaehrlxer Jul 14, 2012 9:59 AM EDT |
as i understand it, no, because a leap second means the day has in fact an extra second, so if you need to accurately measure something that crosses a leapsecond boundary, just resetting the time based on the timeserver would give you the wrong results (off by one second). therefore the leapsecond needs to be correctly inserted, and it is that insertion that triggers the bug. of course for the rest of us who don't need that accuracy, just resetting the time would work, and that is also the workaround (if i understood it correctly): undo the insertion of a leapsecond, and let the timeserver fix the time. greetings, eMBee. |
| jacog Jul 14, 2012 10:16 AM EDT |
I had this problem on one of my servers. I have not fixed/updated the kernel, but simply re-syncing the clock seemed to do the trick. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!