warning using check_dns

[Marc Powell]

> -----Original Message-----
> From: nagios-users-admin at lists.sourceforge.net [mailto:nagios-users-
> admin at lists.sourceforge.net] On Behalf Of FM
> Sent: Friday, September 09, 2005 12:53 PM
> To: Mailing List Nagios
> Subject: [Nagios-users] warning using check_dns
> 
> Hello,
> 
> Nagios 2.x
> 
> I'm trying to use check_dns :
> [trieste plugins]# ./check_dns -H urbino.lan.lexum.pri -s
> dns1.lan.lexum.pri
> DNS OK: 0.239 seconds response time urbino.lan.lexum.pri returns
> 192.168.4.10|time=0.238538s;;;0.000000
> 
> [trieste plugins]# ./check_dns -H urbino.lan.lexum.pri -s
> dns1.lan.lexum.pri
> DNS WARNING - nslookup returned error status
> 
> As you can see it worked at the first attempt but not at the second.

check_dns is a fancy wrapper for nslookup. When it was called, nslookup
returned an error and/or no output. Do you know why that might be? Can
you successfully run '/path/to/nslookup -sil urbino.lan.lexum.pri
dns1.lan.lexum.pri' multiple times? If it complains about the -sil,
simply remove those flags and try again.

If you're running a recent version of the plugins you can pass a -v flag
to check_dns for verbose output.

Finally, you should always do tests of this nature as the nagios user.
While not an issue in the specific case, plugin execution problems can
often be related to permissions for the nagios user that wouldn't be
apparent when testing as root.

--
Marc 


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Nagios-users mailing list
Nagios-users at 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