Using nagios 2.0b3 and have the following host and related service defined:
define host{ use vip.template host_name ProdSystem alias Prod hostgroups Production check_command check-dummy!0!"See Service Detail for Status Information" address 172.16.1.10 } define service{ use vip.template host_name ProdSystem service_description test_client is_volatile 0 check_period Off_Peak max_check_attempts 3 normal_check_interval 1500 retry_check_interval 20 notification_interval 0 check_command test_client!111.111.111.111!9999!35 } test_client is a simple script that tests the connectivity of the custom service that at listening at 172.16.0.50. It is set to timeout and fail at 35 seconds. interval_length is set to 1, therefore normal_check_interval=1500 should be 1500s=25m and retry_check_interval=20 should be 20s. However last night test_client failed and gave initial notification of state CRITICAL at 00:37:21. Manually testing by me immediately after receiving this notification showed that the service was indeed back up therefore I am almost 100% certain that subsequent test_client checks by nagios would have succeeded. However, I did not receive an RECOVERY alert until 01:26:46, which is almost exactly 50 minutes after the initial CRITICAL alert. Also, I have another test for a similar service with identical parameters, and in that case it didn't send a RECOVERY alert until almost exactly 75 minutes after the CRITICAL alert. ------------------------------------------------------- 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 _______________________________________________ Nagios-users mailing list Nagios-users@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