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.
>
> .
>
>> 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?
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]