I'm troubleshooting an issue where one server is occasionally not responding (I
think it's a firewall or snmpd issue, not this plugin), and I noticed that
changing the timeout option to check_openmanage did not affect how long it took
before receiving the
SNMP CRITICAL: No response from remote host A.B.C.D
message. Looking at the code I see the timeout option is _not_ passed to the
Net::SNMP session object, so the SNMP connection timeout uses the default value
(5 seconds according to the Net::SNMP man page, but 10 seconds in my testing).
If I pass the timeout option to the Net::SNMP->session object like so:
====
diff --git a/check_openmanage b/check_openmanage
index b6abec5..3558ed4 100755
--- a/check_openmanage
+++ b/check_openmanage
@@ -860,6 +860,7 @@ sub snmp_initialize {
'-port' => $opt{port},
'-hostname' => $opt{hostname},
'-version' => $opt{protocol},
+ '-timeout' => $opt{timeout},
);
# Setting the domain (IP version and transport protocol)
====
Then it does obey the timeout option and I instead get the
PLUGIN TIMEOUT: check_openmanage timed out after 30 seconds
message. This might be by design though, to have a shorter SNMP timeout and
different error messages, but it was perplexing to me why the timeout option
was seemingly not working. Perhaps a different option for the SNMP timeout, or
a documentation clarification, is a better way?
Thanks,
Andrew Daugherity
Systems Analyst
Division of Research, Texas A&M University
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
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
