[Nagiosplug-help] Check_dig returning warning state incorrectly
engelenh at gmail.com
Mon Sep 26 02:35:03 CEST 2005
On 9/26/05, Ton Voon <ton.voon at altinity.com> wrote:
> On 26 Sep 2005, at 09:44, Hans Engelen wrote:
> On 9/26/05, Ton Voon <ton.voon at altinity.com> wrote:
> > Did you compile the entire 1.4.2 release? There has been a fix for
> > Redhat since there is a problem in the kernel for the dig and the nslookup
> > command when using popen. Our fix in 1.4.2 release also changed the
> > configure script to pick up this scenario., but if you just took the
> > check_dig.c file and compiled against the 1.4.1 release, this would not
> > pick up the fix.
> Yes, I did, I happend to see a message in one of the mailing lists while
> investigating that 1.4.2 was to fix this so I downloaded and compiled it.
> The whole set that is. Sascha is right though the box is running 2.6.9-11so I will be looking into his suggestions. I see there is a new kernel on
> the RH network, maybe that helps already. Either way I have a few directions
> to look in now with yours and Sascha's feedback. Thanks.
> While I acknowledge this problem was introduced by Red Hat, I thought our
> latest code provided a suitable fix. If this is not working for you, then
> that suggests we need to do something else to our code or at least provide
> enough information about workarounds/solutions.
> I'd be grateful for any more information and recommendations on what we
> can do about this, from a Nagios plugins perspective.
I agree, so I took a look at you configure script and I think the problem
is kind of simple. It seems to me the regexp that triggers the check for the
spopen problem is too restrictive. I am talking about this line :
> if echo $ac_cv_uname_r | egrep "\.EL$" >/dev/null 2>&1 ; then
> echo "$as_me:$LINENO: checking for redhat spopen problem" >&5
This if I am not mistaken will not for the smp kernel where uname -r
returns something like :
> [root at box]# uname -r
A reply that does not trigger your IF I think resulting in the spopen
workaround never getting tested or even activated.
Mind you this is just a quick deduction I made. Forgive me if it is wrong
or I am jumping to conclusions.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Help