host retry_check_interval?

[rader at ginseng.hep.wisc.edu]

What's the interval for host check retrys?

There doesn't seem to be any retry_check_interval option for host
objects.  The doc for scheduling host checks simply reads "nagios
will keep pounding out checks of the host" without mentioning
the interval.

And then there's this potentially omnious note...

 Also of note - when Nagios is check the status of a host,
 it holds off on doing anything else (executing new service
 checks, processing other service check results, etc). This
 can slow things down a bit and cause pending service checks
 to be delayed for a while, but it is necessary to determine
 the status of the host before Nagios can take any further
 action on the service(s) that are having problems.

...does "check the status of a host" mean "check the status of a
host N (max_check_attempts) times"??  ...or does it mean "check
that status of a host once"?  In other words, does nagios balk
determining SOFT DOWNs, or does it balk determining HARD DOWNs?

Here's the context of these questions...  We're monitoring flakey
services and hosts (which we don't administer.)  We have cut down
on excessive WARNING/CRITICAL ("spam") notifications by setting
max_check_attempts to 5 and retry_check_interval to 24 (eg only
notify about WARNING/CRITICAL after two hours.)  How do we do that
for DOWN notifications?

steve 
- - - 
systems & network guy
high energy physics
university of wisconsin



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
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