Leap second: Linux can freeze

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

Modern kernels have fixed this. It's mainly old kernels that have a problem.

> 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

We must not have had any apps using futexes -

I think you had to be running ntp.

Yes, all our linux servers run ntp, and so do my desktops - I consider that a pretty basic linux housekeeping task.

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.

Hmmm, does that also explain why XFterm causes X to increase CPU load? No futexes involved, AFAIK.

Wouldn't the usual cron/anachron job for syncing with time servers fix something like this? After all, that typically re-sets the time...

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.

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.