Hi guys,

This is the best summary of the leap second problem I have seen thus
far and figured it could not hurt to share:

http://serverfault.com/questions/403732/anyone-else-experiencing-high-rates-of-linux-server-crashes-during-a-leap-second

Thanks
Petter

On Mon, Jul 2, 2012 at 10:50 PM, Peter van Hooft
<[log in to unmask]> wrote:
> On Mon, Jul 02, 2012 at 08:42:28PM +0100, Jon Peatfield wrote:
>> On Sun, 1 Jul 2012, Peter van Hooft wrote:
>>
>> >Hi,
>> >
>> >On 6.2 (2.6.32-220.23.1.el6.x86_64) I noticed that qpidd started to use an
>> >enormous amount of cpu time. It is probably related to the last leap second.
>> >Doing an strace I saw it doing futex() calls in a furious rate.
>> >After doing the
>> >export LANG=C
>> >date; date `date +"%m%d%H%M%C%y.%S"`; date
>> >trick and restarting qpidd, the problem was gone.
>>
>> Caused by a kernel bug in > 2.6.26 (apparently) < 3.4.something.  See:
>>
>>   http://serverfault.com/questions/403732/anyone-else-experiencing-high-rates-of-linux-server-crashes-during-a-leap-second
>>
>> which in turn points at:
>>
>>   https://access.redhat.com/knowledge/solutions/154713
>>   https://access.redhat.com/knowledge/articles/15145
>>
>> for the RHEL6 info...  The solutions stuff seems to require a
>> subscription to view in full.
>>
>> Note that there seem to have been two bugs one may have caused a
>> hard crash at any time on the day leading up to the leap-second, and
>> the other causes excessive CPU usage after the leap-second has been
>> applied. Machines with higher loads were more likely to suffer the
>> hard crash.
>>
>> The bug all distros with the bad ranges of kernels, so e.g. el5/sl5
>> seems not to have been affected though el6/sl6 were.
>>
>>  -- Jon
>>
>
> Hi Jon,
>
> Thanks for your mail.
> I just wanted to note this for the benefit of others who ran into problems with qpidd.
> For your information, we've got reports of matlab running slowly (on systems without oopses,
> 'hrtimer: interrupt took xxxxx ns' or 'INFO: task xxxxx blocked for more than yyyy seconds'
> messages) and the re-setting of the system time seems to solve that as well.
> In other words, any application that uses java and/or multithreading may benefit from re-setting
> the system time, even if no evidence of kernel problems are present.
>
> Regards,
>
> Peter



-- 
Petter Olsson
System Administrator
NumberFour AG
Schönhauser Allee 8
10119 Berlin
Germany
Mobile: +49 170 2393359
Phone: +49 30 40505411
Fax: +49 30 40505410
[log in to unmask]

www.facebook.com/NumberFour
www.twitter.com/numberfourag

"People who say it cannot be done should not interrupt those who are doing it."