Possible bug in Nagios 2.12?

[Andreas Ericsson]

Steven D. Morrey wrote:
> Hi Everyone,
> 
> I've been working on porting a nagios event broker module from 2.7 to
> 2.12. In the process of doing so I've noticed that on my test system
> that service check latency tends to climb, and at the same time,
> completed service checks are trending downwards.
> 

"porting" between minor versions should be as simple as just recompiling
against new headers.

> Since latency was the first clue there might be a problem, I set off
> to find out where latency is calculated and it turns out that latency
> is calculated in the event_execution loop in events.c While in there
> I noticed something interesting or actually I noticed a lack of
> something.
> 
> I'm not seeing anywhere that (event_list_low = event_list_low->next)
> unless the event actually runs.
> 

That's correct, although the loop is broken out of if:
* The check shouldn't be run right now due to global options
* The check shouldn't be run right now due to temporary setting

However, if the check can't be run immediately due to too many checks
running at that moment, or due to the check not being parallelizable
and *any* other check is running, the only sensible thing to do is
to sleep 1 second and then try again. This is what Nagios does.

> To me this looks like a bug. As far as i can tell unless the current
> event_list_low item executes, the next item on the list could never
> execute. Now I am working on a slightly patched version of nagios
> 2.12 so it is possible something went goofy with the patching
> process, but I keep looking over and over at the same lines of code
> and I don't see how it gets past this.
> 
> Would someone mind taking a look at events.c in nagios 2.12 and see
> if I'm correct here?
> 

This would be inside the while(1) loop starting at line 915 with a
closing brace at line 1142 for those who are interested, I guess?

Have a look at the remove_event() function and I'm sure you'll find
your answer.

> 
> NOTICE: This email message is for the sole use of the intended
> recipient(s) and may contain confidential and privileged information.
> Any unauthorized review, use, disclosure or distribution is
> prohibited. If you are not the intended recipient, please contact the
> sender by reply email and destroy all copies of the original message.
> 

http://www.goldmark.org/jeff/stupid-disclaimers/

Read it, please, and make whatever PHB decided on yours read that too.
Or you could sue me for reading and acting on the email even though I
was not (explicitly) in the recipient list.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com