[Nagiosplug-help] Check_dig returning warning state incorrectly

[Hans Engelen]

On 9/26/05, Ton Voon <tonvoon at mac.com> wrote:
>
>
>  On 26 Sep 2005, at 11:03, Hans Engelen wrote:
>
>
>
> On 9/26/05, Ton Voon <tonvoon at mac.com> wrote:
> >
> >
> > Good observation. Can you change the configure script so the line is:
> >
> >  egrep "\.EL(smp)?$"
> >
> >  and see whether this works? I'll update CVS when you've confirmed.
> >
> >  Ton
> >
>  I think this is the line I should get from configure then :
>  > checking for redhat spopen problem... error
>
> So far (and I have manually ran a check_dig about 50 times now where
> before I would get a warning once every ten tries) all seems well with the
> plugin too.
>  However, I am wondering if even this regexp is enough. I think there is a
> third kind of kernel used by Red Hat, the hugemem kernel. Personally not one
> I am using over here so not sure what that returns on a uname -r.
>  Either way, seems my check_dig is back on track, thanks.
>
>
> Great!
>
> The logic we used for the configure script was to avoid doing unnecessary
> checks on other OSes, hence the grep of uname -r. If CentOS and Fedora
> display the problem, then we'll either have to expand the grep or run the
> test for every OS (which I would prefer not to do).
>
> Sascha says that this is due to --enable-threads on bind9. Is there
> another way of checking for this problem? grep "libpthread"
> /usr/bin/nslookup && uname -s = "Linux" ? I'm open to suggestions before
> updating the grep for the smp uname -r output.
>
> Ton
>
 I just checked on a rather old version of redhat (FC1) and :
 [root at box]# ldd /usr/bin/nslookup
libdns.so.10 => /usr/lib/libdns.so.10 (0x00101000)
libcrypto.so.4 => /lib/libcrypto.so.4 (0x00318000)
libisc.so.4 => /usr/lib/libisc.so.4 (0x00c9e000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00da1000)
libc.so.6 => /lib/tls/libc.so.6 (0x00b3a000)
libdl.so.2 => /lib/libdl.so.2 (0x00c99000)
libz.so.1 => /usr/lib/libz.so.1 (0x00d7e000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00b22000)

So not sure what good the check for libpthread would improve. Seems it's
been in there for a while. Sascha might have a better check for it. Frankly
I am not even sure what it is that got messed up since 2.6.9-5.
 Cheers,
Hans
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-plugins.org/archive/help/attachments/20050926/59f82a13/attachment.html>