* Ivan Fetch <[EMAIL PROTECTED]> [2007-10-05 09:43]: > On Fri, 5 Oct 2007, Holger Weiss wrote: > > You do get that logic, you can specify max_check_attempts just as for > > active checks. You just don't get a retry_check_interval different from > > the normal_check_interval unless you implement it yourself. For us, > > that's not a problem, as we don't want a different retry_check_interval > > anyway (for most checks, we submit check results once a minute). But if > > you rely on this Nagios feature, that's a real drawback of NSCA, yes. > > Good point. We do use retry_check_interval in some cases, but it's not > strictly necessary. If a "it's fixed" state and notification are > important enough, and desired before the next natural check, an admin > could always run the passive check manually.
Yes. If a service is in a _hard_ non-OK state (so that notifications have been sent out), it'll be re-checked using the normal_check_interval anyway, so _here_ there is no difference between active and passive checks. The retry_check_interval just specifies the check interval for active checks during soft states, that is, the interval for the max_check_attempts number of checks which are done for active checks in a non-OK state before notifications are sent out. This interval cannot be specified for passive checks via Nagios, of course. Holger ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Nagios-users mailing list [email protected] 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
