Hi,
I found something that’s looks like a bug.
All this starts with the upgrade from nagios 3.0.5 to 3.0.6. it has some security bug fixes so the was a nessesery upgrade.
After the successful upgrade i always preform a test to see if the alerting is still working.
I don`t know no other way than to change a not existing IP address of a switch in the config file (Of course is not realy an inportant switch)
After a wile it detecting that the switch is not available anymore. It takes 10 min. And than its start to alerting.
For alerting i use sms_client. The following log in nagios shows up:
Feb 09 13:43:59 [19656] : Dialing SMSC 06xxxxxxxx…
Feb 09 13:44:04 [19656] WARNING: read() Timeout
Feb 09 13:44:26 [19656] : Connection Established.
That it. no more than this. It does not hangup the line. Nothing happens. I need to reset the modem to get it working again.
When i send a messages via the the Linux command line, like this: it all works fine.
sms_client kpn:06xxxxxxxx "test"
And the log of sms_client:
Feb 10 10:50:23 [10353] : [000] kpn:06xxxxxxxx "test"
Feb 10 10:50:23 [10353] : Dialing SMSC 0653xxxxxx…
Feb 10 10:50:28 [10353] WARNING: read() Timeout
Feb 10 10:50:51 [10353] : Connection Established.
Feb 10 10:50:57 [10353] : Hangup…
Feb 10 10:51:00 [10353] : kpn Service Time: 37 Seconds
I tested all kinds of thing like changing the config file (COMMANDS.CFG)
Nothing works.
Than i decided to rollback the version from 3.0.6 to 3.0.5 again.
My problem was solved. This is the log:
Hmm… so there is no solution yet…
Could we add this under the atention of the maker of nagios?
I gues this is a serious error. This means that i cannot upgrade to the new version 3.0.6 or 3.1.0
You could try the reporting the issue to the Dev mailing list…
[quote]
nagios-devel ([email protected])
This is a list for people with an interest in working on Nagios addons, event handlers, etc. It is also a place where you can report problems with the “core” code and suggest ideas for future enhancements. [/quote]
Also, the 3.1.x release train is, by all accounts “the first development/testing branch of the Nagios 3.x code” and “ODD minor versions of Nagios releases (e.g. 3.1.x, 3.3,x) will be considered experimental/testing” ( Nagios 3.1.0 Available ) so fingers crossed for v3.2.0
I agree, it certainly should be reported - if we can figure out what the problem is. I don’t see much point in just submitting a “hey, this doesn’t work” report - especially since, based on my research so far, it appears that such reports are greeted with a “fix your sendmail”[1] response. I would really like to be able to point to a specific case where fail can be reproduced consistently … but I don’t have enough data about what is going wrong. I was hoping to find some more information by posting here and getting others to come forward.
I have deployed/managed several Nagios installs in the last couple of years, and the (ubuntu) exim4 and (fedora8) postfix installations work great - but they weren’t deployed on an already-working, correctly configured (fedora10) sendmail host with multiple relays. However, since Nagios is the only thing not delivering mail, I have to presume the external command pipe is to blame. I have MILTER output that seems to confirm this in detail, if anyone is interested, and I will probably go ahead and post it to the dev team next week if I cannot find any more details.
Is there a good way to monitor the actual i/o of the command pipe? Like tee it to another file to see what is actually being written?
Thoughts?
–
immaginos
[1] which is, on the face of it, a valid response. Unfortunately, it seems to have become knee-jerk.
