notifications re-enabling themselves?
Marc Powell
mpowell at ena.com
Wed Sep 3 14:43:58 CEST 2003
The type of behavior you are seeing is caused by having multiple nagios processes running at the same time. Its not a bug but more operator error.
--
Marc
Sent from a very tiny wireless device with a very tiny unlit keyboard.
-----Original Message-----
From: jeff vier <jeff.vier at tradingtechnologies.com>
To: nagios-users <nagios-users at lists.sourceforge.net>
Sent: Wed Sep 03 01:13:24 2003
Subject: [Nagios-users] notifications re-enabling themselves?
I'm running nagios 1.1 with a MySQL back-end (and apan, though I don't
think that's a factor) and I am having a seriously bothersome problem
(one that is paging people in the middle of the night!).
I have a few hosts and services that are set as disabled both for checks
and notifications. However, a significant percentage of the time,
nagios "misses" these flags and re-checks and/or re-notifies about the
problem. Obviously, if it's disabled, I want it to ignore the
host/service.
Now, this is not just an extrapolated guess, if you pull up the
extinfo.cgi on a 'suspect' service and hit reload a few times, you can
plainly see it cycling between Service Checks: Enabled and Service
Checks: Disabled (same with Service Notifications).
Is this a known issue? Is it fixed in CVS (which I can't get a full
tree of because of "waiting for jovi's lock in
/cvsroot/nagios/nagios/module")? If so, is there a patch that I can
apply to my 1.1 source tree (in case CVS remains stuck)?
Thanks for any help - this is quite urgent on my side, and I appreciate
any insight (or even guesses, at this point).
--jeff
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20030903/b3e4497e/attachment.html>
More information about the Users
mailing list