From noreply at sourceforge.net Tue Aug 6 10:15:36 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Aug 2013 01:15:36 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614879 ] Incocistencies between plugins versions Message-ID: Bugs item #3614879, was opened at 2013-08-06 01:15 Message generated for change (Tracker Item Submitted) made by simonkainz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614879&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Simon Kainz (simonkainz) Assigned to: Nobody/Anonymous (nobody) Summary: Incocistencies between plugins versions Initial Comment: I took nagios-plugins from github and noticed the following: Using version 1.4.16.89.gbfe6, the processing of waring/critical ranges in check_snmp seems to be broken. OS: Debian Wheezy 64bit Compiler: 6cc I built all 3 versions by myself from source. I uses these 3 versions for a test: $ for i in nagios-plugins-1.4.15 nagios-plugins-1.4.16 nagios-plugins; do $i/plugins/check_snmp -P 2c -c public -H -o .1.3.6.1.2.1.43.18.1.1.7.1.1 -w 800:1200 -c 850:1150 -v -v -v -V ; done check_snmp v1.4.15 (nagios-plugins 1.4.15) check_snmp v1.4.16 (nagios-plugins 1.4.16) check_snmp v1.4.16.89.gbfe6 (nagios-plugins 1.4.16) Running those 3 results in the following: $ for i in nagios-plugins-1.4.15 nagios-plugins-1.4.16 nagios-plugins; do $i/plugins/check_snmp -P 2c -c public -H -o .1.3.6.1.2.1.43.18.1.1.7.1.1 -w 800:1200 -c 850:1150 -v -v -v ; done /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP CRITICAL - *1104* | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 So the last plugin reports CRITIAL, altough the value reported lies perfectly withing the defined warning/critical ranges. Maybe I'm doing something wrong, but still seems like a bug to me. Regards, Simon ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614879&group_id=2988 From noreply at sourceforge.net Tue Aug 6 10:35:40 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Aug 2013 01:35:40 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614879 ] Incocistencies between plugins versions Message-ID: Bugs item #3614879, was opened at 2013-08-06 01:15 Message generated for change (Settings changed) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614879&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Simon Kainz (simonkainz) >Assigned to: Holger Weiss (hweiss) Summary: Incocistencies between plugins versions Initial Comment: I took nagios-plugins from github and noticed the following: Using version 1.4.16.89.gbfe6, the processing of waring/critical ranges in check_snmp seems to be broken. OS: Debian Wheezy 64bit Compiler: 6cc I built all 3 versions by myself from source. I uses these 3 versions for a test: $ for i in nagios-plugins-1.4.15 nagios-plugins-1.4.16 nagios-plugins; do $i/plugins/check_snmp -P 2c -c public -H -o .1.3.6.1.2.1.43.18.1.1.7.1.1 -w 800:1200 -c 850:1150 -v -v -v -V ; done check_snmp v1.4.15 (nagios-plugins 1.4.15) check_snmp v1.4.16 (nagios-plugins 1.4.16) check_snmp v1.4.16.89.gbfe6 (nagios-plugins 1.4.16) Running those 3 results in the following: $ for i in nagios-plugins-1.4.15 nagios-plugins-1.4.16 nagios-plugins; do $i/plugins/check_snmp -P 2c -c public -H -o .1.3.6.1.2.1.43.18.1.1.7.1.1 -w 800:1200 -c 850:1150 -v -v -v ; done /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP CRITICAL - *1104* | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 So the last plugin reports CRITIAL, altough the value reported lies perfectly withing the defined warning/critical ranges. Maybe I'm doing something wrong, but still seems like a bug to me. Regards, Simon ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614879&group_id=29880 From noreply at sourceforge.net Tue Aug 6 10:45:30 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Aug 2013 01:45:30 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614879 ] Incocistencies between plugins versions Message-ID: Bugs item #3614879, was opened at 2013-08-06 01:15 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614879&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None >Priority: 6 Private: No Submitted By: Simon Kainz (simonkainz) Assigned to: Holger Weiss (hweiss) Summary: Incocistencies between plugins versions Initial Comment: I took nagios-plugins from github and noticed the following: Using version 1.4.16.89.gbfe6, the processing of waring/critical ranges in check_snmp seems to be broken. OS: Debian Wheezy 64bit Compiler: 6cc I built all 3 versions by myself from source. I uses these 3 versions for a test: $ for i in nagios-plugins-1.4.15 nagios-plugins-1.4.16 nagios-plugins; do $i/plugins/check_snmp -P 2c -c public -H -o .1.3.6.1.2.1.43.18.1.1.7.1.1 -w 800:1200 -c 850:1150 -v -v -v -V ; done check_snmp v1.4.15 (nagios-plugins 1.4.15) check_snmp v1.4.16 (nagios-plugins 1.4.16) check_snmp v1.4.16.89.gbfe6 (nagios-plugins 1.4.16) Running those 3 results in the following: $ for i in nagios-plugins-1.4.15 nagios-plugins-1.4.16 nagios-plugins; do $i/plugins/check_snmp -P 2c -c public -H -o .1.3.6.1.2.1.43.18.1.1.7.1.1 -w 800:1200 -c 850:1150 -v -v -v ; done /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP CRITICAL - *1104* | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 So the last plugin reports CRITIAL, altough the value reported lies perfectly withing the defined warning/critical ranges. Maybe I'm doing something wrong, but still seems like a bug to me. Regards, Simon ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2013-08-06 01:45 Message: Thanks for your report. Could you check whether you can reproduce the bug after running $ git revert --no-edit bd782990 in your clone of the Git repository? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614879&group_id=29880 From noreply at sourceforge.net Tue Aug 6 11:05:35 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Aug 2013 02:05:35 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614879 ] Incocistencies between plugins versions Message-ID: Bugs item #3614879, was opened at 2013-08-06 01:15 Message generated for change (Comment added) made by simonkainz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614879&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 6 Private: No Submitted By: Simon Kainz (simonkainz) Assigned to: Holger Weiss (hweiss) Summary: Incocistencies between plugins versions Initial Comment: I took nagios-plugins from github and noticed the following: Using version 1.4.16.89.gbfe6, the processing of waring/critical ranges in check_snmp seems to be broken. OS: Debian Wheezy 64bit Compiler: 6cc I built all 3 versions by myself from source. I uses these 3 versions for a test: $ for i in nagios-plugins-1.4.15 nagios-plugins-1.4.16 nagios-plugins; do $i/plugins/check_snmp -P 2c -c public -H -o .1.3.6.1.2.1.43.18.1.1.7.1.1 -w 800:1200 -c 850:1150 -v -v -v -V ; done check_snmp v1.4.15 (nagios-plugins 1.4.15) check_snmp v1.4.16 (nagios-plugins 1.4.16) check_snmp v1.4.16.89.gbfe6 (nagios-plugins 1.4.16) Running those 3 results in the following: $ for i in nagios-plugins-1.4.15 nagios-plugins-1.4.16 nagios-plugins; do $i/plugins/check_snmp -P 2c -c public -H -o .1.3.6.1.2.1.43.18.1.1.7.1.1 -w 800:1200 -c 850:1150 -v -v -v ; done /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP CRITICAL - *1104* | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 So the last plugin reports CRITIAL, altough the value reported lies perfectly withing the defined warning/critical ranges. Maybe I'm doing something wrong, but still seems like a bug to me. Regards, Simon ---------------------------------------------------------------------- Comment By: Simon Kainz (simonkainz) Date: 2013-08-06 02:05 Message: Hi! Works now! Please see the output below: $ for i in nagios-plugins-1.4.15 nagios-plugins-1.4.16 nagios-plugins; do $i/plugins/check_snmp -P 2c -c public -H 129.27.9.62 -o .1.3.6.1.2.1.43.18.1.1.7.1.1 -w 800:1200 -c 850:1150 -v -v -v -V; done check_snmp v1.4.15 (nagios-plugins 1.4.15) check_snmp v1.4.16 (nagios-plugins 1.4.16) check_snmp v1.4.16.90.g9bb2 (nagios-plugins 1.4.16) g$ for i in nagios-plugins-1.4.15 nagios-plugins-1.4.16 nagios-plugins; do $i/plugins/check_snmp -P 2c -c public -H 129.27.9.62 -o .1.3.6.1.2.1.43.18.1.1.7.1.1 -w 800:1200 -c 850:1150 -v -v -v ; done /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 Thank you! Regards, Simon ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2013-08-06 01:45 Message: Thanks for your report. Could you check whether you can reproduce the bug after running $ git revert --no-edit bd782990 in your clone of the Git repository? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614879&group_id=29880 From noreply at sourceforge.net Wed Aug 7 08:09:23 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Aug 2013 23:09:23 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2555775 ] nagios check_smtp expects integer instead of double Message-ID: Bugs item #2555775, was opened at 2009-02-01 08:36 Message generated for change (Comment added) made by cyco_dd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2555775&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: Release (specify) >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Holger Weiss (hweiss) Summary: nagios check_smtp expects integer instead of double Initial Comment: The following Bugreport we got against the ubuntu package: Command execution returns error with double value: # /usr/lib/nagios/plugins/check_smtp -H localhost -w 0.2 check_smtp: Warning time must be a positive integer Usage:check_smtp -H host [-p port] [-e expect] [-C command] [-f from addr][-A authtype -U authuser -P authpass] [-w warn] [-c crit] [-t timeout] [-S] [-D days] [-n] [-v] [-4|-6] But docu ( /usr/lib/nagios/plugins/check_smtp -h) says: -w, --warning=DOUBLE Response time to result in warning status (seconds) -c, --critical=DOUBLE Response time to result in critical status (seconds) I think, that the integer check is done on error, since all other commands with -w / -c option take double arguments and sub second response time checks are really useful. ----------------------------------------- Current package: Status: install ok installed Priority: extra Section: net Installed-Size: 1252 Maintainer: Ubuntu Core Developers Architecture: i386 Source: nagios-plugins Version: 1.4.11-1ubuntu5 ---------------------------------------- Patch vs nagios-plugins-1.4.12 source (untested): --- check_smtp.orig 2009-01-19 10:57:05.000000000 +0100 +++ check_smtp.c 2009-01-19 11:34:04.000000000 +0100 @@ -103,9 +103,9 @@ char *authtype = NULL; char *authuser = NULL; char *authpass = NULL; -int warning_time = 0; +double warning_time = 0; int check_warning_time = FALSE; -int critical_time = 0; +double critical_time = 0; int check_critical_time = FALSE; int verbose = 0; int use_ssl = FALSE; @@ -432,9 +432,9 @@ elapsed_time = (double)microsec / 1.0e6; if (result == STATE_OK) { - if (check_critical_time && elapsed_time > (double) critical_time) + if (check_critical_time && elapsed_time > critical_time) result = STATE_CRITICAL; - else if (check_warning_time && elapsed_time > (double) warning_time) + else if (check_warning_time && elapsed_time > warning_time) result = STATE_WARNING; } @@ -565,21 +565,19 @@ nresponses++; break; case 'c': /* critical time threshold */ - if (is_intnonneg (optarg)) { - critical_time = atoi (optarg); - check_critical_time = TRUE; - } + if (!is_nonnegative (optarg)) + usage4 (_("Critical time must be a positive")); else { - usage4 (_("Critical time must be a positive integer")); + critical_time = strtod (optarg, NULL); + check_critical_time = TRUE; } break; case 'w': /* warning time threshold */ - if (is_intnonneg (optarg)) { - warning_time = atoi (optarg); - check_warning_time = TRUE; - } + if (!is_nonnegative (optarg)) + usage4 (_("Warning time must be a positive")); else { - usage4 (_("Warning time must be a positive integer")); + warning_time = strtod (optarg, NULL); + check_warning_time = TRUE; } break; case 'v': /* verbose */ Cross comparison with other files (e.g. check_http.c) showed that there might be more of these issues, e.g. wrong message outputs/conversions case 'w': /* warning time threshold */ if (!is_nonnegative (optarg)) usage2 (_("Warning threshold must be integer"), optarg); else { warning_time = strtod (optarg, NULL); check_warning_time = TRUE; } break; You can track the whole bugreport at https://bugs.launchpad.net/ubuntu/+source/nagios-plugins/+bug/318703 Thank, Jan. ---------------------------------------------------------------------- >Comment By: Jan Wagner (cyco_dd) Date: 2013-08-06 23:09 Message: fixed with b6f0e755fd ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2013-07-11 05:54 Message: pull request pending: https://github.com/nagios-plugins/nagios-plugins/pull/58 ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-02-04 20:37 Message: Thanks for your report. The proper fix would rather be using the nagios thresholds functions. OTOH it's more likely that we put time toward implementing the new thresholds format than fixing plugins that were never converted to the old one. Feel free to attach a working patch if you wish - we'll consider it anyway. Otherwise a quick fix would rather be fixing the documentation. ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2009-02-01 08:51 Message: File Added: patch-nagios-plugins-1.4.12 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2555775&group_id=29880 From jitendra.singh at vishalwholesale.co.in Fri Aug 9 13:39:24 2013 From: jitendra.singh at vishalwholesale.co.in (Jitendra Pratap Singh) Date: Fri, 09 Aug 2013 17:09:24 +0530 Subject: [Nagiosplug-devel] Help Require In-Reply-To: References: Message-ID: <5204D4EC.8040407@vishalwholesale.co.in> Dear, We have installed nagios3x on centos 4 and configure Server.cfg , but unable to capture other windows server traffic in/out and running activity . Pls guide us . see below server.cfg file # Define a service to "ping" the local machine define service{ uselocal-service; Name of service template to use host_name-Primary-Server service_descriptionPING check_commandcheck_ping!100.0,20%!500.0,60% } # Define a service to check the disk space of the root partition define service{ uselocal-service; Name of service template to use host_namePrimary-Server service_descriptionHTTP check_commandcheck_http notifications_enabled0 } define service{ uselocal-service; Name of service template to use host_namePrimary-Server service_descriptionCurrent Load check_commandcheck_local_load!5.0,4.0,3.0!10.0,6.0,4.0 } regds jitendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Tue Aug 13 04:26:32 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Aug 2013 19:26:32 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614897 ] check_nt COUNTER overenthusiatic isPercent test Message-ID: Bugs item #3614897, was opened at 2013-08-12 19:26 Message generated for change (Tracker Item Submitted) made by rod-payne You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614897&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rod Payne (rod-payne) Assigned to: Nobody/Anonymous (nobody) Summary: check_nt COUNTER overenthusiatic isPercent test Initial Comment: Plugin Version (-V output): check_nt v1991 (nagios-plugins 1.4.13) Plugin Name: check_nt Plugin Commandline showing issues: -l "\\PhysicalDisk(_Total)\\Avg. Disk sec/Transfer","Seconds/transfer = %.6f","seconds" -w 1.000000 -c 2.000000 This returns performance data like: 'Seconds/transfer = %.6f&'=0.000044%;1.000000;2.000000 Note the percent sign (%) after the counter value. This confuses the graph programs. (%.6f is being specified because with just a clear description/label field, only two decimal places are displayed, and for this counter it mostly shows "Second/transfer = 0.00 seconds".) Whenever the description is formated for printf substitution ("Seconds/transfer = %.6f") in this example, the isPercent test finds the % in the description, overriding whatever may have been specified in counter_unit. It should be looking for a % in the perfmon counter name only. Alternately, allow the user to specify the counter_unit and override the isPercent test. Alternately, allow the user to specify the number of decimal places in the result. Code: (looking at line numbers in https://github.com/nagios-plugins/nagios-plugins/blob/master/plugins/check_nt.c) ----- insert after 93 ----- char *counter_name = NULL; ----- replace 339-341 ----- isPercent = (strchr (value_list, '%') != NULL); strtok (value_list, "&"); /* burn the first parameters */ ----- with ----- counter_name = strtok (value_list, "&"); isPercent = (strchr (counter_name, '%') != NULL); ------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614897&group_id=29880 From noreply at sourceforge.net Tue Aug 13 15:45:10 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Aug 2013 06:45:10 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614897 ] check_nt COUNTER overenthusiatic isPercent test Message-ID: Bugs item #3614897, was opened at 2013-08-12 19:26 Message generated for change (Comment added) made by rod-payne You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614897&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rod Payne (rod-payne) Assigned to: Nobody/Anonymous (nobody) Summary: check_nt COUNTER overenthusiatic isPercent test Initial Comment: Plugin Version (-V output): check_nt v1991 (nagios-plugins 1.4.13) Plugin Name: check_nt Plugin Commandline showing issues: -l "\\PhysicalDisk(_Total)\\Avg. Disk sec/Transfer","Seconds/transfer = %.6f","seconds" -w 1.000000 -c 2.000000 This returns performance data like: 'Seconds/transfer = %.6f&'=0.000044%;1.000000;2.000000 Note the percent sign (%) after the counter value. This confuses the graph programs. (%.6f is being specified because with just a clear description/label field, only two decimal places are displayed, and for this counter it mostly shows "Second/transfer = 0.00 seconds".) Whenever the description is formated for printf substitution ("Seconds/transfer = %.6f") in this example, the isPercent test finds the % in the description, overriding whatever may have been specified in counter_unit. It should be looking for a % in the perfmon counter name only. Alternately, allow the user to specify the counter_unit and override the isPercent test. Alternately, allow the user to specify the number of decimal places in the result. Code: (looking at line numbers in https://github.com/nagios-plugins/nagios-plugins/blob/master/plugins/check_nt.c) ----- insert after 93 ----- char *counter_name = NULL; ----- replace 339-341 ----- isPercent = (strchr (value_list, '%') != NULL); strtok (value_list, "&"); /* burn the first parameters */ ----- with ----- counter_name = strtok (value_list, "&"); isPercent = (strchr (counter_name, '%') != NULL); ------------------- ---------------------------------------------------------------------- >Comment By: Rod Payne (rod-payne) Date: 2013-08-13 06:45 Message: Also, the help text does not have a closing quote and mention the counter_unit: ----- replace 736 ----- printf (" %s\n", _("-l \"\\\\\\\\counter\",\"")); ----- with ----- printf (" %s\n", _("-l \"\\\\\\\\counter\",\"\",\"\"")); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614897&group_id=29880 From roderickhpayne at gmail.com Wed Aug 14 03:59:31 2013 From: roderickhpayne at gmail.com (Rod Payne) Date: Tue, 13 Aug 2013 21:59:31 -0400 Subject: [Nagiosplug-devel] Suggest using quotes instead of apostrophes around the certificate name in sslutils.c for check_http In-Reply-To: References: Message-ID: I would like to suggest using quotes (\?) instead of apostrophes (?) around the certificate name in sslutils.c for check_http so that Nagios displays the name in quotes instead of surrounded by ?'?. (BTW, displaying the name is an excellent enhancement.) check_http v1.4.16 (nagios-plugins 1.4.16) Before: COMMAND: /usr/local/nagios/libexec/check_http -I 10.11.252.246 -C 30 OUTPUT: OK - Certificate 'mail.kaleidahealth.org' will expire on 10/21/2014 12:00. After: COMMAND: /usr/local/nagios/libexec/check_http -I 10.11.252.246 -C 30 OUTPUT: OK - Certificate "mail.kaleidahealth.org" will expire on 10/21/2014 12:00. -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Wed Aug 14 12:04:14 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Aug 2013 03:04:14 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614897 ] check_nt COUNTER overenthusiatic isPercent test Message-ID: Bugs item #3614897, was opened at 2013-08-12 19:26 Message generated for change (Comment added) made by cyco_dd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614897&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rod Payne (rod-payne) Assigned to: Nobody/Anonymous (nobody) Summary: check_nt COUNTER overenthusiatic isPercent test Initial Comment: Plugin Version (-V output): check_nt v1991 (nagios-plugins 1.4.13) Plugin Name: check_nt Plugin Commandline showing issues: -l "\\PhysicalDisk(_Total)\\Avg. Disk sec/Transfer","Seconds/transfer = %.6f","seconds" -w 1.000000 -c 2.000000 This returns performance data like: 'Seconds/transfer = %.6f&'=0.000044%;1.000000;2.000000 Note the percent sign (%) after the counter value. This confuses the graph programs. (%.6f is being specified because with just a clear description/label field, only two decimal places are displayed, and for this counter it mostly shows "Second/transfer = 0.00 seconds".) Whenever the description is formated for printf substitution ("Seconds/transfer = %.6f") in this example, the isPercent test finds the % in the description, overriding whatever may have been specified in counter_unit. It should be looking for a % in the perfmon counter name only. Alternately, allow the user to specify the counter_unit and override the isPercent test. Alternately, allow the user to specify the number of decimal places in the result. Code: (looking at line numbers in https://github.com/nagios-plugins/nagios-plugins/blob/master/plugins/check_nt.c) ----- insert after 93 ----- char *counter_name = NULL; ----- replace 339-341 ----- isPercent = (strchr (value_list, '%') != NULL); strtok (value_list, "&"); /* burn the first parameters */ ----- with ----- counter_name = strtok (value_list, "&"); isPercent = (strchr (counter_name, '%') != NULL); ------------------- ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2013-08-14 03:04 Message: easiest way to get patches integrated is to send push requests to https://github.com/nagios-plugins/nagios-plugins ---------------------------------------------------------------------- Comment By: Rod Payne (rod-payne) Date: 2013-08-13 06:45 Message: Also, the help text does not have a closing quote and mention the counter_unit: ----- replace 736 ----- printf (" %s\n", _("-l \"\\\\\\\\counter\",\"")); ----- with ----- printf (" %s\n", _("-l \"\\\\\\\\counter\",\"\",\"\"")); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614897&group_id=29880 From noreply at sourceforge.net Thu Aug 15 11:00:32 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Aug 2013 02:00:32 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552836 ] check_http does not handle ; in -k parameters Message-ID: Bugs item #3552836, was opened at 2012-07-31 16:03 Message generated for change (Comment added) made by svennierlein You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552836&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Duplicate Priority: 5 Private: No Submitted By: C?lestyo (calestyo) >Assigned to: sni (svennierlein) Summary: check_http does not handle ; in -k parameters Initial Comment: Hi. This is from the old / soon to be disabled again Nagios Plugins bug tracker that used to be at Nagios itself. I've just copied this bug over. I'm not the original reporter and have no idea about the thoughts about this bug. This used to be: http://tracker.nagios.org/view.php?id=237 -------------------------------------------------------------------------------- agflem: -------------------------------------------------------------------------------- When I execute the following check the cookie value is broken up onto two lines, thus the check always returns a 400 error. ./check_http -H mysite.com -u http://mysite.com/home/index.aspx [^] -f follow -s Welcome -k 'Cookie: user=4reqrerqwr;userlogin=123adsfjlk324' -v The cookie in the request looks like: Cookie: user=4reqrerqwr userlogin=123adsfjlk324 But should look like Cookie: user=4reqrerqwr;userlogin=123adsfjlk324 ---------------------------------------------------------------------- >Comment By: sni (svennierlein) Date: 2013-08-15 02:00 Message: fixed in git #5815864e6cda7c247b62d1c9e84349e5a678040f ---------------------------------------------------------------------- Comment By: sni (svennierlein) Date: 2013-08-15 02:00 Message: This problem is now fixed in Git. Thank you for your report. ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2013-05-29 13:48 Message: This is the same issue as reported in #3571331. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552836&group_id=29880 From holger at cis.fu-berlin.de Sat Aug 17 18:55:44 2013 From: holger at cis.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Sat, 17 Aug 2013 18:55:44 +0200 Subject: [Nagiosplug-devel] Bug -> nagios-plugins In-Reply-To: References: Message-ID: <20130817165544.GR282039@zedat.fu-berlin.de> * OUISLY C?dric [2013-07-19 17:04]: > Validate.xs: In function 'get_type': > Validate.xs:208:5: error: duplicate case value > Validate.xs:205:5: error: previously used here I cannot reproduce this with my oldish Perl (5.10.1) on Debian Squeeze, but it looks like they merged SVt_IV and SVt_RV to have the same value in newer Perl releases. The workaround for you would be to remove one of the offending lines from Validate.xs after running into the failure, e.g. (assuming GNU sed(1)): $ ./configure --enable-perl-modules $ make || sed -i -e 208d perlmods/Params-Validate-0.88/Validate.xs $ make $ make install I'd guess this issue is fixed in newer Params::Validate versions, we should update the bundled Perl modules (or maybe stop bundling them). Holger From holger at cis.fu-berlin.de Sat Aug 17 19:27:39 2013 From: holger at cis.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Sat, 17 Aug 2013 19:27:39 +0200 Subject: [Nagiosplug-devel] [PATCH] Outbound connections from alternate interfaces In-Reply-To: <91BAC3C2-9B94-41BF-986A-A11F312EE77D@silence.org> References: <91BAC3C2-9B94-41BF-986A-A11F312EE77D@silence.org> Message-ID: <20130817172739.GA330296@zedat.fu-berlin.de> * Sam Clippinger [2013-02-05 12:25]: > Most of my servers have multiple IP addresses and today I needed the > ability to check outbound SMTP from those secondary addresses instead of > always using the primary address. (I use check_smtp to test if my mail > servers are blocked by blacklists that can't be checked through DNS > (e.g. AT&T) and some of my servers use alternate interfaces for > delivery.) So I came up with this patch. It adds a "-I" argument to > check_smtp that will accept a hostname, IP or IPv6 address. If the > argument is supplied and the address is bound to the local machine, it > will use it for the outgoing connection. If it can't bind to the > address, it will print an error and exit with UNKNOWN status. Looks fine to me. Just a stylistic note: I wouldn't name the function "np_net_connect_inner", as the caller isn't interested in whether or not it's wrapped by some other function within netutils.c. Maybe call it "np_net_connect_from" instead? Could you change the name and then create a pull request on GitHub (or via email)? If you could also add a test case for the new option, that would be awesome. > Since the meat of the changes are in netutils.[ch], it should be trivial > to add a similar argument to other tests as well, if anyone wants to. Indeed. Thank you for your contribution, and sorry for the late reply. Holger From holger at cis.fu-berlin.de Sat Aug 17 20:14:52 2013 From: holger at cis.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Sat, 17 Aug 2013 20:14:52 +0200 Subject: [Nagiosplug-devel] New release numbering scheme and Git branches Message-ID: <20130817181452.GV282039@zedat.fu-berlin.de> We'd like to propose a change to the release numbering and Git branching before the next release. The idea is to (re)introduce a "maint" branch that only gets obvious bug fixes, and to also cut releases from that. We would keep the X.Y.Z version numbers, and increment Z for bug fix releases (cut from "maint"), increment Y for backwards-compatible feature releases (cut from "master"), and increment X when releasing backwards-incompatible features. We'd also like to introduce a "pu" branch for merging pull requests _before_ reviewing them closely. That's basically what the gitworkflows(7) man page suggests. My hope is that we could get out minor releases (with possibly just a small number of fixes) more often, as other projects do it. The "pu" branch would make new contributions more accessible for testing. So, unless anybody objects, the next release will be version 1.5, and we'll then create the "maint" and "pu" branches. Holger From holger at cis.fu-berlin.de Sat Aug 17 22:48:53 2013 From: holger at cis.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Sat, 17 Aug 2013 22:48:53 +0200 Subject: [Nagiosplug-devel] [PATCH/PULL] Various improvements and fixes for check_pgsql In-Reply-To: <20120705095354.GF9887@whisky.of.teamix.net> References: <20110408093132.GH20370@chough.tokkee.org> <20120705095354.GF9887@whisky.of.teamix.net> Message-ID: <20130817204853.GB330296@zedat.fu-berlin.de> * Sebastian Harl [2012-07-05 11:53]: > While the query support is a bit redundant with the check_dbi plugin by > now, I still think that could also be included in check_pgsql (after all > the code is already there, it's not that complex/much and I'm willing to > support it ;-)). Comments, flames, whatever about that would be much > appreciated, though. If people disagree, I'll extract the other patches. > > The branch is now available at > . > > Any comments, feedback? I finally found the time to read the diffs, and I merged all of them. Thanks a lot for these commits, and for your patience. Holger From noreply at sourceforge.net Sun Aug 18 01:02:49 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Aug 2013 16:02:49 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552839 ] Option for check_procs to ignore kernel threads Message-ID: Bugs item #3552839, was opened at 2012-07-31 16:11 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552839&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: Option for check_procs to ignore kernel threads Initial Comment: Hi. This is from the old / soon to be disabled again Nagios Plugins bug tracker that used to be at Nagios itself. I've just copied this bug over. I'm not the original reporter and have no idea about the thoughts about this bug. This used to be: http://tracker.nagios.org/view.php?id=221 -------------------------------------------------------------------------------- fmalfoy: -------------------------------------------------------------------------------- Hi, Amount of cores in new processor series tends to get larger and larger. The Linux kernel runs one specific kernel thread on each physical or logical core, and for several services. These kernel threads are seen as processes by the check_procs plugin, and thus taken in count while comparing to the thresholds. It would be a great functionality to be able to tell check_procs to not select them. This would allow the checks to be less dependent on the hardware specifications. The only way, for now, to avoid any alarm is to increase the thresholds, which implies to create a specific check, or checking group, for each hardware model. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2013-08-17 16:02 Message: The check_procs plugin now has a "-k" option (implemented by Richard Leitner) that does just that. ---------------------------------------------------------------------- Comment By: Richard Leitner (g0hl1n) Date: 2013-05-29 08:26 Message: Hi, I've just added a pull request (#53) to fix this issue on GNU/Linux Systems. https://github.com/nagios-plugins/nagios-plugins/pull/53 br, Richard ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552839&group_id=29880 From noreply at sourceforge.net Sun Aug 18 11:16:32 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Aug 2013 02:16:32 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3600122 ] Old version of gnulib assumes gets is defined Message-ID: Bugs item #3600122, was opened at 2013-01-09 09:38 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3600122&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: racb () Assigned to: Holger Weiss (hweiss) Summary: Old version of gnulib assumes gets is defined Initial Comment: The next release of Ubuntu will use eglibc 2.16, which drops the definition of gets (following ISO C11). The embedded gnulib assumes that gets is defined, and thus causes a build failure in the current development release of Ubuntu. Upstream gnulib has followed this change in http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=66712c23388e93e5c518ebc8515140fa0c807348 Workaround is to disable the warning in gl/stdio.in.h. Please update gnulib to allow nagios-plugins to compile in environments where gets is not defined. Ubuntu bug: https://launchpad.net/bugs/1097848 Thanks! ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2013-08-18 02:16 Message: We've updated Gnulib in the current Git code. Please test the snapshot to check whether everything works fine now: http://nagiosplug.sourceforge.net/snapshot/nagios-plugins-master.tar.gz Thanks! ---------------------------------------------------------------------- Comment By: inaki_mtz (inakimtz) Date: 2013-04-05 01:15 Message: Same issue on OpenSuse 12.3 clean install when compiling nagios-plugins 1.4.16 ./stdio.h:456:1: error: 'gets' undeclared here (not in a function) make[5]: *** [localcharset.o] Error 1 ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2013-01-09 10:57 Message: Yes, we're aware of that issue and will update Gnulib before the next release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3600122&group_id=29880 From noreply at sourceforge.net Sun Aug 18 23:15:25 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Aug 2013 14:15:25 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-2257044 ] check_http client ssl certificate support Message-ID: Feature Requests item #2257044, was opened at 2008-11-10 10:19 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=2257044&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Priority: 5 Private: No Submitted By: cybernet_ (cybernet_) Assigned to: Nobody/Anonymous (nobody) Summary: check_http client ssl certificate support Initial Comment: Hi, I know thant there's a contrib plugin check_http-with-client-certificate.c that support client cert but it would be nice that this feature was added to the currect version of check_http. The contrib plugin mentioned is a little bit out of date (2003). thanks Cybernet_ ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2013-08-18 14:15 Message: Lionel Cons added client certificate authentication support to check_http. Please use the current snapshot if you'd like to try this out: http://nagiosplug.sourceforge.net/snapshot/nagios-plugins-master.tar.gz ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=2257044&group_id=29880 From noreply at sourceforge.net Mon Aug 19 23:13:45 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Aug 2013 14:13:45 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3611599 ] check_load -r uses misleading value for ncpus. Message-ID: Bugs item #3611599, was opened at 2013-04-22 13:44 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3611599&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: check_load -r uses misleading value for ncpus. Initial Comment: check_load -r uses the macro sysconf(__SC_nprocessors_conf) If you are on a system with hyper-threading disabled after boot, this value is incorrect since it counts configured rather than active CPUS. The code works correctly in this case if you change the macro to sysconf(__SC_nprocessors_ONLN) I've attached a patch to implement this change. ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2013-08-19 14:13 Message: This problem is now fixed in Git. Thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3611599&group_id=29880 From noreply at sourceforge.net Mon Aug 19 23:14:07 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Aug 2013 14:14:07 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3611599 ] check_load -r uses misleading value for ncpus. Message-ID: Bugs item #3611599, was opened at 2013-04-22 13:44 Message generated for change (Settings changed) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3611599&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: check_load -r uses misleading value for ncpus. Initial Comment: check_load -r uses the macro sysconf(__SC_nprocessors_conf) If you are on a system with hyper-threading disabled after boot, this value is incorrect since it counts configured rather than active CPUS. The code works correctly in this case if you change the macro to sysconf(__SC_nprocessors_ONLN) I've attached a patch to implement this change. ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2013-08-19 14:13 Message: This problem is now fixed in Git. Thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3611599&group_id=29880 From holger at cis.fu-berlin.de Tue Aug 20 01:00:18 2013 From: holger at cis.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Tue, 20 Aug 2013 01:00:18 +0200 Subject: [Nagiosplug-devel] [PATCH] NetBSD support for check_ide_smart In-Reply-To: <1kx9ash.mroe6u1aqxuevM%manu@netbsd.org> References: <1kx9ash.mroe6u1aqxuevM%manu@netbsd.org> Message-ID: <20130819230018.GA467284@zedat.fu-berlin.de> * Emmanuel Dreyfus [2013-01-25 14:00]: > Below are patches to get check_ide_smart working on NetBSD. > Could it be checked in? I committed them now, thanks. Holger From noreply at sourceforge.net Tue Aug 20 23:34:38 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Aug 2013 14:34:38 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614716 ] np_net_ssl_read fails to take SSL_WANT_READ into account Message-ID: Bugs item #3614716, was opened at 2013-07-16 07:17 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614716&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Pepijn Schmitz (pepijn) Assigned to: Holger Weiss (hweiss) Summary: np_net_ssl_read fails to take SSL_WANT_READ into account Initial Comment: The np_net_ssl_read function in sslutils.c fails to take the SSL_ERROR_WANT_READ return code into account. This is not an error but indicates that the read should be retried. It can occur for instance when an SSL/TLS renegotiation occurs. This is causing the following check_http command to fail with a "HTTP CRITICAL - Error on receive" message, causing a false negative (the site in question works fine): check_http -I www.essentialmall.com -S The fix is to replace the np_net_ssl_read() function with this: int np_net_ssl_read(void *buf, int num) { int rc; do { rc = SSL_read(s, buf, num); } while ((rc < 0) && (SSL_get_error(s, rc) == SSL_ERROR_WANT_READ)); return rc; } ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2013-08-20 14:34 Message: This should be fixed in the current Git code. You could try this out with the current snapshot: http://nagiosplug.sourceforge.net/snapshot/nagios-plugins-master.tar.gz ---------------------------------------------------------------------- Comment By: Pepijn Schmitz (pepijn) Date: 2013-07-16 15:55 Message: I guess the write function should be similarly adapted (for SSL_ERROR_WANT_WRITE), but I have not seen that cause a problem yet. ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2013-07-16 09:40 Message: easiest way to get patches integrated is to send push requests to https://github.com/nagios-plugins/nagios-plugins ---------------------------------------------------------------------- Comment By: Pepijn Schmitz (pepijn) Date: 2013-07-16 07:19 Message: This is in release 1.4.16. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614716&group_id=29880 From holger at cis.fu-berlin.de Tue Aug 20 23:37:11 2013 From: holger at cis.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Tue, 20 Aug 2013 23:37:11 +0200 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614716 ] np_net_ssl_read fails to take SSL_WANT_READ into account In-Reply-To: References: <20130716223144.GB18712@zedat.fu-berlin.de> Message-ID: <20130820213711.GC282039@zedat.fu-berlin.de> * William Leibzon [2013-07-16 15:57]: > On Tue, Jul 16, 2013 at 3:31 PM, Holger Wei? wrote: > > * William Leibzon [2013-07-16 14:28]: > >> and SSL_WANT_READ needs to be handled. > > > > I was going to check whether setting SSL_MODE_AUTO_RETRY? would be a > > better choice. When using blocking I/O, I don't see the point in having > > OpenSSL's I/O functions return SSL_WANT_READ. I just wanted to make > > sure this won't break GnuTLS (or older OpenSSL versions, but I think > > they introduced SSL_MODE_AUTO_RETRY ages ago). If GnuTLS supports > > SSL_MODE_AUTO_RETRY, I'd happily pull a commit that sets this mode > > (maybe wrapped in an "#ifdef SSL_MODE_AUTO_RETRY" if it's only supported > > by newer GnuTLS versions). > > Yeah, that's even better. It was added in 0.9.6 which is 2004. Thanks for checking. I committed this now: https://github.com/nagios-plugins/nagios-plugins/commit/f4b90cabc002 Holger From noreply at sourceforge.net Tue Aug 20 23:40:55 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Aug 2013 14:40:55 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3571331 ] check_http converts semicolon to newline in -k Message-ID: Bugs item #3571331, was opened at 2012-09-24 14:14 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3571331&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: release-1.4.15 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: RudolfPotucekSmart (rpsmart) Assigned to: Holger Weiss (hweiss) Summary: check_http converts semicolon to newline in -k Initial Comment: When trying to pass Accept: headers, which are supposed to contain semicolons, using the -k option then the semicolon is converted to a newline (verified using snapshot version 1.4.16-38-g4cdd on RHEL 6.3 and recording request using tcpdump: call: ./nagios-plugins-1.4.16-38-g4cdd/plugins/check_http -I obfuscated -H obfuscated -k 'Accept: application/json;charset=UTF-8' -u obfuscated tcpdump / wireshark: GET ofuscated HTTP/1.1 User-Agent: check_http/v1.4.16-38-g4cdd (nagios-plugins 1.4.16) Connection: close Host: obfuscated Accept: application/json charset=UTF-8 ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2013-08-20 14:40 Message: This problem is now fixed in Git. Thank you for your report. ---------------------------------------------------------------------- Comment By: Richard Leitner (g0hl1n) Date: 2013-05-29 13:53 Message: Hi, multiple -k options are already implemented in the current check_http. Using them you can define multiple HTTP header fields. Until now check_http wasn't able to handle semicolons (;) in an header field, due to the fact it split them up into multiple header fields. So after my patch the mentioned use of check_http (./nagios-plugins-1.4.16-38-g4cdd/plugins/check_http -I obfuscated -H obfuscated -k 'Accept: application/json;charset=UTF-8' -u obfuscated) will work (I've testes it, I swear^^), but you wouldn't be able to specify multiple Header fields in one -k option. Hope this describes it well. Otherwise just check the sources at https://github.com/nagios-plugins/nagios-plugins/pull/52/files or the help text of check_http. br, Richard ---------------------------------------------------------------------- Comment By: RudolfPotucekSmart (rpsmart) Date: 2013-05-29 09:36 Message: I think multiple -k options don't help because there is only ONE header called "Accept:" with a value of "application/json;charset=UTF-8" ---------------------------------------------------------------------- Comment By: Richard Leitner (g0hl1n) Date: 2013-05-29 06:06 Message: Hi, btw: I've opened a pull request for the removal of the semicolon input delimiter from the -k argument. br, Richard ---------------------------------------------------------------------- Comment By: Richard Leitner (g0hl1n) Date: 2013-05-29 05:32 Message: Hi, as far as I see in the check_http source the semicolon is used as delimiter for multiple header fields. So as the semicolon is a valid character in header fields this should be changed. Due to the fact multiple -k arguments could be passed I think such a delimiter isn't needed at all. Is there an other reason for this delimiter? br, Richard ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3571331&group_id=29880 From noreply at sourceforge.net Wed Aug 21 12:13:17 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Aug 2013 03:13:17 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3613736 ] check_disk show 0% used on some part on AIX Message-ID: Bugs item #3613736, was opened at 2013-05-22 09:20 Message generated for change (Comment added) made by patrickjolliffe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3613736&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: cameleon078 (cameleon078) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk show 0% used on some part on AIX Initial Comment: I have an issue on check_disk on some part on AIX system. -bash-3.00# /var/opt/nagios/plugins/check_disk -w 5% -p /dev/tsm02fORA0lv -vvvv calling stat on /dev/tsm02fORA0lv For /ptsm02/server/filesORA0, used_pct=100 free_pct=0 used_units=1831 free_units=0 total_units=1.1991e+07 used_inodes_pct=1 free_inodes_pct=99 fsp.fsu_blocksize=4096 mult=1048576 Freespace_units result=0 Freespace% result=1 Usedspace_units result=0 Usedspace_percent result=0 Usedinodes_percent result=0 Freeinodes_percent result=0 DISK WARNING - free space: /ptsm02/server/filesORA0 0 MB (0% inode=99%);| /ptsm02/server/filesORA0=1831MB;11391488;;0;11991040 -bash-3.00# df -k /dev/tsm02fORA0lv Filesystem 1024-blocks Free %Used Iused %Iused Mounted on /dev/tsm02fORA0lv 12278824960 12276949612 1% 5 1% /ptsm02/server/filesORA0 -bash-3.00# df -i /dev/tsm02fORA0lv Filesystem 512-blocks Free %Used Iused %Iused Mounted on /dev/tsm02fORA0lv 24557649920 24553899224 1% 5 1% /ptsm02/server/filesORA0 ---------------------------------------------------------------------- Comment By: Patrick Jolliffe (patrickjolliffe) Date: 2013-08-21 03:13 Message: I am getting the same issue. Not sure if it is related to 2918714 - note that is also on AIX. Volume I am testing is 11TB in size. I added some debug output as follows; void get_path_stats (struct parameter_list *p, struct fs_usage *fsp) { p->total = fsp->fsu_blocks; /* 2007-12-08 - Workaround for Gnulib reporting insanely high available * space on BSD (the actual value should be negative but fsp->fsu_bavail * is unsigned) */ printf("PVJ %g %g\n", fsp->fsu_bavail, fsp->fsu_bfree); p->available = fsp->fsu_bavail > fsp->fsu_bfree ? 0 : fsp->fsu_bavail; Output is: PVJ -NaNQ 1.51616e-314 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3613736&group_id=29880 From noreply at sourceforge.net Wed Aug 21 12:27:54 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Aug 2013 03:27:54 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3613736 ] check_disk show 0% used on some part on AIX Message-ID: Bugs item #3613736, was opened at 2013-05-22 09:20 Message generated for change (Settings changed) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3613736&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: cameleon078 (cameleon078) >Assigned to: Holger Weiss (hweiss) Summary: check_disk show 0% used on some part on AIX Initial Comment: I have an issue on check_disk on some part on AIX system. -bash-3.00# /var/opt/nagios/plugins/check_disk -w 5% -p /dev/tsm02fORA0lv -vvvv calling stat on /dev/tsm02fORA0lv For /ptsm02/server/filesORA0, used_pct=100 free_pct=0 used_units=1831 free_units=0 total_units=1.1991e+07 used_inodes_pct=1 free_inodes_pct=99 fsp.fsu_blocksize=4096 mult=1048576 Freespace_units result=0 Freespace% result=1 Usedspace_units result=0 Usedspace_percent result=0 Usedinodes_percent result=0 Freeinodes_percent result=0 DISK WARNING - free space: /ptsm02/server/filesORA0 0 MB (0% inode=99%);| /ptsm02/server/filesORA0=1831MB;11391488;;0;11991040 -bash-3.00# df -k /dev/tsm02fORA0lv Filesystem 1024-blocks Free %Used Iused %Iused Mounted on /dev/tsm02fORA0lv 12278824960 12276949612 1% 5 1% /ptsm02/server/filesORA0 -bash-3.00# df -i /dev/tsm02fORA0lv Filesystem 512-blocks Free %Used Iused %Iused Mounted on /dev/tsm02fORA0lv 24557649920 24553899224 1% 5 1% /ptsm02/server/filesORA0 ---------------------------------------------------------------------- Comment By: Patrick Jolliffe (patrickjolliffe) Date: 2013-08-21 03:13 Message: I am getting the same issue. Not sure if it is related to 2918714 - note that is also on AIX. Volume I am testing is 11TB in size. I added some debug output as follows; void get_path_stats (struct parameter_list *p, struct fs_usage *fsp) { p->total = fsp->fsu_blocks; /* 2007-12-08 - Workaround for Gnulib reporting insanely high available * space on BSD (the actual value should be negative but fsp->fsu_bavail * is unsigned) */ printf("PVJ %g %g\n", fsp->fsu_bavail, fsp->fsu_bfree); p->available = fsp->fsu_bavail > fsp->fsu_bfree ? 0 : fsp->fsu_bavail; Output is: PVJ -NaNQ 1.51616e-314 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3613736&group_id=29880 From holger at cis.fu-berlin.de Wed Aug 21 12:57:22 2013 From: holger at cis.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Wed, 21 Aug 2013 12:57:22 +0200 Subject: [Nagiosplug-devel] Bug -> nagios-plugins In-Reply-To: <20130817165544.GR282039@zedat.fu-berlin.de> References: <20130817165544.GR282039@zedat.fu-berlin.de> Message-ID: <20130821105722.GH282039@zedat.fu-berlin.de> * Holger Wei? [2013-08-17 18:55]: > * OUISLY C?dric [2013-07-19 17:04]: > > Validate.xs: In function 'get_type': > > Validate.xs:208:5: error: duplicate case value > > Validate.xs:205:5: error: previously used here > > I cannot reproduce this with my oldish Perl (5.10.1) on Debian Squeeze, > but it looks like they merged SVt_IV and SVt_RV to have the same value > in newer Perl releases. The workaround for you would be to remove one > of the offending lines from Validate.xs after running into the failure, > e.g. (assuming GNU sed(1)): > > $ ./configure --enable-perl-modules > $ make || sed -i -e 208d perlmods/Params-Validate-0.88/Validate.xs > $ make > $ make install > > I'd guess this issue is fixed in newer Params::Validate versions, we > should update the bundled Perl modules [...]. We've done this now (thanks a lot to Ton who did most of the work, and to Sven for testing!), so you could try whether the current snapshot works for you: http://nagiosplug.sourceforge.net/snapshot/nagios-plugins-master.tar.gz Holger From holger at cis.fu-berlin.de Wed Aug 21 14:35:59 2013 From: holger at cis.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Wed, 21 Aug 2013 14:35:59 +0200 Subject: [Nagiosplug-devel] New Threshold Syntax In-Reply-To: References: Message-ID: <20130821123559.GI282039@zedat.fu-berlin.de> * P?ll Gu?j?n Sigur?sson [2013-07-15 20:57]: > We implemented same RFC in pynag (python modules for nagios related > stuff). We also hit some walls and wanted to make modifications. > Unfortunately, it's been a long time since it was written and author of > the proposal is not answering my emails on the topic. > > I am not sure if there is a lot of motivation among the nagios-plugins > folks to implement this RFC, so i wonder if third party libraries like > you and should coordinate on it anyway ? We (the Plugins Development Team) discussed this internally, but we haven't really reached a consensus on how to proceed. Some concerns have been raised regarding the added complexity and the amount of refactoring necessary to check only for specified thresholds. Either way, I guess we must acknowledge that we currently lack the manpower to implement a new threshold syntax, which means we'll probably stick to the current syntax for the time being. So I'd say yes: Please move ahead independently of us. Personally I quite like the new syntax, and if you settled on the details and it works well for you, we can still decide on whether and how to adopt it :-) Thanks a lot for your work on this! Holger From noreply at sourceforge.net Wed Aug 21 15:12:44 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Aug 2013 06:12:44 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614879 ] Incocistencies between plugins versions Message-ID: Bugs item #3614879, was opened at 2013-08-06 01:15 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614879&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None >Status: Pending >Resolution: Fixed Priority: 6 Private: No Submitted By: Simon Kainz (simonkainz) Assigned to: Holger Weiss (hweiss) Summary: Incocistencies between plugins versions Initial Comment: I took nagios-plugins from github and noticed the following: Using version 1.4.16.89.gbfe6, the processing of waring/critical ranges in check_snmp seems to be broken. OS: Debian Wheezy 64bit Compiler: 6cc I built all 3 versions by myself from source. I uses these 3 versions for a test: $ for i in nagios-plugins-1.4.15 nagios-plugins-1.4.16 nagios-plugins; do $i/plugins/check_snmp -P 2c -c public -H -o .1.3.6.1.2.1.43.18.1.1.7.1.1 -w 800:1200 -c 850:1150 -v -v -v -V ; done check_snmp v1.4.15 (nagios-plugins 1.4.15) check_snmp v1.4.16 (nagios-plugins 1.4.16) check_snmp v1.4.16.89.gbfe6 (nagios-plugins 1.4.16) Running those 3 results in the following: $ for i in nagios-plugins-1.4.15 nagios-plugins-1.4.16 nagios-plugins; do $i/plugins/check_snmp -P 2c -c public -H -o .1.3.6.1.2.1.43.18.1.1.7.1.1 -w 800:1200 -c 850:1150 -v -v -v ; done /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP CRITICAL - *1104* | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 So the last plugin reports CRITIAL, altough the value reported lies perfectly withing the defined warning/critical ranges. Maybe I'm doing something wrong, but still seems like a bug to me. Regards, Simon ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2013-08-21 06:12 Message: We (hopefully) fixed this properly now, you might want to try the current 'master' branch without reverting the mentioned commit. Please let us know if you still encounter any issues. Thanks a lot for your report, this was quite a major regression and I'm happy you found it before we created the new release. ---------------------------------------------------------------------- Comment By: Simon Kainz (simonkainz) Date: 2013-08-06 02:05 Message: Hi! Works now! Please see the output below: $ for i in nagios-plugins-1.4.15 nagios-plugins-1.4.16 nagios-plugins; do $i/plugins/check_snmp -P 2c -c public -H 129.27.9.62 -o .1.3.6.1.2.1.43.18.1.1.7.1.1 -w 800:1200 -c 850:1150 -v -v -v -V; done check_snmp v1.4.15 (nagios-plugins 1.4.15) check_snmp v1.4.16 (nagios-plugins 1.4.16) check_snmp v1.4.16.90.g9bb2 (nagios-plugins 1.4.16) g$ for i in nagios-plugins-1.4.15 nagios-plugins-1.4.16 nagios-plugins; do $i/plugins/check_snmp -P 2c -c public -H 129.27.9.62 -o .1.3.6.1.2.1.43.18.1.1.7.1.1 -w 800:1200 -c 850:1150 -v -v -v ; done /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 Thank you! Regards, Simon ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2013-08-06 01:45 Message: Thanks for your report. Could you check whether you can reproduce the bug after running $ git revert --no-edit bd782990 in your clone of the Git repository? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614879&group_id=29880 From william at leibzon.org Wed Aug 21 17:23:41 2013 From: william at leibzon.org (William Leibzon) Date: Wed, 21 Aug 2013 08:23:41 -0700 Subject: [Nagiosplug-devel] New Threshold Syntax In-Reply-To: <20130821123559.GI282039@zedat.fu-berlin.de> References: <20130821123559.GI282039@zedat.fu-berlin.de> Message-ID: I have requested time at upcoming Nagios conference for 30 minute BoF session on this topic and to get feedback on any general features people may like to see in all the plugins. They have't got back to me yet (only sent email on Friday) but this is not a formal session and so I'd not expect an issue with holding it after normal sessions are over. My own plugins library and several plugins will support the syntax at https://github.com/willixix/nagios-plugins/wiki/New-Threshold-Syntax by conference time (just committed most of the necessary code yesterday). I hope that as independent library authors move in to this syntax, the official plugins can too although I totally understand about the manpower in the open-source effort. Still I'd like to see it a a future long-term goal to support this. William On Wed, Aug 21, 2013 at 5:35 AM, Holger Wei? wrote: > * P?ll Gu?j?n Sigur?sson [2013-07-15 20:57]: > > We implemented same RFC in pynag (python modules for nagios related > > stuff). We also hit some walls and wanted to make modifications. > > Unfortunately, it's been a long time since it was written and author of > > the proposal is not answering my emails on the topic. > > > > I am not sure if there is a lot of motivation among the nagios-plugins > > folks to implement this RFC, so i wonder if third party libraries like > > you and should coordinate on it anyway ? > > We (the Plugins Development Team) discussed this internally, but we > haven't really reached a consensus on how to proceed. Some concerns > have been raised regarding the added complexity and the amount of > refactoring necessary to check only for specified thresholds. > > Either way, I guess we must acknowledge that we currently lack the > manpower to implement a new threshold syntax, which means we'll probably > stick to the current syntax for the time being. So I'd say yes: Please > move ahead independently of us. Personally I quite like the new syntax, > and if you settled on the details and it works well for you, we can > still decide on whether and how to adopt it :-) > > Thanks a lot for your work on this! > > Holger > > > ------------------------------------------------------------------------------ > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________________ > Nagios Plugin Development Mailing List > Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jochen.Bern at LINworks.de Wed Aug 21 20:31:16 2013 From: Jochen.Bern at LINworks.de (Jochen Bern) Date: Wed, 21 Aug 2013 20:31:16 +0200 Subject: [Nagiosplug-devel] New Threshold Syntax In-Reply-To: References: <20130821123559.GI282039@zedat.fu-berlin.de> Message-ID: <52150774.1070705@LINworks.de> On 21.08.2013 17:23, William Leibzon wrote: > I have requested time at upcoming Nagios conference for 30 minute BoF > session on this topic and to get feedback on any general features people > may like to see in all the plugins. They have't got back to me yet (only > sent email on Friday) but this is not a formal session and so I'd not > expect an issue with holding it after normal sessions are over. > > My own plugins library and several plugins will support the syntax at > https://github.com/willixix/nagios-plugins/wiki/New-Threshold-Syntax by > conference time (just committed most of the necessary code yesterday). I'm afraid I haven't had much time to read up on the discussion ever since my first reply on the topic (which I made from a cell phone with an almost-depleted battery, so I'm sorry if I sounded a bit gruff), so let me take this opportunity to comment on the version currently on that page: ------- I'm missing the possibility to supply *different* labels for the same (numerical) data as presented in the output vs. in the performance data. Cases where such a differentiation would be useful, off the top of my head: -- Output (-> notifications) in local staff's primary language, but perfdata names shall be in English so as to permit *global* referencing (say, in a performance data backend system's graph templates) [Same goes for things like "Houston Interlink" vs. "Interface 4711", "upstream"/"downstream" vs. "ingress"/"egress", etc. ad nauseam] -- Continuity of saved performance data, e.g., what the first version of the plugin reported as "rx pkts" should now be properly called "received unicast packets to a local MAC" in the output but still just "rx_pkts" in the performance data Note 1: It would be a possibility to use non-{yes_or_no} values for the "display" and/or "perf" keywords to achieve this. Note 2: There are performance data backends which rely on the *order* of performance data items, rather than their naming, to have performance data items produced by the current plugin run correlated to (hopefully) equivalent items of the previous runs. Do we want to provide a means, however contrived, to control that order? Note 3: Restricting the labels to [A-Za-z0-9_-]* means that we're actually dropping behind the current perfdata spec (which allows special chars inside quotes). ------- rrdtool, as the most common basis for performance data backends, allows you to provide a non-numerical value 'U' so that you can provide complete data*sets* even in cases where single *values* are unknown / cannot be determined. PNP4Nagios followed suit and now allows plugins to return 'U' in the performance data (replacing the number, still allowing the UOM etc.). I think this should make it into an updated perfdata spec (which is likely to result from *this* activity sooner rather than later). ------- Speaking of the UOM, your spec for the "uom" keyword mirrors the current perfdata specs in only allowing UOMs from a given whitelist. [Yes, I'm aware that the allowed values for your "uom" keyword do not necessarily imply restrictions on the UOM spec for plugin output, but bear with me.] This approach has, in my opinion, proven to be a failure because it is virtually impossible to provide an all-encompassing list of UOMs that may occur in the wild. (Off the top of my head, I have "ppm" from ntpd drift files, several UOMs for bandwidth, "dBm" for GSM reception level, "degC" for Temperatures, "RPM" for fans, "V" for Voltages, ...) One consequence of that is that I do not know a *single* perfdata backend that would try to split the perfdata UOM back into unit and prefix, and *that* results in output (graphs) where UOMs like "kB" (as output by "df", for example) get scaled into "MkB" and similar chimeras. Thus, my first suggestion: Drop the ever-outdated base unit registry! Second, if we want a chance to *ever* get proper automatic UOM scaling back in working order, we need some sort of hint within the perfdata UOM string that allows the backends to tell prefix from base unit, candela from centidays, Ampere- from attohours, etc.. I'm thinking of a separator character, preferably one that results in a small, unobtrusive representation if *not* caught before Web-UI etc.. (U+00B7 looks like a good candidate to me, but I'm not very experienced with charset conversion and compatibility problems ...) ------- The "prefix" keyword *badly* needs a clarification where it shall have an effect and where not: -- prefixed to string specified with "uom" keyword -- causing the relevant number output to be rescaled -- *from* prefixed *to* prefixless UOM (i.e., "prefix:k" changes original result "3.14" to "3140", equivalent to the statement "the number obtained by the plugin up to output formatting *is in* thousands") -- *from* prefixless *to* prefixed UOM (i.e., when the plugin's original output is "4711 foo", "prefix:k" shall change it to "4.7 kfoo" -- causing the *thresholds* to be rescaled accordingly -- again, *from* or *to* the given prefix and most of this could potentially apply to a number's representation in the output, the perfdata, or both ... Kind regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im : Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Gesch?ftsf?hrer Metin Dogan, Oliver Michel From holger at cis.fu-berlin.de Wed Aug 21 21:54:09 2013 From: holger at cis.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Wed, 21 Aug 2013 21:54:09 +0200 Subject: [Nagiosplug-devel] U (was: New Threshold Syntax) In-Reply-To: <52150774.1070705@LINworks.de> References: <20130821123559.GI282039@zedat.fu-berlin.de> <52150774.1070705@LINworks.de> Message-ID: <20130821195409.GJ282039@zedat.fu-berlin.de> * Jochen Bern [2013-08-21 20:31]: > rrdtool, as the most common basis for performance data backends, allows > you to provide a non-numerical value 'U' so that you can provide > complete data*sets* even in cases where single *values* are unknown / > cannot be determined. PNP4Nagios followed suit and now allows plugins to > return 'U' in the performance data (replacing the number, still allowing > the UOM etc.). I think this should make it into an updated perfdata spec > (which is likely to result from *this* activity sooner rather than later). D'oh! During last year's OSMC, I promised J?rg to add this to the performance data specification, and then I totally forgot about that, sorry. Here's a proposal: https://github.com/nagios-plugins/nagios-plugins/commit/75a4ae68e4 Any objections, corrections, or stylistic improvements? Holger From Jochen.Bern at LINworks.de Thu Aug 22 01:09:25 2013 From: Jochen.Bern at LINworks.de (Jochen Bern) Date: Thu, 22 Aug 2013 01:09:25 +0200 Subject: [Nagiosplug-devel] U In-Reply-To: <20130821195409.GJ282039@zedat.fu-berlin.de> References: <20130821123559.GI282039@zedat.fu-berlin.de> <52150774.1070705@LINworks.de> <20130821195409.GJ282039@zedat.fu-berlin.de> Message-ID: <521548A5.1030709@LINworks.de> On 21.08.2013 21:54, Holger Wei? wrote: > https://github.com/nagios-plugins/nagios-plugins/commit/75a4ae68e4 > Any objections, corrections, or stylistic improvements? You might want to also change the part saying that multiline output "will be a feature of Nagios 3" :-), including the - now falsified - shorthand description of performance data as "everything after the | of the plugin output". (FWIW, adding a warning that extremely character-saving plugin output along the lines of printf("tic|foo=1 bar=2\ntac\ntoe|baz=3 org=4\n"); will cause Nagios 3.x to incorrectly assemble the perfdata string as "foo=1 bar=2baz=3 org=4" - which misses a space between "2" and "baz", thus being syntactically incorrect - might be worthwhile, too.) Kind regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im : Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Gesch?ftsf?hrer Metin Dogan, Oliver Michel From holger at cis.fu-berlin.de Thu Aug 22 12:31:29 2013 From: holger at cis.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Thu, 22 Aug 2013 12:31:29 +0200 Subject: [Nagiosplug-devel] U In-Reply-To: <521548A5.1030709@LINworks.de> References: <20130821123559.GI282039@zedat.fu-berlin.de> <52150774.1070705@LINworks.de> <20130821195409.GJ282039@zedat.fu-berlin.de> <521548A5.1030709@LINworks.de> Message-ID: <20130822103129.GK282039@zedat.fu-berlin.de> * Jochen Bern [2013-08-22 01:09]: > You might want to also change the part saying that multiline output > "will be a feature of Nagios 3" :-), including the - now falsified - > shorthand description of performance data as "everything after the | of > the plugin output". > > (FWIW, adding a warning that extremely character-saving plugin output > along the lines of > printf("tic|foo=1 bar=2\ntac\ntoe|baz=3 org=4\n"); > will cause Nagios 3.x to incorrectly assemble the perfdata string as > "foo=1 bar=2baz=3 org=4" > - which misses a space between "2" and "baz", thus being syntactically > incorrect - might be worthwhile, too.) Agreed, to both. Could anyone provide a patch? Holger From Jochen.Bern at LINworks.de Thu Aug 22 16:32:17 2013 From: Jochen.Bern at LINworks.de (Jochen Bern) Date: Thu, 22 Aug 2013 16:32:17 +0200 Subject: [Nagiosplug-devel] U In-Reply-To: <20130822103129.GK282039@zedat.fu-berlin.de> References: <20130821123559.GI282039@zedat.fu-berlin.de> <52150774.1070705@LINworks.de> <20130821195409.GJ282039@zedat.fu-berlin.de> <521548A5.1030709@LINworks.de> <20130822103129.GK282039@zedat.fu-berlin.de> Message-ID: <521620F1.10408@LINworks.de> On 22.08.2013 12:31, Holger Wei? wrote: > * Jochen Bern [2013-08-22 01:09]: >> You might want to also change [...] > > Agreed, to both. Could anyone provide a patch? I have neither git nor SGML tools at hand, but I'll try (-> attached). Kind regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im : Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Gesch?ftsf?hrer Metin Dogan, Oliver Michel -------------- next part -------------- A non-text attachment was scrubbed... Name: developer-guidelines.diff Type: text/x-patch Size: 2367 bytes Desc: not available URL: From holger at cis.fu-berlin.de Thu Aug 22 20:52:31 2013 From: holger at cis.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Thu, 22 Aug 2013 20:52:31 +0200 Subject: [Nagiosplug-devel] U In-Reply-To: <521620F1.10408@LINworks.de> References: <20130821123559.GI282039@zedat.fu-berlin.de> <52150774.1070705@LINworks.de> <20130821195409.GJ282039@zedat.fu-berlin.de> <521548A5.1030709@LINworks.de> <20130822103129.GK282039@zedat.fu-berlin.de> <521620F1.10408@LINworks.de> Message-ID: <20130822185231.GN282039@zedat.fu-berlin.de> * Jochen Bern [2013-08-22 16:32]: > On 22.08.2013 12:31, Holger Wei? wrote: > > * Jochen Bern [2013-08-22 01:09]: > >> You might want to also change [...] > > > > Agreed, to both. Could anyone provide a patch? > > I have neither git nor SGML tools at hand, but I'll try (-> attached). Looks good. I committed and pushed it, thanks! Holger From noreply at sourceforge.net Mon Aug 26 09:22:45 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Aug 2013 00:22:45 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614879 ] Incocistencies between plugins versions Message-ID: Bugs item #3614879, was opened at 2013-08-06 01:15 Message generated for change (Comment added) made by simonkainz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614879&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Pending Resolution: Fixed Priority: 6 Private: No Submitted By: Simon Kainz (simonkainz) Assigned to: Holger Weiss (hweiss) Summary: Incocistencies between plugins versions Initial Comment: I took nagios-plugins from github and noticed the following: Using version 1.4.16.89.gbfe6, the processing of waring/critical ranges in check_snmp seems to be broken. OS: Debian Wheezy 64bit Compiler: 6cc I built all 3 versions by myself from source. I uses these 3 versions for a test: $ for i in nagios-plugins-1.4.15 nagios-plugins-1.4.16 nagios-plugins; do $i/plugins/check_snmp -P 2c -c public -H -o .1.3.6.1.2.1.43.18.1.1.7.1.1 -w 800:1200 -c 850:1150 -v -v -v -V ; done check_snmp v1.4.15 (nagios-plugins 1.4.15) check_snmp v1.4.16 (nagios-plugins 1.4.16) check_snmp v1.4.16.89.gbfe6 (nagios-plugins 1.4.16) Running those 3 results in the following: $ for i in nagios-plugins-1.4.15 nagios-plugins-1.4.16 nagios-plugins; do $i/plugins/check_snmp -P 2c -c public -H -o .1.3.6.1.2.1.43.18.1.1.7.1.1 -w 800:1200 -c 850:1150 -v -v -v ; done /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP CRITICAL - *1104* | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 So the last plugin reports CRITIAL, altough the value reported lies perfectly withing the defined warning/critical ranges. Maybe I'm doing something wrong, but still seems like a bug to me. Regards, Simon ---------------------------------------------------------------------- Comment By: Simon Kainz (simonkainz) Date: 2013-08-26 00:22 Message: Yes, it works now. Glad I could help. Bye, Simon ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2013-08-21 06:12 Message: We (hopefully) fixed this properly now, you might want to try the current 'master' branch without reverting the mentioned commit. Please let us know if you still encounter any issues. Thanks a lot for your report, this was quite a major regression and I'm happy you found it before we created the new release. ---------------------------------------------------------------------- Comment By: Simon Kainz (simonkainz) Date: 2013-08-06 02:05 Message: Hi! Works now! Please see the output below: $ for i in nagios-plugins-1.4.15 nagios-plugins-1.4.16 nagios-plugins; do $i/plugins/check_snmp -P 2c -c public -H 129.27.9.62 -o .1.3.6.1.2.1.43.18.1.1.7.1.1 -w 800:1200 -c 850:1150 -v -v -v -V; done check_snmp v1.4.15 (nagios-plugins 1.4.15) check_snmp v1.4.16 (nagios-plugins 1.4.16) check_snmp v1.4.16.90.g9bb2 (nagios-plugins 1.4.16) g$ for i in nagios-plugins-1.4.15 nagios-plugins-1.4.16 nagios-plugins; do $i/plugins/check_snmp -P 2c -c public -H 129.27.9.62 -o .1.3.6.1.2.1.43.18.1.1.7.1.1 -w 800:1200 -c 850:1150 -v -v -v ; done /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 Thank you! Regards, Simon ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2013-08-06 01:45 Message: Thanks for your report. Could you check whether you can reproduce the bug after running $ git revert --no-edit bd782990 in your clone of the Git repository? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614879&group_id=29880 From noreply at sourceforge.net Mon Aug 26 11:54:07 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Aug 2013 02:54:07 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614879 ] Incocistencies between plugins versions Message-ID: Bugs item #3614879, was opened at 2013-08-06 01:15 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614879&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None >Status: Closed Resolution: Fixed Priority: 6 Private: No Submitted By: Simon Kainz (simonkainz) Assigned to: Holger Weiss (hweiss) Summary: Incocistencies between plugins versions Initial Comment: I took nagios-plugins from github and noticed the following: Using version 1.4.16.89.gbfe6, the processing of waring/critical ranges in check_snmp seems to be broken. OS: Debian Wheezy 64bit Compiler: 6cc I built all 3 versions by myself from source. I uses these 3 versions for a test: $ for i in nagios-plugins-1.4.15 nagios-plugins-1.4.16 nagios-plugins; do $i/plugins/check_snmp -P 2c -c public -H -o .1.3.6.1.2.1.43.18.1.1.7.1.1 -w 800:1200 -c 850:1150 -v -v -v -V ; done check_snmp v1.4.15 (nagios-plugins 1.4.15) check_snmp v1.4.16 (nagios-plugins 1.4.16) check_snmp v1.4.16.89.gbfe6 (nagios-plugins 1.4.16) Running those 3 results in the following: $ for i in nagios-plugins-1.4.15 nagios-plugins-1.4.16 nagios-plugins; do $i/plugins/check_snmp -P 2c -c public -H -o .1.3.6.1.2.1.43.18.1.1.7.1.1 -w 800:1200 -c 850:1150 -v -v -v ; done /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP CRITICAL - *1104* | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 So the last plugin reports CRITIAL, altough the value reported lies perfectly withing the defined warning/critical ranges. Maybe I'm doing something wrong, but still seems like a bug to me. Regards, Simon ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2013-08-26 02:54 Message: Thanks for confirming this. ---------------------------------------------------------------------- Comment By: Simon Kainz (simonkainz) Date: 2013-08-26 00:22 Message: Yes, it works now. Glad I could help. Bye, Simon ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2013-08-21 06:12 Message: We (hopefully) fixed this properly now, you might want to try the current 'master' branch without reverting the mentioned commit. Please let us know if you still encounter any issues. Thanks a lot for your report, this was quite a major regression and I'm happy you found it before we created the new release. ---------------------------------------------------------------------- Comment By: Simon Kainz (simonkainz) Date: 2013-08-06 02:05 Message: Hi! Works now! Please see the output below: $ for i in nagios-plugins-1.4.15 nagios-plugins-1.4.16 nagios-plugins; do $i/plugins/check_snmp -P 2c -c public -H 129.27.9.62 -o .1.3.6.1.2.1.43.18.1.1.7.1.1 -w 800:1200 -c 850:1150 -v -v -v -V; done check_snmp v1.4.15 (nagios-plugins 1.4.15) check_snmp v1.4.16 (nagios-plugins 1.4.16) check_snmp v1.4.16.90.g9bb2 (nagios-plugins 1.4.16) g$ for i in nagios-plugins-1.4.15 nagios-plugins-1.4.16 nagios-plugins; do $i/plugins/check_snmp -P 2c -c public -H 129.27.9.62 -o .1.3.6.1.2.1.43.18.1.1.7.1.1 -w 800:1200 -c 850:1150 -v -v -v ; done /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 /usr/bin/snmpget -t 1 -r 5 -m '' -v 2c [authpriv] 129.27.9.62:161 .1.3.6.1.2.1.43.18.1.1.7.1.1 iso.3.6.1.2.1.43.18.1.1.7.1.1 = INTEGER: 1104 Processing oid 1 (line 1) oidname: iso.3.6.1.2.1.43.18.1.1.7.1.1 response: = INTEGER: 1104 SNMP OK - 1104 | iso.3.6.1.2.1.43.18.1.1.7.1.1=1104 Thank you! Regards, Simon ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2013-08-06 01:45 Message: Thanks for your report. Could you check whether you can reproduce the bug after running $ git revert --no-edit bd782990 in your clone of the Git repository? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614879&group_id=29880 From holger at cis.fu-berlin.de Tue Aug 27 17:02:14 2013 From: holger at cis.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Tue, 27 Aug 2013 17:02:14 +0200 Subject: [Nagiosplug-devel] [HEADS UP] Removing the "contrib" directory Message-ID: <20130827150214.GV282039@zedat.fu-berlin.de> We decided to remove the remaining plugins from the "contrib" directory? of our repository, so they will not be shipped with the next release. This directory was created long ago to publish contributed plugins. Back then, sites such as and didn't exist. These days, those sites are a much better place for publishing plugins not maintained by the Plugins Development Team. So, if anyone is interested in any of the "contrib" plugins, please try to contact the author and suggest uploading it to Nagios Exchange; or, failing that, just publish the plugin yourself. Holger ? https://github.com/nagios-plugins/nagios-plugins/tree/7a80e27f/contrib