Nagios 3.1.1 eats cpu like mad

[Hiren Patel]

Alessandro Ren wrote:
> 
> On 6/23/2009 2:52 PM, Ethan Galstad wrote:
>> Patch is in CVS now.  Can someone who was experience scheduling problems
>> with the 3.0.6 release test the latest 3.1.2 release?  If the problem
>> still persists, its likely in one of the following functions in
>> base/utils.c:
>>
>> check_time_against_period()
>> get_next_valid_time()
>>    
> 
>      This solved the 2010 random schedule of  services bug, now this 
> will happen again. Off course, the 100% CPU is not a trace off to solve 
> the bug.
> 
>      [s].
> 
>> These functions are more complicated now with the new timeperiod
>> exceptions and date formats, so a bug could likely exist here.
>>
>> - Ethan Galstad
>>
>>
>> Andreas Ericsson wrote:
>>    
>>> There's a bug in Nagios 3.1.1, making it eat all available CPU even
>>> with a very small configuration (5 hosts, 12 service checks).
>>>
>>> I sort of introduced it, as I didn't fully test the impact of a patch
>>> sent in before accepting it. Mea culpa, so I'll make sure to fix it.
>>>
>>> For some reason, the patch shown inline below makes Nagios consume
>>> 100% CPU on my system. I don't know the reason for this, but I'll
>>> investigate it and see how it can be fixed. I *think* it happens

should we not have a predictable release cycle, apologies if there is 
one and I'm not aware. A release cycle and freeze period before releases 
could help us catch issues like this before releases in future. I'd be 
glad to spec out a small test scenario that should/would be carried out 
during the freeze periods before releases?
we could mandate that this test must work satisfactory before a release 
is regarded ready?


------------------------------------------------------------------------------