weirdness in the scheduling of host checks

[Frater, Greg J]

Greetings All, 

Is anyone else seeing weird things in the scheduling of checks?  I don't
have a good sense of what is wrong but, it's definitely not the way it
was under Nagios 1.0 (or the way it should be).  I've been watching the
scheduling queue on our Nagios 3 box for a week or so, here's a list of
what I've seen:

Under Nagios 3.0.6:
 - host checks staying at the top of the queue for a long time (over an
hour sometimes) even when they have a timeout set at 30 seconds

Under Nagios 3.1.6
 - host check showing up unexpectedly in the scheduling queue, this
morning when I looked at the queue the top event was about 15 minutes
behind the current time but things were moving along okay, when I last
checked there was a host check at the top of the queue with a next check
time from 4 days ago.
 - We had a host go down yesterday (Sunday) but we did not get alerted.
When I looked at it in Nagios I noticed the host check was in an OKAY
state and the 'last check' value for it was from 12 days ago
(6/17/2009)!
 - Host checks don't seem to be getting stuck in the queue like they
were under 3.0.6, at least not for as long

I'm going to submit a ticket to tracker.nagios.org but would like to
have more empirical evidence of the problem first, all I have so far are
symptoms, no good data points (logs, errors, etc.).  Is anyone else
seeing this type of behavior?

Nagios 3.1.2 (also had trouble with 3.0.6)
RHEL 5 64 bit

Regards, 

-greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20090629/21a502a5/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
-------------- next part --------------
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null