This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C3C0E1.B2AAD2E0
Content-Type: text/plain;
charset="ISO-8859-1"
woo! I manually applied the changes to checks.c, notifications.c and
sehandlers.c to my Nagios 1.1 tarball - and it looks like everything is
working as expected (ie: I got one single notification for a WARNING and one
single notification for a CRITICAL).
Thanks, Ethan.
--
"Computer science is as much about computers as
astronomy is about telescopes" -- Edsger Dijkstra
---------------------------------------------------------
Anthony Tonns, UNIX Administrator - [email protected]
> -----Original Message-----
> From: Ethan Galstad [mailto:[email protected]]
> Sent: Thursday, December 04, 2003 8:55 PM
> To: [email protected]
> Subject: Re: [Nagios-devel] Forcing hard state change notifications
>
>
> 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, [email protected] 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 - [email protected]
> >
> > > -----Original Message-----
> > > From: [email protected] [mailto:[email protected]]
> > > Sent: Monday, November 10, 2003 6:56 PM To:
> > > [email protected] 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_s
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]