Fix for host dependency checks
Ethan Galstad
nagios at nagios.org
Tue Mar 21 19:50:18 CET 2006
On 24 Feb 2006 at 19:04, Holger Weiss wrote:
> * Holger Weiss <holger at CIS.FU-Berlin.DE> [2006-01-30 16:54]:
> > There is a timing problem in the host[*] dependency check logic: If
> > host B is configured to be dependent on host A being up and host A
> > goes down, the dependency will only fail if host A "incidentally"
> > was checked _prior_ to host B after going down. Hence, the host
> > dependency logic will sometimes work and sometimes not. I'd
> > therefore suggest to explicitly (re-)check host A during the
> > dependency checking for host B, as the attached patch does.
>
> Okay, this introduces a new problem: If host B is checked immediately
> before and host A (during the dependency check) after a recovery of
> both hosts, the dependency won't fail. Hence, notifications for host
> B won't be suppressed (been there, got the t-shirt).
>
> Next try: The attached patch lets the dependency fail if either the
> current or the previous (hard) state of A matches the failure
> criteria. AFAICS, this should reliably suppress notifications for host
> B if the dependency fails.
>
> Holger
I'll keep this on the TODO list for Nagios 3.x, but I think it might
require some more thought. The last hard state of the host should
only be used in the dependency logic if a state change occurred
relatively recently. If, for example, the last hard state change
occurred two days ago, you don't want that value used in the logic.
Rather than changing the logic tests, it may be wiser to simply delay
the next host notification for a bit. I'll keep this on my TODO
list.
Ethan Galstad,
Nagios Developer
---
Email: nagios at nagios.org
Website: http://www.nagios.org
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
More information about the Developers
mailing list