Hi Kriek! If you want just to be notified one time, you must set : notification_interval 0
regards -- Fernando Rocha <fernando.ro...@opservices.com.br> Analista de Suporte - Operação OpServices - Porto Alegre - RS - Brasil +55 51 3275.3588 www.opservices.com.br www.opmon.org ----- "Kriek Jooste" <nag...@speakopen.org> wrote: > I am sure I am missing something simple, and would like some extra > eyes on this. > > The effect I'm seeing is that when a service is in a state I want to > send notifications (e.g. CRITICAL) for, it seems to keep on sending > notifications out, every 20 or 30 minutes or so. For example: > 2009-9-29 13:36:38 SERVICE NOTIFICATION: > kriek-email;kokeyserver;Login > Requests;CRITICAL;notify-by-email;CRITICAL LoginRequests:1065(1000.0) > 2009-9-29 14:06:25 SERVICE NOTIFICATION: > kriek-email;kokeyserver;Login > Requests;CRITICAL;notify-by-email;CRITICAL LoginRequests:1128(1000.0) > 2009-9-29 14:46:33 SERVICE NOTIFICATION: > kriek-email;kokeyserver;Login > Requests;CRITICAL;notify-by-email;CRITICAL LoginRequests:1046(1000.0) > > What I want is for it to notify me only once when it goes from OK to > CRITICAL, until the service is OK again. > > I would have thought this is controlled by notification interval, but > here's the service from the objects cache: > > define service { > host_name kokeyserver > service_description Login Requests > check_period 24x7 > check_command service-is-stale > contact_groups linux-admins > notification_period 24x7 > initial_state o > check_interval 5.000000 > retry_interval 1.000000 > max_check_attempts 3 > is_volatile 0 > parallelize_check 1 > active_checks_enabled 0 > passive_checks_enabled 1 > obsess_over_service 0 > event_handler_enabled 1 > low_flap_threshold 0.000000 > high_flap_threshold 0.000000 > flap_detection_enabled 0 > flap_detection_options o,w,u,c > freshness_threshold 1800 > check_freshness 1 > notification_options u,w,c,r > notifications_enabled 1 > notification_interval 10080.000000 > first_notification_delay 0.000000 > stalking_options n > process_perf_data 1 > failure_prediction_enabled 1 > retain_status_information 1 > retain_nonstatus_information 1 > } > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, > CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9-12, 2009. Register > now! > http://p.sf.net/sfu/devconf > _______________________________________________ > 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 > > __________________________________________________ __________________________________________________ ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ 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