first_notification_delay problem

[Yueh-Hung Liu]

no bug in your case.
"first_notification_delay" is just to postpone the notification for a
(hard)status change, Nagios won't check the status during the delay
period.
in your example, a notification will be sent at 09-02-2011 07:17:41 to
reflect the critical event at 09-02-2011 07:07:41, no matter what
happened then.


On Fri, Feb 11, 2011 at 1:24 AM, Jim Avery <jim at jimavery.me.uk> wrote:
> Hi,
>
> I'm having a problem with using first_notification_delay.  I'm not
> sure if it's a bug or just that I don't understand how it's supposed
> to work.
>
> I have this passive service check to receive traps from a UPS:
>
> define service {
>        host_name       ups-a
>        service_description     SNMP-Trap
>        check_period    24x7
>        check_command   check_nothing
>        contact_groups  notify-Facilities_HQ
>        notification_period     24x7
>        initial_state   o
>        check_interval  60.000000
>        retry_interval  2.000000
>        max_check_attempts      1
>        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     0
>        check_freshness 0
>        notification_options    w,c,r
>        notifications_enabled   1
>        notification_interval   720.000000
>        first_notification_delay        10.000000
>        stalking_options        w,c
>        process_perf_data       0
>        failure_prediction_enabled      1
>        notes   If you need to reset status of this check back to OK,
> submit a passive service check.
>        retain_status_information       1
>        retain_nonstatus_information    1
>        }
>
> I want Nagios only to send a notification if the service is in a
> non-ok state for more than ten minutes.  In practice I find it sends a
> notification regardless:
>
> ups-a   SNMP-Trap       CRITICAL        09-02-2011 07:07:41     notify-Facilities_HQ
>        notify-service-by-email         upsOnBattery UPS: Switched to battery backup
> power.
> ups-a   SNMP-Trap       OK      09-02-2011 07:07:41     notify-Facilities_HQ
>        notify-service-by-email         powerRestored UPS: Returned from battery
> backup power.
>
>
> Is this a bug?  I tried looking in Nagios tracker (
> http://tracker.nagios.org ) but couldn't find anything (then again I
> rarely look there so might have done the search wrong).  Is Nagios
> Tracker the right place to look for issues like this?
>
> Cheers,
>
> Jim
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> 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
>

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
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