[Nagiosplug-help] Check_dig returning warning state incorrectly

[Hans Engelen]

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.
>
>  Ton
>
 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
> 2.6.9-17.ELsmp
 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.
 Cheers,
Hans
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-plugins.org/archive/help/attachments/20050926/61e526ab/attachment.html>