Suggestion to first_notification_delay

[Matthieu Kermagoret]

On Tue, Sep 6, 2011 at 11:21 PM, Andreas Ericsson <ae at op5.se> wrote:
> It took me quite a while to grok what you're saying, although the code
> speaks clearly enough for itself. To clarify for others who might not
> have the stamina to apply the MUA-mangled patch and read the code for
> themselves, the patch intends to make first_notification_delay depend
> only on the first non-OK hard state change and not reset the timer for
> new hard states that replace the one that initially triggered the
> first_notification_delay.
>

From what I understand from this patch, your explanations are the
expected behavior but not what really happens with the code. Indeed
the patch base the first_notification_delay on the last hard state
change, not the first non-OK hard state change. Both might be the same
but only if the hard state have not changed during the first
notification delay (from critical to warning for example).

Best regards,

-- 
Matthieu KERMAGORET | Développeur

mkermagoret at merethis.com

MERETHIS est éditeur du logiciel Centreon.

------------------------------------------------------------------------------
Doing More with Less: The Next Generation Virtual Desktop 
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops?   How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel