[Nagiosplug-help] Check_dig returning warning state incorrectly
engelenh at gmail.com
Mon Sep 26 04:19:07 CEST 2005
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.
> 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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Help