> [EMAIL PROTECTED] stucky]# /usr/local/nagios/libexec/check_dig -w 1 -c 2 -H > {nameserver} -l {fqdn} -a {ip} > DNS WARNING - 0.011 seconds response time ({fqdn} 38400 IN A {ip})|time=0. > 011227s;1.000000;2.000000;0.000000 > > Have I totally gone nuts or did I not just tell check_dig to only warn me > if the query takes more than one second ? As you can see the tool itself > reports it took only 0.011 seconds so why the warning ? > It's annoying cause I get those random fake alerts and another recovery > messager soon after. > Thing is even if I totally leave the -w and -c flags out it'll still do > that as if it had a hardcoded value between 0.008 and 0.011 in there that > can't be changed.
This is a redhat issue, there's something they screwed up in the futex handling of their kernel. Do a manual up2date -uf to force the update of kernel packages, which are usually excluded by up2date. Reboot - be happy. This has been fixed with hotfix-kernel-2.6.9-22 (not publicly available) and later on with the last major update 3 (nahant). regards Sascha -- Sascha Runschke Netzwerk Administration IT-Services ABIT AG Robert-Bosch-Str. 1 40668 Meerbusch Tel.:+49 (0) 2150.9153.226 Mobil:+49 (0) 173.5419665 mailto:[EMAIL PROTECTED] http://www.abit.net http://www.abit-epos.net --------------------------------- Sicherheitshinweis zur E-Mail Kommunikation / Security note regarding email communication: http://www.abit.net/sicherheitshinweis.html ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null