Odd, I didn't see anything amiss

Story: Leap second: Linux can freezeTotal Replies: 10
Author Content

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

Jul 03, 2012
9:35 PM EDT
Modern kernels have fixed this. It's mainly old kernels that have a problem.

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


Jul 03, 2012
11:17 PM EDT
We must not have had any apps using futexes -

Jul 04, 2012
12:35 AM EDT
I think you had to be running ntp.

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.

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.

Jul 04, 2012
5:34 PM EDT
Hmmm, does that also explain why XFterm causes X to increase CPU load? No futexes involved, AFAIK.

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

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.

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!