Arghh - looks like this is a bug, as notifications should get reset
when a state change occurs. I'll post bug fixes to the 1.x and 2.0
(HEAD) branches shortly. Thanks for the note.
On 4 Dec 2003 at 19:00, atonns@mail.ivillage.com wrote:
>
> I sent in this post almost a month ago. I'm wondering if anyone
> thinks it's a feature worth implementing. I'm not running the latest
> HEAD (I'm at v1.1 right now) but I'd be willing to setup a test
> instance with the HEAD, make the alterations, etc. - if it's going to
> be merged into the codebase. It's pretty hard-core when it comes to
> the nitty gritty of the notifications logic. It's taken me some time
> just to figure out. -- "Computer science is as much about computers as
>
> astronomy is about telescopes" -- Edsger Dijkstra
> ---------------------------------------------------------
> Anthony Tonns, UNIX Administrator - atonns@mail.ivillage.com
>
> > -----Original Message-----
> > From: atonns@mail.ivillage.com [mailto:atonns@mail.ivillage.com]
> > Sent: Monday, November 10, 2003 6:56 PM To:
> > nagios-devel@lists.sourceforge.net Subject: [Nagios-devel] Different
> > paging for different levels
> >
> >
> > Below is a post that I made to the nagios-users list over a
> > week ago. I
> > thought about it, and figured that nagios-devel would be the
> > better place
> > for it.
> >
> > Summary: I'm thinking of some global config variable named
> > "force_hard_state_change_notification". It would be a
> > supplement for people
> > that have "notification_interval=0" to suppress periodic
> > notifications when
> > the hard state is the same not-OK state until recovery, but
> > DO want to know
> > about other hard state changes while not-OK (ie: a transition
> > from WARNING
> > to CRITICAL).
> >
> > --- post follows ---
> >
> > Whoops. Looks like my assessment was not 100% accurate.
> >
> > When a service goes from WARNING to CRITICAL it _is_ a hard
> > state change.
> > The problem is that I have notification_interval=0 - which
> > means since it's
> > already sent single notification for a non-OK state (the
> > WARNING) it will
> > not send another notification for ANY OTHER non-OK state (the
> > CRITICAL).
> >
> > What might be the "feature addition" that would make this
> > work for me would
> > be some option to enable some additional logic so that even if the
> > notification_interval=0, Nagios should ignore the time interval and
> > attempt to send a immediate notification (assuming all the other
> > checks
> like
> > downtime, flapping, etc. pass) whenever there's hard state change.
> >
> > I'd like to work on adding this feature (I've spent a lot of
> > time reading
> > the source at this point) but I don't want to add logic where
> > it doesn't
> > belong. There's a lot of checks going on with
> > "check_service_notification_viability" in notifications.c, but
> there's
> > nothing about how to determine a hard state change. That's
> > done in checks.c
> > as part of "reap_service_checks". The "semi-psuedo code" for
> > my suggested
> > change to "check_service_notification_viability" would be:
> >
> > /* dont notify contacts about this service problem again if
> > the notification
> > interval is set to 0
> > * unless forcing notification due to a hard state change */
> > if(svc->current_state!=STATE_OK && svc-
> >no_more_notifications==TRUE){
> > if(force_hard_state_change_notification == FALSE ||
> > (svc->current_state!=svc->last_state &&
> > svc->current_attempt>=svc->max_attempts)) {
> > #ifdef DEBUG4
> > printf("\tWe shouldn't re-notify contacts
> > about this service
> > problem!\n");
> > #endif
> > return ERROR;
> > }
> > #ifdef DEBUG4
> > else {
> > printf("\tNotifications about hard state changes
> were
> > forced!\n"0;
> > }
> > #endif
> > }
> >
> > --
> > "Computer science is as much about computers as
> > astronomy is about telescopes" -- Edsger Dijkstra
> > ---------------------------------------------------------
> > Anthony Tonns, UNIX Administrator - atonns@mail.ivillage.com
> >
> >
> > > -----Original Message-----
> > > From: atonns@mail.ivillage.
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: nagios@nagios.org