From noreply at sourceforge.net Wed Aug 1 00:39:01 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 15:39:01 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552814 ] Spurious 99% inode usage warning reports Message-ID: Bugs item #3552814, was opened at 2012-07-31 15:39 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552814&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: Spurious 99% inode usage warning reports 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=362 -------------------------------------------------------------------------------- bryanhunt: -------------------------------------------------------------------------------- Nagios is reporting that 99% of inodes on /home are used, when in fact only 1% are in use. Subject: ** PROBLEM Service Alert: localhost/Disk Space is WARNING ** Sent: 27 Jul 2012 17:41 ***** Nagios ***** Notification Type: PROBLEM Service: Disk Space Host: localhost Address: 127.0.0.1 State: WARNING Date/Time: Fri Jul 27 17:41:34 BST 2012 Additional Info: DISK WARNING - free space: /home 4946 MB (20% inode=99%): % sudo -u nagios /usr/lib/nagios/plugins/check_disk -m /home DISK OK - free space: /home 17275 MB (72% inode=99%);| /home=6643MB;;;0;25198 % mount /dev/mapper/dataloader-home on /home type ext3 (rw,relatime,errors=continue,data=ordered) % df -ih /home Filesystem Inodes IUsed IFree IUse% Mounted on /dev/mapper/dataloader-home 1.6M 2.4K 1.6M 1% /home % df -ih / Filesystem Inodes IUsed IFree IUse% Mounted on /dev/mapper/dataloader-root 1.3M 25K 1.3M 2% / % df /home Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/dataloader-home 25803068 6700352 17792188 28% /home System is AMD64, loads of cores. I've had a try at building plugins from source but can't get it to build on that box. I've attached the output of trying to build nagios-plugins git head. -------------------------------------------------------------------------------- brennan: -------------------------------------------------------------------------------- The check is functioning correctly. The line that starts with "free space" in the check result is the key here...you have 99% of your inodes free. -------------------------------------------------------------------------------- bryanhunt: -------------------------------------------------------------------------------- Plugin works correctly. % /usr/lib/nagios/plugins/check_disk -w 10% -c 20% -W 20% -K 10% -e The problem was the plugin configuration, which was incorrect. There might have been some copy-paste configuration going on. -------------------------------------------------------------------------------- bryanhunt: -------------------------------------------------------------------------------- Basically, what was happening, was that the command was being run like so: /usr/lib/nagios/plugins/check_disk -w 90% -c 20% -W -e DISK WARNING - free space: / 4402 MB (93% inode=98%); /dev 8035 MB (100% inode=99%); /run 1607 MB (99% inode=99%); /run/lock 5 MB (100% inode=99%); /tmp 9396 MB (99% inode=99%); /run/shm 3215 MB (100% inode=99%); /boot 198 MB (91% inode=99%); /home 17076 MB (71% inode=99%); /usr 6256 MB (78% inode=88%); /var 6718 MB (35% inode=98%);| /=302MB;495;3968;0;4960 /dev=0MB;803;6428;0;8035 /run=0MB;160;1285;0;1607 /run/lock=0MB;0;4;0;5 /tmp=11MB;991;7935;0;9919 /run/shm=0MB;321;2572;0;3215 /boot=17MB;22;181;0;227 /home=6841MB;2519;20158;0;25198 /usr=1759MB;844;6756;0;8445 /var=12429MB;2016;16133;0;20167 Note the missing parameter to -W ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552814&group_id=29880 From noreply at sourceforge.net Wed Aug 1 00:42:59 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 15:42:59 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552818 ] configure script not compatible with newer version of net-to Message-ID: Bugs item #3552818, was opened at 2012-07-31 15:42 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552818&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: configure script not compatible with newer version of net-to 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=298 -------------------------------------------------------------------------------- SethRobertson: -------------------------------------------------------------------------------- The configure script parses the output of ifconfig to find first_ip. However, a newer version of ifconfig has a different output syntax which causes first_ip to be empty. (first_ip is subsequently used to try to probe PING_COMMAND which fails, causing check_ping to fail). FAILING SYSTEM: ----------------------------------- ifconfig --version net-tools 1.60_p201111202031570500 ifconfig 1.42 (2001-04-13) eth0: flags=4163 mtu 1500 metric 1 inet 204.52.227.15 netmask 255.255.255.224 broadcast 204.52.227.159 inet6 fe80::21d:60ff:fecf:3213 prefixlen 64 scopeid 0x20 RX packets 48697927 bytes 48259662481 (44.9 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 35395890 bytes 22321875058 (20.7 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 17 eth1: flags=4163 mtu 1500 metric 1 inet 172.25.111.5 netmask 255.255.255.252 broadcast 172.25.111.59 inet6 fe80::21d:60ff:fecf:30d5 prefixlen 64 scopeid 0x20 ether 00:1d:60:cf:30:d5 txqueuelen 1000 (Ethernet) RX packets 15610212 bytes 9829520165 (9.1 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 9213019 bytes 628567083 (599.4 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 16 base 0xec00 lo: flags=73 mtu 16436 metric 1 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 0 (Local Loopback) RX packets 126050249 bytes 344817663604 (321.1 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 126050249 bytes 344817663604 (321.1 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ------------------------------------------------------------------- WORKING SYSTEM ----------------------------------- ifconfig --version net-tools 1.60_p20110409135728 ifconfig 1.42 (2001-04-13) -------------------------------------------------------------------------------- SethRobertson: -------------------------------------------------------------------------------- Gaa, it submitted before I was done. Stupid forms. This was using nagios-plugins-1.4.15 running on Gentoo. The following command would seem to work on both the new and old output syntax: /sbin/ifconfig | egrep "inet (addr:)?" | sed -n -r -e 's/ (Bcast|netmask).*$//' -e 's/^\s*inet (addr:)?//' -e '1p' One further suggestion (untested) is to simply use 127.0.0.1 if first_ip is undefined add the following line to configure.ac immediately after the first_ip definition attempt. : ${first_ip:=127.0.0.1} These are the working ifconfig output. eth0 Link encap:Ethernet HWaddr 00:25:22:fd:c1:20 inet addr:204.52.227.12 Bcast:204.52.227.255 Mask:255.255.255.224 inet6 addr: fe80::225:22ff:fefd:c120/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:21482175 errors:0 dropped:0 overruns:0 frame:0 TX packets:40645487 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2750581366 (2.5 GiB) TX bytes:45839132246 (42.6 GiB) Interrupt:83 Base address:0xe000 eth1 Link encap:Ethernet HWaddr 00:25:22:fd:c1:17 inet addr:192.168.1.25 Bcast:192.168.1.255 Mask:255.255.255.252 inet6 addr: fe80::25:2f:fefd:c117/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:193824 errors:0 dropped:0 overruns:0 frame:0 TX packets:318462 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:21038697 (20.0 MiB) TX bytes:148442291 (141.5 MiB) Interrupt:84 Base address:0xa000 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552818&group_id=29880 From noreply at sourceforge.net Wed Aug 1 00:45:46 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 15:45:46 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552819 ] configure hangs in environment without 127.0.0.1 Message-ID: Bugs item #3552819, was opened at 2012-07-31 15:45 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552819&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: configure hangs in environment without 127.0.0.1 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=271 -------------------------------------------------------------------------------- kensington: -------------------------------------------------------------------------------- In an environment without 127.0.0.1 (such as vserver), configure hangs on "checking for ICMP ping syntax...". Attached is a patch from bugs.gentoo.org/{44382,338247}. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552819&group_id=29880 From noreply at sourceforge.net Wed Aug 1 00:48:09 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 15:48:09 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552824 ] NRDP returns the string "Array ()" when you send it invalid Message-ID: Bugs item #3552824, was opened at 2012-07-31 15:48 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552824&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: NRDP returns the string "Array ()" when you send it invalid 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: -------------------------------------------------------------------------------- Shawn Sterling: -------------------------------------------------------------------------------- When I send NRDP bad XML I get the following string returned: Array ( ) -1 BAD XML Expected results: -1 BAD XML It would be best if I didn't send NRDP bad XML in the first place, but that's beside the point. :) PS: NRDP is awesome thanks for making it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552824&group_id=29880 From noreply at sourceforge.net Wed Aug 1 00:50:52 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 15:50:52 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552824 ] NRDP returns the string "Array ()" when you send it invalid Message-ID: Bugs item #3552824, was opened at 2012-07-31 15:48 Message generated for change (Comment added) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552824&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: NRDP returns the string "Array ()" when you send it invalid 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: -------------------------------------------------------------------------------- Shawn Sterling: -------------------------------------------------------------------------------- When I send NRDP bad XML I get the following string returned: Array ( ) -1 BAD XML Expected results: -1 BAD XML It would be best if I didn't send NRDP bad XML in the first place, but that's beside the point. :) PS: NRDP is awesome thanks for making it. ---------------------------------------------------------------------- >Comment By: C?lestyo (calestyo) Date: 2012-07-31 15:50 Message: This used to be: http://tracker.nagios.org/view.php?id=269 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552824&group_id=29880 From noreply at sourceforge.net Wed Aug 1 00:53:51 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 15:53:51 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552828 ] Define source ip for check_ping. Message-ID: Bugs item #3552828, was opened at 2012-07-31 15:53 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552828&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: Define source ip for check_ping. 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=268 -------------------------------------------------------------------------------- bva: -------------------------------------------------------------------------------- There are thousand of inet aliases on same interface on Nagios host. And some of switches which I need to check, accepts ICMP only from certain internal addresses, but default route policy forward packets through wrong gateway. I couldn't change routing and settings on switches. The solution [for me] is to specify the source address for check_ping. Used nagios-plugins-1.4.15 [nagios]> ./check_ping -H 192.168.17.114 -w 3000.0,80% -c 5000.0,100% -p 1 PING CRITICAL - Packet loss = 100%|rta=5000.000000ms;3000.000000;5000.000000;0.000000 pl=100%;80;100;0 [nagios]> [nagios]> route get 192.168.17.114 route to: 192.168.17.114 destination: 192.168.17.112 mask: 255.255.255.252 gateway: cat1 interface: vlan1 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 0 [nagios]> [nagios]> ./check_ping2 -S 192.168.150.3 -H 192.168.17.114 -w 3000.0,80% -c 5000.0,100% -p 1 PING OK - Packet loss = 0%, RTA = 3.67 ms|rta=3.668000ms;3000.000000;5000.000000;0.000000 pl=0%;80;100;0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552828&group_id=29880 From noreply at sourceforge.net Wed Aug 1 00:55:19 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 15:55:19 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552832 ] check_http false alarms Message-ID: Bugs item #3552832, was opened at 2012-07-31 15:55 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552832&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: check_http false alarms 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=267 -------------------------------------------------------------------------------- nbardier: -------------------------------------------------------------------------------- check_http reports socket timeouts ("socket timeout after 30 seconds") against some hosts. Although the problem only happens with those hosts, inmediatly after i get an alarm, i check the URL myself, and it's working. I also tried raising from 10 to 30 seconds the command timeout, with no luck check_http v1.4.15 (nagios-plugins 1.4.15) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552832&group_id=29880 From noreply at sourceforge.net Wed Aug 1 00:58:12 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 15:58:12 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552833 ] check_smtp ignores arguments starting with first (second) no Message-ID: Bugs item #3552833, was opened at 2012-07-31 15:58 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552833&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: check_smtp ignores arguments starting with first (second) no 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=226 -------------------------------------------------------------------------------- qha: -------------------------------------------------------------------------------- check_smtp stops processing arguments on the first non option (or on the second one if hostname is not given with -H or --hostname). This is not particularly helpful, I'd have expected a usage message and return code STATE_UNKNOWN if optind points to remaining arguments after processing options and possibly trying to take hostname from the remaining arguments. Instead I received return code STATE_OK after check_smtp checked only the first message from the server and how soon it arrived ignoring the response checks I'd specified later. In my case I'd been particularly clumsy in defining the services in Nagios but I'm sure this could be triggered by fairly hard to spot mistakes. To reproduce: /usr/lib64/nagios/plugins/check_smtp -H mx.example.com -f nagios at example.com -C rcpt to: no-such-local-part at example.com -R 550 5.1.1 -6 will result in: SMTP OK - 0,125 sec. response time|time=0,124762s;;;0,000000 and return code 0. -------------------------------------------------------------------------------- qha: -------------------------------------------------------------------------------- Apologies for bumping this isssue, but I still haven't seen any message about it on nagiosplug-devel. -------------------------------------------------------------------------------- Inny: -------------------------------------------------------------------------------- Please encapsulate any arguments containing spaces in parentheses, this should resolve your issue. Ex.: ./check_smtp -H mx.example.com -f nagios at example.com -C "rcpt to: no-such-local-part at example.com" -R 550 -6 -------------------------------------------------------------------------------- qha: -------------------------------------------------------------------------------- Yes, that is how I got my service to work the way I intended. This bug is about making check_smtp help me catch such mistakes by flagging them with status unknown instead of ignoring any arguments supplied that it doesn't understand. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552833&group_id=29880 From noreply at sourceforge.net Wed Aug 1 01:00:11 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 16:00:11 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552834 ] check_snmp threshold breaks with negative values Message-ID: Bugs item #3552834, was opened at 2012-07-31 16:00 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552834&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: check_snmp threshold breaks with negative values 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=265 -------------------------------------------------------------------------------- candlerb: -------------------------------------------------------------------------------- The INTEGER type in SNMP is a signed 32-bit value. However check_snmp breaks with negative values. (1) The negative sign is dropped as soon as you apply -w or -c command line flags. # /usr/lib/nagios/plugins/check_snmp -vvv -H 192.168.5.119 -C public -o .1.3.6.1.2.1.25.2.3.1.5.2 /usr/bin/snmpget -t 1 -r 5 -m '' -v 1 [authpriv] 192.168.5.119:161 .1.3.6.1.2.1.25.2.3.1.5.2 iso.3.6.1.2.1.25.2.3.1.5.2 = INTEGER: -632823937 Processing line 1 oidname: iso.3.6.1.2.1.25.2.3.1.5.2 response: = INTEGER: -632823937 SNMP OK - -632823937 | iso.3.6.1.2.1.25.2.3.1.5.2=-632823937 # /usr/lib/nagios/plugins/check_snmp -vvv -H 192.168.5.119 -C public -o .1.3.6.1.2.1.25.2.3.1.5.2 -w 0 /usr/bin/snmpget -t 1 -r 5 -m '' -v 1 [authpriv] 192.168.5.119:161 .1.3.6.1.2.1.25.2.3.1.5.2 iso.3.6.1.2.1.25.2.3.1.5.2 = INTEGER: -632823937 Processing line 1 oidname: iso.3.6.1.2.1.25.2.3.1.5.2 response: = INTEGER: -632823937 SNMP WARNING - *632823937* | iso.3.6.1.2.1.25.2.3.1.5.2=632823937 <<< NOTE! (2) Any threshold with a negative value is rejected as invalid # /usr/lib/nagios/plugins/check_snmp -vvv -H 192.168.5.119 -C public -o .1.3.6.1.2.1.25.2.3.1.5.2 -w -5:-3 Range format incorrect I am guessing problem (1) could be fixed like this: --- a/plugins/check_snmp.c +++ b/plugins/check_snmp.c @@ -401,7 +401,7 @@ main (int argc, char **argv) /* Process this block for numeric comparisons */ /* Make some special values,like Timeticks numeric only if a thr if (thlds[i]->warning || thlds[i]->critical || calculate_rate) { - ptr = strpbrk (show, "0123456789"); + ptr = strpbrk (show, "-0123456789"); if (ptr == NULL) die (STATE_UNKNOWN,_("No valid data returned")); response_value[i] = strtod (ptr, NULL); and that problem (2) could be fixed like this: --- a/lib/utils_base.h +++ b/lib/utils_base.h @@ -62,7 +62,7 @@ int check_range(double, range *); int get_status(double, thresholds *); /* All possible characters in a threshold range */ -#define NP_THRESHOLDS_CHARS "0123456789.:@~" +#define NP_THRESHOLDS_CHARS "-0123456789.:@~" char *np_escaped_string (const char *); -------------------------------------------------------------------------------- candlerb: -------------------------------------------------------------------------------- I have rebuild check_snmp from source, and those two one-line changes do appear to fix the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552834&group_id=29880 From noreply at sourceforge.net Wed Aug 1 01:01:58 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 16:01:58 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552835 ] TLS support lost installing on >= Debian Squeeze distro Message-ID: Bugs item #3552835, was opened at 2012-07-31 16:01 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552835&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: TLS support lost installing on >= Debian Squeeze distro 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=251 -------------------------------------------------------------------------------- VGavara: -------------------------------------------------------------------------------- TLS support is always off installing Nagios Plugins 1.4.15 on Debian Squeeze and more recent releases. Configuration process outputs: ... checking for libgnutls-config... no ... --with-gnutls: no The reason is that Nagios Plugins installation script needs libgnutls-config binary that has been deprecated since Debian Squeeze release, ie, is not being included in the libgnutls-dev package anymore. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552835&group_id=29880 From noreply at sourceforge.net Wed Aug 1 01:03:30 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 16:03:30 -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 (Tracker Item Submitted) made by calestyo 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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552836&group_id=29880 From noreply at sourceforge.net Wed Aug 1 01:06:30 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 16:06:30 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552837 ] check_snmp does not read snmp.conf files Message-ID: Bugs item #3552837, was opened at 2012-07-31 16:06 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552837&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: check_snmp does not read snmp.conf files 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=220 -------------------------------------------------------------------------------- durist: -------------------------------------------------------------------------------- check_snmp does not read snmp.conf files (as the standard UCD-SNMP utilities do), which makes it impossible to use SNMP version 3 without passing the password on the commandline and thus exposing the password in the process table. This is in check_snmp v1.4.14 (nagios-plugins 1.4.14). -------------------------------------------------------------------------------- wyztix: -------------------------------------------------------------------------------- I had to implement this feature off nagios-plugins-1.4.15 since we needed that for our monitoring server. I am unaware of the normal way to provide patches so I attached it to the ticket itself. I left the error validation to the External command. If an invalid etry is provided, we will receive an exit code of 3 and the error message will appear as "External command error: "; This worked on RHEL5 with NET-SNMP 5.3.2.2-9. -------------------------------------------------------------------------------- wyztix: -------------------------------------------------------------------------------- Look like I uploaded the wrong file. The first one (nagios-plugins-1.4.15-snmp_conf.patch) should work for SNMP3. At least, it works on our servers. Yet, I forgot the community string on that first one since we don't use SNMP v2 that much anymore: only for windows. This was solved on the second version: nagios-plugins-1.4.15-snmp_conf_final.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552837&group_id=29880 From noreply at sourceforge.net Wed Aug 1 01:09:31 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 16:09:31 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552838 ] check_procs option -a fails on long command lines due to COL Message-ID: Bugs item #3552838, was opened at 2012-07-31 16:09 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552838&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs option -a fails on long command lines due to COL 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=231 -------------------------------------------------------------------------------- Christoph Probst : -------------------------------------------------------------------------------- To receive a list of processes the check_procs plug-in uses /bin/ps axwo 'stat uid pid ppid vsz rss pcpu etime comm args' ps limits its output in regard to the current value of the environment variable COLUMNS. If COLUMNS is set to a small value and the command line arguments of the process is very long (e.g. >1000 characters for a java command with many properties), a required command line argument (-a option) might not be found. Debugging becomes tricky as the value of COLUMNS depends on the current environment, when NRPE/check_procs is started. If the NRPE Daemon is started by init, the COLUMNS value might be a lot smaller (96 in my case) than if NRPE Daemon is restarted manually using /etc/init.d/nrpe restart. Actually it depends on the current xterm/putty windows size if the check turns green after a manuall restart or not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552838&group_id=29880 From noreply at sourceforge.net Wed Aug 1 01:11:35 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 16:11:35 -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 (Tracker Item Submitted) made by calestyo 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: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552839&group_id=29880 From noreply at sourceforge.net Wed Aug 1 01:12:58 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 16:12:58 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552840 ] check_disk -u bytes incorrect performance data Message-ID: Bugs item #3552840, was opened at 2012-07-31 16:12 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552840&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk -u bytes incorrect performance data 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=219 -------------------------------------------------------------------------------- aayala: -------------------------------------------------------------------------------- Hello I use CentOS release 5.6 (Final) 64 bits, with: check_disk v1.4.15 (nagios-plugins 1.4.15) When i use: check_disk -u bytes -w 20% -c 10% Please NOTE -u bytes return invalid performance data (negative values): DISK OK - free space: / 45387558912 B (96% inode=99%); /boot 221027328 B (91% inode=99%); /dev/shm 525316096 B (100% inode=99%);| /=1714491392B;-2147483648;-2147483648;0;49665605632 /boot=20682752B;229381632;203639915;0;254868480 /dev/shm=0B;472784486;419727560;0;525316096 verbose output: [root@ ~]# /usr/lib64/nagios/plugins/check_disk -u bytes -c 20.1% -w 10% -vvvv Thresholds(pct) for / warn: 10.000000 crit 20.100000 calling stat on / For /, total=12125392, available=11080947, available_to_root=11706815, used=418577, fsp.fsu_files=12517376, fsp.fsu_ffree=12473854 For /, used_pct=4 free_pct=96 used_units=1.71449e+09 free_units=4.53876e+10 total_units=4.96656e+10 used_inodes_pct=1 free_inodes_pct=99 fsp.fsu_blocksize=4096 mult=1 Freespace_units result=0 Freespace% result=0 Usedspace_units result=0 Usedspace_percent result=0 Usedinodes_percent result=0 Freeinodes_percent result=0 Thresholds(pct) for /proc warn: 10.000000 crit 20.100000 calling stat on /proc Thresholds(pct) for /sys warn: 10.000000 crit 20.100000 calling stat on /sys Thresholds(pct) for /dev/pts warn: 10.000000 crit 20.100000 calling stat on /dev/pts Thresholds(pct) for /boot warn: 10.000000 crit 20.100000 calling stat on /boot For /boot, total=248895, available=215847, available_to_root=228697, used=20198, fsp.fsu_files=64256, fsp.fsu_ffree=64215 For /boot, used_pct=9 free_pct=91 used_units=2.06828e+07 free_units=2.21027e+08 total_units=2.54868e+08 used_inodes_pct=1 free_inodes_pct=99 fsp.fsu_blocksize=1024 mult=1 Freespace_units result=0 Freespace% result=0 Usedspace_units result=0 Usedspace_percent result=0 Usedinodes_percent result=0 Freeinodes_percent result=0 Thresholds(pct) for /dev/shm warn: 10.000000 crit 20.100000 calling stat on /dev/shm For /dev/shm, total=128251, available=128251, available_to_root=128251, used=0, fsp.fsu_files=128251, fsp.fsu_ffree=128250 For /dev/shm, used_pct=0 free_pct=100 used_units=0 free_units=5.25316e+08 total_units=5.25316e+08 used_inodes_pct=1 free_inodes_pct=99 fsp.fsu_blocksize=4096 mult=1 Freespace_units result=0 Freespace% result=0 Usedspace_units result=0 Usedspace_percent result=0 Usedinodes_percent result=0 Freeinodes_percent result=0 Thresholds(pct) for /proc/sys/fs/binfmt_misc warn: 10.000000 crit 20.100000 calling stat on /proc/sys/fs/binfmt_misc Thresholds(pct) for /var/lib/nfs/rpc_pipefs warn: 10.000000 crit 20.100000 calling stat on /var/lib/nfs/rpc_pipefs DISK OK - free space: / 45387558912 B (96% inode=99%); /boot 221027328 B (91% inode=99%); /dev/shm 525316096 B (100% inode=99%);| /=1714491392B;-2147483648;-2147483648;0;49665605632 /boot=20682752B;229381632;203639915;0;254868480 /dev/shm=0B;472784486;419727560;0;525316096 and with only one partition: [root@ ~]# /usr/lib64/nagios/plugins/check_disk -u bytes -c 20.1% -w 10% -vvvv -p / calling stat on / Thresholds(pct) for / warn: 10.000000 crit 20.100000 calling stat on / For /, total=12125392, available=11080947, available_to_root=11706815, used=418577, fsp.fsu_files=12517376, fsp.fsu_ffree=12473854 For /, used_pct=4 free_pct=96 used_units=1.71449e+09 free_units=4.53876e+10 total_units=4.96656e+10 used_inodes_pct=1 free_inodes_pct=99 fsp.fsu_blocksize=4096 mult=1 Freespace_units result=0 Freespace% result=0 Usedspace_units result=0 Usedspace_percent result=0 Usedinodes_percent result=0 Freeinodes_percent result=0 DISK OK - free space: / 45387558912 B (96% inode=99%);| /=1714491392B;-2147483648;-2147483648;0;49665605632 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552840&group_id=29880 From noreply at sourceforge.net Wed Aug 1 01:16:40 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 16:16:40 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552845 ] check_disk plugin returns incorrect inode size. Message-ID: Bugs item #3552845, was opened at 2012-07-31 16:16 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552845&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk plugin returns incorrect inode size. 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=25 -------------------------------------------------------------------------------- guest: -------------------------------------------------------------------------------- Using default nagios debian package I get in several servers (same hosting): DISK CRITICAL - free space: / 3051 MB (20% inode=97%) but df -i output is: Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda6 2003424 57648 1945776 3% / Hope It may be useful. Regards. -------------------------------------------------------------------------------- dermoth: -------------------------------------------------------------------------------- I don't see a problem here. 97% free inodes is equivalent to 3% used inodes. What is wrong with that?? Besides for now the official tracker for bugs is on sourceforge, and unless we move it (we might) this one is very unlikely to be checked by developers. -------------------------------------------------------------------------------- foobar47: -------------------------------------------------------------------------------- Hi all, The problem is the following. Nagios send a WARNING cause it see 99% in the result. Morevover, there is enough space disk. DISK WARNING - free space: / 3229 MB (15% inode=99%) -------------------------------------------------------------------------------- dermoth: -------------------------------------------------------------------------------- Doubtful. What is the exact command line that returns this? -------------------------------------------------------------------------------- foobar47: -------------------------------------------------------------------------------- From the local server : /usr/local/nagios/libexec/check_disk -w 20% -c 5% -p /dev/mapper/VolGroup01-u03 DISK WARNING - free space: /u03 21431 MB (17% inode=84%);| /u03=101688MB;103765;123221;0;129707 From nagios server : /usr/local/nagios/libexec/check_nrpe -H 192.168.0.47 -c check_volu03 DISK WARNING - free space: /u03 21431 MB (17% inode=84%);| /u03=101688MB;103765;123221;0;129707 inode show 84% and report a warning... -------------------------------------------------------------------------------- dermoth: -------------------------------------------------------------------------------- So you're telling it to warn when free space is at 20% and alert (critical) at 5%, since you have 17% free space you're well within the warning range and therefore the plugin returns a WARNING. The 84% free inodes has nothing to do with the warning state. This bug is invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552845&group_id=29880 From noreply at sourceforge.net Wed Aug 1 01:17:50 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 16:17:50 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552846 ] memory plugin doesn't account for cached memory Message-ID: Bugs item #3552846, was opened at 2012-07-31 16:17 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552846&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: memory plugin doesn't account for cached memory 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=216 -------------------------------------------------------------------------------- vdanen: -------------------------------------------------------------------------------- keep getting warnings about memory usage on one system (it has 8GB RAM): WARNING - 397 / 7987 MB (4%) Free Memory, Used: 7590 MB, Shared: 0 MB, Buffers: 813 MB, Cached: 5750 MB This looks scary, but on a Linux box this is ok. Cached memory is actually a good thing, so while it is technically accurate, it should account for cached memory. Instead of "Free Memory" it should probably report "Available Memory" in which case it wouldn't be 397MB available but 397MB (free) + 5.7GB (cached) which leaves me with just over 6GB available/usable memory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552846&group_id=29880 From noreply at sourceforge.net Wed Aug 1 01:19:07 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 16:19:07 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552847 ] autodiscovery fping issue Message-ID: Bugs item #3552847, was opened at 2012-07-31 16:19 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552847&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: autodiscovery fping issue 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=212 -------------------------------------------------------------------------------- michaelo: -------------------------------------------------------------------------------- Log extract OUTPUT: /usr/local/nagiosxi/html/includes/components/autodiscovery/jobs/4mout7.xml WATCH: /usr/local/nagiosxi/html/includes/components/autodiscovery/jobs/4mout7.watch FPING CMD: /usr/sbin/fping -a -r 1 -g 10.72.14.128/25 2> /dev/null ALIVE: Array ( [0] => 10.72.14.128 [<- 10.72.8.196] [1] => 10.72.14.129 [2] => 10.72.14.130 [3] => 10.72.14.131 [4] => 10.72.14.140 [5] => 10.72.14.141 [6] => 10.72.14.142 [7] => 10.72.14.143 [8] => 10.72.14.255 [<- 10.72.8.196] ) the parse fails because of the [<- 10.72.8.196] returned by fping the net result is the autodiscovery does not work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552847&group_id=29880 From noreply at sourceforge.net Wed Aug 1 01:20:29 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 16:20:29 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552848 ] check_http plugin does not handle HTTP host header properly Message-ID: Bugs item #3552848, was opened at 2012-07-31 16:20 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552848&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: check_http plugin does not handle HTTP host header properly 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=211 -------------------------------------------------------------------------------- jmalone: -------------------------------------------------------------------------------- The check_http plugin sends the "-H" argument as the HTTP host header even when a "-u" url argument is given; the latter is more correct I believe. My patch seems to correct the issue on my installation, but my C code may not be optimal. Patch is against nagios-plugins-1.4.15. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552848&group_id=29880 From noreply at sourceforge.net Wed Aug 1 01:23:09 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 16:23:09 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552849 ] check_disk confused by LOFS mounts Message-ID: Bugs item #3552849, was opened at 2012-07-31 16:23 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552849&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk confused by LOFS mounts 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=186 -------------------------------------------------------------------------------- morven: -------------------------------------------------------------------------------- check_disk takes a path with the -p option that can be either a filesystem mount path OR a device. It assumes that if it can find it in the mounted filesystems as the source of a filesystem, it's a device path, otherwise it's a mountpoint. This is broken by LOFS on Solaris. LOFS (loopback file system) puts the source directory of the loopback as its device. Thus, the LOFS mount is chosen over the real filesystem. This wouldn't be a real problem normally, since the usage statistics for the loopback mount are the same as the real filesystem underneath. However, if the LOFS mount is made in a child zone, non-root processes in the parent global zone cannot statvfs() it, and the checks fail. It would be nice to have a flag that forces interpretation as one or the other, or for the code to fall back to the alternate interpretation if the statvfs() fails, or for the code to check mnttab to see if the path is also a mount point before deciding to use the path as the device entry. -------------------------------------------------------------------------------- jedblack: -------------------------------------------------------------------------------- add me to the list -- i'm having the same issue. We have Solaris global zone and a few sparse-root zones within it. Solaris 10 global with a few spart-root zones. here is the grep for /usr on the /etc/mnttab bash-3.00# cat /etc/mnttab |grep -i usr /dev/dsk/c0t2d0s4 /usr ufs rw,intr,largefiles,logging,xattr,onerror=panic,dev=d80144 1283285554 /usr/lib/libc/libc_hwcap2.so.1 /lib/libc.so.1 lofs dev=d80144 1283285553 /usr /zones/www/root/usr lofs ro,nodevices,nosub,dev=d80144 1283285653 /zones/www/root/usr/lib/libc/libc_hwcap2.so.1 /zones/www/root/lib/libc.so.1 lofs zone=www-zone,dev=d80144 1283285657 /usr /zones/k2proc/root/usr lofs ro,nodevices,nosub,dev=d80144 1283286256 /zones/k2proc/root/usr/lib/libc/libc_hwcap2.so.1 /zones/k2proc/root/lib/libc.so.1 lofs zone=k2proc,dev=d80144 1283286258 bash-3.00# ------------------------------------ And here is a df -h.... /dev/dsk/c0t2d0s0 3.9G 380M 3.5G 10% / /devices 0K 0K 0K 0% /devices ctfs 0K 0K 0K 0% /system/contract proc 0K 0K 0K 0% /proc mnttab 0K 0K 0K 0% /etc/mnttab swap 4.5G 564K 4.5G 1% /etc/svc/volatile objfs 0K 0K 0K 0% /system/object /dev/dsk/c0t2d0s4 3.9G 781M 3.1G 20% /usr /usr/lib/libc/libc_hwcap2.so.1 3.9G 781M 3.1G 20% /lib/libc.so.1 fd 0K 0K 0K 0% /dev/fd /dev/dsk/c0t2d0s5 3.9G 2.6G 1.3G 68% /var swap 4.5G 48K 4.5G 1% /tmp swap 4.5G 24K 4.5G 1% /var/run /dev/dsk/c0t3d0s1 56G 154M 55G 1% /weblogs /dev/dsk/c0t2d0s7 42G 12G 29G 29% /zones /dev/dsk/c0t2d0s6 9.9G 1012M 8.8G 11% /export/home -bash-3.00$ now if I try to run "check_disk" as user 'nagios' on the solaris global, checking ' /usr ' -bash-3.00$ ./check_disk -w 10% -c 5% -v -p /usr DISK CRITICAL - free space: /zones/k2proc/root/usr 8741023416033 MB (0% inode=-208431361588%);| /zones/k2proc/root/usr=-2147483648MB;-2147483648;-2147483648;0;-2147483648 -bash-3.00$ Dong a Truss on the check_disk command , it seem like statvfs64() is getting confused by the LOFS as Morven pointed out... stat64("/usr", 0x08079878) = 0 sysconfig(_CONFIG_PAGESIZE) = 4096 stat64("/usr", 0x08079878) = 0 statvfs64("/zones/k2proc/root/usr", 0x08047B50) Err#13 EACCES [file_dac_search] ioctl(1, TCGETA, 0x08046F74) = 0 fstat64(1, 0x08046EE0) = 0 DISK CRITICAL - free space: /zones/k2proc/root/usr 8741023416033 MB (0% inode=-208431361588%);| /zones/k2proc/root/usr=-2147483648MB;-2147483648;-2147483648;0;-2147483648 write(1, " D I S K C R I T I C A".., 171) = 171 _exit(2) -bash-3.00$ --------------------------------------- However, if i check ' /usr/ ' (note: the trailing forward slash), it seem to work fine. -bash-3.00$ ./check_disk -w 10% -c 5% -v -p /usr/ DISK OK - free space: /usr 3218 MB (80% inode=92%);| /usr=780MB;3636;3838;0;4040 -bash-3.00$ stat64("/usr/", 0x08079878) = 0 sysconfig(_CONFIG_PAGESIZE) = 4096 stat64("/usr/", 0x08079878) = 0 statvfs64("/usr", 0x08047B50) = 0 ioctl(1, TCGETA, 0x08046F74) = 0 fstat64(1, 0x08046EE0) = 0 DISK OK - free space: /usr 3218 MB (80% inode=92%);| /usr=780MB;3636;3838;0;4040 write(1, " D I S K O K - f r".., 81) = 81 _exit(0) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552849&group_id=29880 From noreply at sourceforge.net Wed Aug 1 01:25:09 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 16:25:09 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552853 ] Warn when check_command argument is passed but the definitio Message-ID: Bugs item #3552853, was opened at 2012-07-31 16:25 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552853&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: Warn when check_command argument is passed but the definitio 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=167 -------------------------------------------------------------------------------- candlerb: -------------------------------------------------------------------------------- I propose that a warning is issued when parsing the config, if a check_command is invoked with arguments, but the command definition does not make use of those arguments. Example: (This issue came up when using Ubuntu/Debian package of nagios 3.2.0) The nagios documentation shows that if you want to monitor a different URI path, you use something like this: check_command check_http!-u /myapp/ However, the Debianized configs define check_http in /etc/nagios-plugins/config/http.cfg as: # 'check_http' command definition define command{ command_name check_http command_line /usr/lib/nagios/plugins/check_http -H '$HOSTADDRESS$' -I '$HOSTADDRESS$' } Note that there is no $ARG1$. This means that if you provide arguments to check_http!.... they are accepted but silently ignored. As a result, you may think you are monitoring a different uri path / port etc, but actually you are monitoring the server root. You may not discover this until the app dies and Nagios doesn't alert :-( Furthermore: View Config > Services shows the arguments, leading to a further false sense of security. "Debian Always Knows Best" But this is a circumstance in which a warning is arguably useful in general. Suggested wording: Warning: Extra arguments passed to service check command 'check_http' specified in service 'NAGIOS' will be ignored (or maybe it should be an Error?) As a bonus, it would be useful to report the file where the command was defined. This is because the fragmented Debian config doesn't include the 'define command' sections under /etc/nagios3/conf.d where you'd expect them, so you have to go hunting. Again, you can hardly blame nagios for this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552853&group_id=29880 From noreply at sourceforge.net Wed Aug 1 01:26:59 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 16:26:59 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552854 ] HTTP check does not allow -f follow and -e * t be used toget Message-ID: Bugs item #3552854, was opened at 2012-07-31 16:26 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552854&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: HTTP check does not allow -f follow and -e * t be used toget 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=161 -------------------------------------------------------------------------------- sarts: -------------------------------------------------------------------------------- check_http -H host -f follow -e {something} prevents check_http from following redirects. Or, in other words. check_http -H host -f follow only accepts an end-point return-code of 200 OK. When a url redirects from http to https (or from / to /some-app), and then expects a login. This URI can not be checked with the nagios check_http plugin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552854&group_id=29880 From noreply at sourceforge.net Wed Aug 1 01:28:16 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 16:28:16 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552858 ] Add support for monitoring jabber server-to-server connectiv Message-ID: Bugs item #3552858, was opened at 2012-07-31 16:28 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552858&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for monitoring jabber server-to-server connectiv 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=157 -------------------------------------------------------------------------------- Xelnor: -------------------------------------------------------------------------------- Besides the current check_jabber plugin, which checks whether a given XMPP server is running correctly, would it be possible to add a "check_jabbers2s" plugin to check whether the server to server part is running too ? I have attached a patch to check_tcp.c for enabling this (based on nagios-plugins-1.4.14) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552858&group_id=29880 From noreply at sourceforge.net Wed Aug 1 01:30:01 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 16:30:01 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552859 ] SELinux is preventing ping (ping_t) "read write" Message-ID: Bugs item #3552859, was opened at 2012-07-31 16:30 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552859&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: SELinux is preventing ping (ping_t) "read write" 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=117 -------------------------------------------------------------------------------- tonvoon: -------------------------------------------------------------------------------- Errors in /var/log/messages: Dec 10 15:50:12 hostname setroubleshoot: SELinux is preventing ping (ping_t) "read write" to /usr/local/nagios/var/spool/checkresults/checkt30dqT (usr_t). For complete SELinux messages. run sealert -l 0d9dbc11-44d8-49bd-a42a-c350a082fd48 The fix suggested by sealert does not fix the problem since the file name is random. Changing the security context of the directory does not work either. Proposed solution: Add to Nagios policy file: require { type usr_t; type ping_t; class file { read write }; } #============= ping_t ============== allow ping_t usr_t:file { read write }; Also see: http://blog.pas.net.au/2009/05/fighting-with-selinux-and-nagios/ -------------------------------------------------------------------------------- ageric: -------------------------------------------------------------------------------- The blog linked to talks about /bin/ping and some ping_t selinux policy stuff, so this must be plugin-related. Originally, this bug was posted in "Nagios Core", but the core never has and never will ship an SELinux policy file. If the plugins project doesn't either, I suggest just closing it with "won't fix" and ask the reporter to re-file the bug with his distribution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552859&group_id=29880 From noreply at sourceforge.net Wed Aug 1 01:31:35 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 16:31:35 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552860 ] check_dns plugin doesn't output correct the results Message-ID: Bugs item #3552860, was opened at 2012-07-31 16:31 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552860&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: check_dns plugin doesn't output correct the results 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=135 -------------------------------------------------------------------------------- Constantin007: -------------------------------------------------------------------------------- I guess there are 2 issues: 1. The resolved IP addresses are not returned when the plugin is run with -s option on some DNS servers: #./check_dns -H www.google.com -s 192.228.79.201 (<-rood DNS Server) DNS OK: 0.201 seconds response time. www.google.com returns |time=0.200703s;;;0.000000 When using other local DNS: #./check_dns -H www.google.com -s 192.168.115.5 #DNS OK: 0.065 seconds response time. www.google.com returns 74.125.87.103,74.125.87.104,74.125.87.105,74.125.87.106,74.125.87.147,74.125.87.99|time=0.064952s;;;0.000000 2. The warning & critical thresholds are not reflected in the output performance: #./check_dns -H www.google.com -s 192.228.79.201 -w 10 -c 20 DNS OK: 0.213 seconds response time. www.google.com returns |time=0.212656s;;;0.000000 #./check_dns -H www.google.com -s 192.168.115.5 -w 10 -c 20 DNS OK: 0.020 seconds response time. www.google.com returns 74.125.87.103,74.125.87.104,74.125.87.105,74.125.87.106,74.125.87.147,74.125.87.99|time=0.019878s;;;0.000000 Could you please investigate this? ./check_dns -h check_dns v1.4.14 (nagios-plugins 1.4.14) Copyright (c) 1999 Ethan Galstad Copyright (c) 2000-2008 Nagios Plugin Development Team ./nagios --help Nagios Core 3.2.0 Copyright (c) 2009 Nagios Core Development Team and Community Contributors Copyright (c) 1999-2009 Ethan Galstad Last Modified: 08-12-2009 License: GPL ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552860&group_id=29880 From noreply at sourceforge.net Wed Aug 1 01:32:46 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 16:32:46 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552861 ] check_nt incorrectly calculates percentage values leading to Message-ID: Bugs item #3552861, was opened at 2012-07-31 16:32 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552861&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: check_nt incorrectly calculates percentage values leading to 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=126 -------------------------------------------------------------------------------- mmelin: -------------------------------------------------------------------------------- This problem was discovered and reproduced when using check_nt against a NSClient++ 0.3.7.493 2009-10-12 checking drive size with USEDDISKSPACE. When given "-w 98% -c 99%" as WARNING/CRITICAL values, check_nt will not return CRITICAL when disk usage transitions from 98% usage to 99% usage. This was reproduced and verifed by creating a RAM disk 8 MB in size, then filling it with garbage data to only have 64K bytes free. At the time of testing, this was the drive statistics as reported by Windows Explorer: 8192512 bytes total size 65536 bytes free 65536 / 8192512 = 0.0079 = 7.9% First, verification that the Nagios host sees the correct disk and values by using check_nrpe and this NRPE Handler: USEDDISKSPACE=inject CheckDriveSize ShowAll=long Drive=E:\ MaxWarn=98% MaxCrit=99% As expected the output is this: root at support-mon-gbg:~# /opt/plugins/check_nrpe -H 172.16.141.179 -c USEDDISKSPACE CRITICAL: E:\: Total: 7.81M - Used: 7.75M (99%) - Free: 64K (1%) > critical|'E:\'=99%;98;99; root at support-mon-gbg:~# echo $? 2 Now for the fun part. check_nt with 99% critical: root at support-mon-gbg:~# /opt/plugins/check_nt -H 172.16.141.179 -p 1248 -v USEDDISKSPACE -l E -w 98% -c 99% E:\ - total: 0.01 Gb - used: 0.01 Gb (99%) - free 0.00 Gb (1%) | 'E:\ Used Space'=0.01Gb;0.01;0.01;0.00;0.01 root at support-mon-gbg:~# echo $? 1 check_nt with 98.99% critical: root at support-mon-gbg:~# /opt/plugins/check_nt -H 172.16.141.179 -p 1248 -v USEDDISKSPACE -l E -w 98% -c 98.99% E:\ - total: 0.01 Gb - used: 0.01 Gb (99%) - free 0.00 Gb (1%) | 'E:\ Used Space'=0.01Gb;0.01;0.01;0.00;0.01 root at support-mon-gbg:~# echo $? 2 -- Workaround is to use check_nrpe with CheckDriveSize. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552861&group_id=29880 From noreply at sourceforge.net Wed Aug 1 01:34:26 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 16:34:26 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552862 ] add --with-lmstat-command to configure Message-ID: Bugs item #3552862, was opened at 2012-07-31 16:34 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552862&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: add --with-lmstat-command to configure 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=122 -------------------------------------------------------------------------------- authority: -------------------------------------------------------------------------------- Just upgraded nagios-plugins to 1.4.14. The configure script has numerous options for specifying the location of various commands that may be used by the plugins. The check_flexlm script makes use of the lmstat binary, specified in the utils.pm library, but the value is empty, which caused some minor breakage during my upgrade. It appears that @PATH_TO_LMSTAT@ is a macro that could be used to expand to the correct value if the path to lmstat was supplied or automatically detected. I don't expect any sort of logic could find the lmstat binary on my system (and it's not in my build user's path), so some means of supplying the value should be added, presumably during the configure. [nagios at enigma nagios-plugins-1.4.14]$ grep -R PATH_TO_LMSTAT * config.h:/* #undef PATH_TO_LMSTAT */ config.h.in:#undef PATH_TO_LMSTAT config.log:PATH_TO_LMSTAT='' config.status:s, at PATH_TO_LMSTAT@,|#_!!_#|,g configure:PATH_TO_LMSTAT configure:if test "${ac_cv_path_PATH_TO_LMSTAT+set}" = set; then configure: case $PATH_TO_LMSTAT in configure: ac_cv_path_PATH_TO_LMSTAT="$PATH_TO_LMSTAT" # Let the user override the test with a path. configure: ac_cv_path_PATH_TO_LMSTAT="$as_dir/$ac_word$ac_exec_ext" configure:PATH_TO_LMSTAT=$ac_cv_path_PATH_TO_LMSTAT configure:if test -n "$PATH_TO_LMSTAT"; then configure: { echo "$as_me:$LINENO: result: $PATH_TO_LMSTAT" >&5 configure:echo "${ECHO_T}$PATH_TO_LMSTAT" >&6; } configure:if test -x "$PATH_TO_LMSTAT" configure:#define PATH_TO_LMSTAT "$PATH_TO_LMSTAT" configure:PATH_TO_LMSTAT!$PATH_TO_LMSTAT$ac_delim configure.in:AC_PATH_PROG(PATH_TO_LMSTAT,lmstat) configure.in:if test -x "$PATH_TO_LMSTAT" configure.in: AC_DEFINE_UNQUOTED(PATH_TO_LMSTAT,"$PATH_TO_LMSTAT",[path to lmstat]) gl/Makefile.in:PATH_TO_LMSTAT = @PATH_TO_LMSTAT@ gl/Makefile:PATH_TO_LMSTAT = lib/Makefile.in:PATH_TO_LMSTAT = @PATH_TO_LMSTAT@ lib/tests/Makefile.in:PATH_TO_LMSTAT = @PATH_TO_LMSTAT@ lib/tests/Makefile:PATH_TO_LMSTAT = lib/Makefile:PATH_TO_LMSTAT = Makefile:PATH_TO_LMSTAT = Makefile.in:PATH_TO_LMSTAT = @PATH_TO_LMSTAT@ perlmods/Makefile.in:PATH_TO_LMSTAT = @PATH_TO_LMSTAT@ perlmods/Makefile:PATH_TO_LMSTAT = plugins/Makefile.in:PATH_TO_LMSTAT = @PATH_TO_LMSTAT@ plugins/Makefile:PATH_TO_LMSTAT = plugins-root/Makefile.in:PATH_TO_LMSTAT = @PATH_TO_LMSTAT@ plugins-root/Makefile:PATH_TO_LMSTAT = plugins-scripts/Makefile.in:PATH_TO_LMSTAT = @PATH_TO_LMSTAT@ plugins-scripts/utils.pm.in:$PATH_TO_LMSTAT = "@PATH_TO_LMSTAT@" ; plugins-scripts/check_flexlm.pl:my $lmstat = $utils::PATH_TO_LMSTAT ; plugins-scripts/Makefile:PATH_TO_LMSTAT = plugins-scripts/utils.pm:$PATH_TO_LMSTAT = "" ; plugins-scripts/check_flexlm:my $lmstat = $utils::PATH_TO_LMSTAT ; tap/Makefile.in:PATH_TO_LMSTAT = @PATH_TO_LMSTAT@ tap/Makefile:PATH_TO_LMSTAT = ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552862&group_id=29880 From noreply at sourceforge.net Wed Aug 1 02:54:31 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jul 2012 17:54:31 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552882 ] check_ntp_time and check_ntp return just first offset Message-ID: Bugs item #3552882, was opened at 2012-07-31 17:54 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552882&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: snapshot tarball Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: check_ntp_time and check_ntp return just first offset Initial Comment: Both check_ntp_time and check_ntp return just first measured offset, instead of wanted average of four measurements. There is used bad index j (equeal to 0) instead of correct index i in avg_offset loop: for(i=0; i Bugs item #3552848, was opened at 2012-07-31 16:20 Message generated for change (Comment added) made by j-bern You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552848&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: check_http plugin does not handle HTTP host header properly 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=211 -------------------------------------------------------------------------------- jmalone: -------------------------------------------------------------------------------- The check_http plugin sends the "-H" argument as the HTTP host header even when a "-u" url argument is given; the latter is more correct I believe. My patch seems to correct the issue on my installation, but my C code may not be optimal. Patch is against nagios-plugins-1.4.15. ---------------------------------------------------------------------- Comment By: J. Bern (j-bern) Date: 2012-08-01 09:10 Message: Clarification: In the normal scenario (direct connection to webserver), the -u parameter is *not meant* to include more than the *path* part of the URL, in spite of the naming. (Proof: There are several places in check_http.c where the *actual* URL gets reconstructed from method, hostname/address, port, and the server_url variable in question here.) However, when the plugin talks to a *proxy*, -u needs to state the entire method/host/port/path assembly, referring to the actual webserver. Having that said, both RFC 2616 section 14.23 and a quick packet sniff on a productive proxy indicate that in the latter scenario, the Host: header shall and does indicate the actual server, *not* the proxy. Given that -H normally is used to indicate the host that the plugin shall connect to (i.e., the proxy), I'd say that the patch does have merit as a means to prevent confusion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552848&group_id=29880 From noreply at sourceforge.net Wed Aug 1 18:19:18 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Aug 2012 09:19:18 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552846 ] memory plugin doesn't account for cached memory Message-ID: Bugs item #3552846, was opened at 2012-07-31 16:17 Message generated for change (Comment added) made by j-bern You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552846&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: memory plugin doesn't account for cached memory 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=216 -------------------------------------------------------------------------------- vdanen: -------------------------------------------------------------------------------- keep getting warnings about memory usage on one system (it has 8GB RAM): WARNING - 397 / 7987 MB (4%) Free Memory, Used: 7590 MB, Shared: 0 MB, Buffers: 813 MB, Cached: 5750 MB This looks scary, but on a Linux box this is ok. Cached memory is actually a good thing, so while it is technically accurate, it should account for cached memory. Instead of "Free Memory" it should probably report "Available Memory" in which case it wouldn't be 397MB available but 397MB (free) + 5.7GB (cached) which leaves me with just over 6GB available/usable memory. ---------------------------------------------------------------------- Comment By: J. Bern (j-bern) Date: 2012-08-01 09:19 Message: Unfortunately, things aren't *quite* that simple. While free RAM can be used immediately and without repercussions, cannibalizing the disk cache *does* have impact on system performance (namely, increased disk I/O, duh), including the potential to stop the machine dead in its tracks when the cache reaches zero. Also, when asked to provide more RAM to a process, the kernel will actually decide whether to use ex-disk cache, or swapspace, based on the system's "swappiness" settings. Hence, for "the full picture", you'ld need to include swapspace figures as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552846&group_id=29880 From noreply at sourceforge.net Wed Aug 1 18:38:05 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Aug 2012 09:38:05 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552828 ] Define source ip for check_ping. Message-ID: Bugs item #3552828, was opened at 2012-07-31 15:53 Message generated for change (Comment added) made by j-bern You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552828&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: Define source ip for check_ping. 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=268 -------------------------------------------------------------------------------- bva: -------------------------------------------------------------------------------- There are thousand of inet aliases on same interface on Nagios host. And some of switches which I need to check, accepts ICMP only from certain internal addresses, but default route policy forward packets through wrong gateway. I couldn't change routing and settings on switches. The solution [for me] is to specify the source address for check_ping. Used nagios-plugins-1.4.15 [nagios]> ./check_ping -H 192.168.17.114 -w 3000.0,80% -c 5000.0,100% -p 1 PING CRITICAL - Packet loss = 100%|rta=5000.000000ms;3000.000000;5000.000000;0.000000 pl=100%;80;100;0 [nagios]> [nagios]> route get 192.168.17.114 route to: 192.168.17.114 destination: 192.168.17.112 mask: 255.255.255.252 gateway: cat1 interface: vlan1 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 0 [nagios]> [nagios]> ./check_ping2 -S 192.168.150.3 -H 192.168.17.114 -w 3000.0,80% -c 5000.0,100% -p 1 PING OK - Packet loss = 0%, RTA = 3.67 ms|rta=3.668000ms;3000.000000;5000.000000;0.000000 pl=0%;80;100;0 ---------------------------------------------------------------------- Comment By: J. Bern (j-bern) Date: 2012-08-01 09:38 Message: This approach uses a dubitable feature of the underlying "ping" command (which is absent from, e.g., fping) to work around the lack of access to the routing config (or, for that matter, iptables SNAT) to solve the *actual* problem. As soon as the switches need to be monitored, say, via SNMP, it'll reappear with a vengeance. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552828&group_id=29880 From casper at meteor.dp.ua Wed Aug 1 18:52:13 2012 From: casper at meteor.dp.ua (=?koi8-r?Q?=F0=CF=CB=CF=D4=C9=CC=C5=CE=CB=CF_?= =?koi8-r?Q?=EB=CF=CE=D3=D4=C1=CE=D4=C9=CE_?= =?koi8-r?Q?=E1=CC=C5=CB=D3=C1=CE=C4=D2=CF=D7=C9?= =?koi8-r?Q?=DE?=) Date: Wed, 01 Aug 2012 19:52:13 +0300 Subject: [Nagiosplug-devel] contribution Message-ID: <1343839933.3219.34.camel@fincasper> Hi, I have some enchantments to standard nagios-plugins. What is the way to make them included mainstream? First of all I would like to start from: http://exchange.nagios.org/directory/Plugins/Operating-Systems/Linux/check_procs_perf/details I'm not familiar with autoconf/configure way of keeping projects, so I was unable to actually make a patch. It is just modified version of check_proc.c I also have check_mysql clone with support for multi column and multi row queries with perf data. It utilizes zlib compression of arguments to somehow overcome nrpe outgoing packet size for long queries and base64 encoding for support for spaces and other illegal characters. From noreply at sourceforge.net Thu Aug 2 09:08:54 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Aug 2012 00:08:54 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552845 ] check_disk plugin returns incorrect inode size. Message-ID: Bugs item #3552845, was opened at 2012-07-31 16:16 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552845&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: Invalid Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk plugin returns incorrect inode size. 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=25 -------------------------------------------------------------------------------- guest: -------------------------------------------------------------------------------- Using default nagios debian package I get in several servers (same hosting): DISK CRITICAL - free space: / 3051 MB (20% inode=97%) but df -i output is: Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda6 2003424 57648 1945776 3% / Hope It may be useful. Regards. -------------------------------------------------------------------------------- dermoth: -------------------------------------------------------------------------------- I don't see a problem here. 97% free inodes is equivalent to 3% used inodes. What is wrong with that?? Besides for now the official tracker for bugs is on sourceforge, and unless we move it (we might) this one is very unlikely to be checked by developers. -------------------------------------------------------------------------------- foobar47: -------------------------------------------------------------------------------- Hi all, The problem is the following. Nagios send a WARNING cause it see 99% in the result. Morevover, there is enough space disk. DISK WARNING - free space: / 3229 MB (15% inode=99%) -------------------------------------------------------------------------------- dermoth: -------------------------------------------------------------------------------- Doubtful. What is the exact command line that returns this? -------------------------------------------------------------------------------- foobar47: -------------------------------------------------------------------------------- From the local server : /usr/local/nagios/libexec/check_disk -w 20% -c 5% -p /dev/mapper/VolGroup01-u03 DISK WARNING - free space: /u03 21431 MB (17% inode=84%);| /u03=101688MB;103765;123221;0;129707 From nagios server : /usr/local/nagios/libexec/check_nrpe -H 192.168.0.47 -c check_volu03 DISK WARNING - free space: /u03 21431 MB (17% inode=84%);| /u03=101688MB;103765;123221;0;129707 inode show 84% and report a warning... -------------------------------------------------------------------------------- dermoth: -------------------------------------------------------------------------------- So you're telling it to warn when free space is at 20% and alert (critical) at 5%, since you have 17% free space you're well within the warning range and therefore the plugin returns a WARNING. The 84% free inodes has nothing to do with the warning state. This bug is invalid. ---------------------------------------------------------------------- >Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2012-08-02 00:08 Message: I'm not sure why you "forwarded" it, this bug was and is still invalid. Unless of course if you can prove mathematically that 97% free isn't the same as 3% used, and that 17% is more than 20%. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552845&group_id=29880 From noreply at sourceforge.net Thu Aug 2 13:58:59 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Aug 2012 04:58:59 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552845 ] check_disk plugin returns incorrect inode size. Message-ID: Bugs item #3552845, was opened at 2012-07-31 16:16 Message generated for change (Comment added) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552845&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: Invalid Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk plugin returns incorrect inode size. 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=25 -------------------------------------------------------------------------------- guest: -------------------------------------------------------------------------------- Using default nagios debian package I get in several servers (same hosting): DISK CRITICAL - free space: / 3051 MB (20% inode=97%) but df -i output is: Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda6 2003424 57648 1945776 3% / Hope It may be useful. Regards. -------------------------------------------------------------------------------- dermoth: -------------------------------------------------------------------------------- I don't see a problem here. 97% free inodes is equivalent to 3% used inodes. What is wrong with that?? Besides for now the official tracker for bugs is on sourceforge, and unless we move it (we might) this one is very unlikely to be checked by developers. -------------------------------------------------------------------------------- foobar47: -------------------------------------------------------------------------------- Hi all, The problem is the following. Nagios send a WARNING cause it see 99% in the result. Morevover, there is enough space disk. DISK WARNING - free space: / 3229 MB (15% inode=99%) -------------------------------------------------------------------------------- dermoth: -------------------------------------------------------------------------------- Doubtful. What is the exact command line that returns this? -------------------------------------------------------------------------------- foobar47: -------------------------------------------------------------------------------- From the local server : /usr/local/nagios/libexec/check_disk -w 20% -c 5% -p /dev/mapper/VolGroup01-u03 DISK WARNING - free space: /u03 21431 MB (17% inode=84%);| /u03=101688MB;103765;123221;0;129707 >From nagios server : /usr/local/nagios/libexec/check_nrpe -H 192.168.0.47 -c check_volu03 DISK WARNING - free space: /u03 21431 MB (17% inode=84%);| /u03=101688MB;103765;123221;0;129707 inode show 84% and report a warning... -------------------------------------------------------------------------------- dermoth: -------------------------------------------------------------------------------- So you're telling it to warn when free space is at 20% and alert (critical) at 5%, since you have 17% free space you're well within the warning range and therefore the plugin returns a WARNING. The 84% free inodes has nothing to do with the warning state. This bug is invalid. ---------------------------------------------------------------------- Comment By: C?lestyo (calestyo) Date: 2012-08-02 04:58 Message: Forwarding the bugs (all of them which were still marked as open) was already quite some work which took several hours... I haven't read any of their contents and/or checked their validity. :) Cheers. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2012-08-02 00:08 Message: I'm not sure why you "forwarded" it, this bug was and is still invalid. Unless of course if you can prove mathematically that 97% free isn't the same as 3% used, and that 17% is more than 20%. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552845&group_id=29880 From reply+i-6022940-a95fd34046c605243d188d57ff5ac4a1e91a5e82-1651316 at reply.github.com Fri Aug 3 22:18:45 2012 From: reply+i-6022940-a95fd34046c605243d188d57ff5ac4a1e91a5e82-1651316 at reply.github.com (Tim Laszlo) Date: Fri, 3 Aug 2012 13:18:45 -0700 Subject: [Nagiosplug-devel] [nagios-plugins] This add performance data for mysql slave checks (#14) Message-ID: ... behind master You can merge this Pull Request by running: git pull https://github.com/timl/nagios-plugins master Or you can view, comment on it, or merge it online at: https://github.com/nagios-plugins/nagios-plugins/pull/14 -- Commit Summary -- * check_mysql: when checking slave thread add performance data for seconds behind master -- File Changes -- M plugins/check_mysql.c (20) -- Patch Links -- https://github.com/nagios-plugins/nagios-plugins/pull/14.patch https://github.com/nagios-plugins/nagios-plugins/pull/14.diff --- Reply to this email directly or view it on GitHub: https://github.com/nagios-plugins/nagios-plugins/pull/14 From noreply at sourceforge.net Fri Aug 10 14:39:48 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Aug 2012 05:39:48 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3556040 ] check_smtp error when combining -S and -e Message-ID: Bugs item #3556040, was opened at 2012-08-10 05:39 Message generated for change (Tracker Item Submitted) made by lgarrett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3556040&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: CVS Status: Open Resolution: None Priority: 5 Private: No Submitted By: lgarrett (lgarrett) Assigned to: Nobody/Anonymous (nobody) Summary: check_smtp error when combining -S and -e Initial Comment: Hi, tested with git checkout as of today: $ ./check_smtp -S -H mail.programmfabrik.de -e "220 mail.berlin.programmfabrik.de ESMTP Postfix (Debian/GNU)" -p 25 -D 30 -v HELOCMD: EHLO mycomputer 220 mail.berlin.programmfabrik.de ESMTP Postfix (Debian/GNU) Server does not support STARTTLS sent QUIT ^C In fact, our SMTP server does support STARTTLS, as shown here: $ ./check_smtp -S -H mail.programmfabrik.de -p 25 -D 30 -v HELOCMD: EHLO lgarrett-Inspiron-531 220 mail.berlin.programmfabrik.de ESMTP Postfix (Debian/GNU) sent EHLO mycomputer 250-mail.berlin.programmfabrik.de 250-PIPELINING 250-SIZE 157286400 250-VRFY 250-ETRN 250-AUTH DIGEST-MD5 PLAIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN sent QUIT received 221 2.0.0 Bye SMTP OK - 0.027 sec. response time, 221 2.0.0 Bye |time=0.027238s;;;0.000000 Running check_smtp in gdb showed me the following: $ gdb --args ./check_smtp -S -H mail.programmfabrik.de -e "220 mail.berlin.programmfabrik.de ESMTP Postfix (Debian/GNU)" -p 25 -D 30 -v GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /scratch/nagios/nagios-plugins/plugins/check_smtp...done. (gdb) b 235 Breakpoint 1 at 0x403e4f: file check_smtp.c, line 235. (gdb) run Starting program: /scratch/nagios/nagios-plugins/plugins/check_smtp -S -H mail.programmfabrik.de -e 220\ mail.berlin.programmfabrik.de\ ESMTP\ Postfix\ \(Debian/GNU\) -p 25 -D 30 -v [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". HELOCMD: EHLO mycomputer 220 mail.berlin.programmfabrik.de ESMTP Postfix (Debian/GNU) Breakpoint 1, main (argc=, argv=) at check_smtp.c:235 235 printf (_("Server does not support STARTTLS\n")); (gdb) print buffer $1 = "220 2.0.0 Ready to start TLS\r\n\000de\r\n250-PIPELINING\r\n250-SIZE 157286400\r\n250-VRFY\r\n250-ETRN\r\n250-STARTTLS\r\n250-AUTH DIGEST-MD5 PLAIN\r\n250-ENHANCEDSTATUSCODES\r\n250-8BITMIME\r\n250 DSN\r\n", '\000' (gdb) print server_expect $2 = 0x7fffffffe12e "220 mail.berlin.programmfabrik.de ESMTP Postfix (Debian/GNU)" (gdb) q A debugging session is active. Inferior 1 [process 30377] will be killed. Quit anyway? (y or n) y Looking into the code, we are checking for the expect string in line 198 of check_smtp.c. However, we do the same again in line 234, this time matching against the returned string after the 'STARTTLS' command being sent. This looks like a bug to me. Commenting out the if-block solved my problem, I don't know if it's a proper fix though. Regards, Lee ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3556040&group_id=29880 From rcantu at paypal.com Mon Aug 13 20:37:18 2012 From: rcantu at paypal.com (Cantu, Ron) Date: Mon, 13 Aug 2012 18:37:18 +0000 Subject: [Nagiosplug-devel] check_ssh Message-ID: <528C87E6CF87EC4884710151407843B902B379B1@DEN-EXDDA-S41.corp.ebay.com> I have enabled service performance data (perfdata) processing w/ my Nagios 3.3.1 installation (linux). I have enabled perfdata, which allows me to write the results of my load and memory checks to my DB using my perfdata processing script. The problem is w/ the check_ssh plugin, it does not pass performance data to my script. I've verified this by checking what data is being sent to my processing script. SSH data is never sent unless it's for a statechange (stage changes are also processed by my perfdata processing script). Is this a known check_ssh issue that causes it to not to pass performance data to a perfdata processing script? Is there a fix? Thanks, Ron Cantu PS: I've checked my service definitions for my memory and SSH checks. There's no significant difference that accounts for this discrepancy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nagios at babar.us Mon Aug 13 20:48:56 2012 From: nagios at babar.us (Olivier 'Babar' Raginel) Date: Mon, 13 Aug 2012 20:48:56 +0200 Subject: [Nagiosplug-devel] check_ssh In-Reply-To: <528C87E6CF87EC4884710151407843B902B379B1@DEN-EXDDA-S41.corp.ebay.com> References: <528C87E6CF87EC4884710151407843B902B379B1@DEN-EXDDA-S41.corp.ebay.com> Message-ID: <20120813184845.GA29715@mail.babar.us> On Mon, Aug 13, 2012 at 06:37:18PM +0000, Cantu, Ron wrote: > I have enabled service performance data (perfdata) processing w/ my > Nagios 3.3.1 installation (linux). > > > I have enabled perfdata, which allows me to write the results of my > load and memory checks to my DB using my perfdata processing script. > The problem is w/ the check_ssh plugin, it does not pass performance > data to my script. I?ve verified this by checking what data is being > sent to my processing script. SSH data is never sent unless it?s for a > statechange (stage changes are also processed by my perfdata processing > script). > > > Is this a known check_ssh issue that causes it to not to pass > performance data to a perfdata processing script? > > Is there a fix? Patch check_ssh so it outputs performance data? Not sure what it would output though, 'cause I do not really see what kind of performance this plugin could measure... The time to get a reply, like check_icmp? The time to generate a session key? But I think it disconnects before even getting to that stage. So, what are you expecting to graph there? -- Babar From noreply at sourceforge.net Tue Aug 14 23:15:23 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Aug 2012 14:15:23 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-2458521 ] Add performance data to check_procs plugin Message-ID: Feature Requests item #2458521, was opened at 2008-12-22 05:10 Message generated for change (Comment added) made by dubuc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=2458521&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: Open Priority: 5 Private: No Submitted By: Jan Ondrej (ondrejj) Assigned to: Nobody/Anonymous (nobody) Summary: Add performance data to check_procs plugin Initial Comment: check_procs plugin has no performance data. It can be nice to display performance data for number of processes or zombie processes. I have my own perfdata wrapper until this will be a part of nagios-plugins, but my wrapper has very limited functionality. You only need to display this at end of line from check_plugin: |procs=NUMBER_OF_PROCS;WARN_PROC_COUNT;CRITICAL_PROC_COUNT;0 Attaching my wrapper, which does this, but it's not a right way. :) ---------------------------------------------------------------------- Comment By: Paul M. Dubuc (dubuc) Date: 2012-08-14 14:15 Message: Please consider patching with this enhanced version from nagios exchange: http://exchange.nagios.org/directory/Plugins/Operating-Systems/Linux/check_procs_perf/details ---------------------------------------------------------------------- Comment By: J.M. Roth (jmroth) Date: 2011-01-27 04:37 Message: Please forget my previous patch. I see there are several patches already listed: ID# 2918676 1106840 1396989 The oldest one is from 2005 :-\ Additionally, here is my current one against 1.4.15 --- check_procs-old.c 2010-07-27 22:47:16.000000000 +0200 +++ check_procs.c 2011-01-27 13:34:19.000000000 +0100 @@ -301,6 +301,35 @@ if ( verbose >= 1 && strcmp(fails,"") ) printf (" [%s]", fails); + printf ("|procs=%d", procs); + if (wmin == -1) { + if (wmax == -1) { + printf (";"); + } else { + printf (";:%d", wmax); + } + } else { + if (wmax == -1) { + printf (";%d:", wmin); + } else { + printf (";%d:%d", wmin, wmax); + } + } + if (cmin == -1) { + if (cmax == -1) { + printf (";"); + } else { + printf (";:%d", cmax); + } + } else { + if (cmax == -1) { + printf (";%d:", cmin); + } else { + printf (";%d:%d", cmin, cmax); + } + } + printf (";1"); + printf ("\n"); return result; } ---------------------------------------------------------------------- Comment By: J.M. Roth (jmroth) Date: 2011-01-27 01:07 Message: here's a diff to add performance data to check_procs.c --- check_procs-old.c 2010-07-27 22:47:16.000000000 +0200 +++ check_procs.c 2011-01-27 10:02:08.000000000 +0100 @@ -301,6 +301,7 @@ if ( verbose >= 1 && strcmp(fails,"") ) printf (" [%s]", fails); + printf ("|procs=%d;%d;%d;%d:%d;%d:%d", procs, warn, crit, wmin, wmax, cmin, cmax); printf ("\n"); return result; } ---------------------------------------------------------------------- Comment By: GreenRover (greenrover) Date: 2009-03-06 05:09 Message: Her as the original check_procs.c /root/nagios-plugins-1.4.13/plugins/check_procs.c row 308 befor " printf ("\n");" add: printf (" | "); printf (ngettext ("process=%d", "processes=%d", (unsigned long) procs), procs); printf (";%d;%d", wmax, cmax); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=2458521&group_id=29880 From eric.schoeller at Colorado.EDU Fri Aug 17 03:41:11 2012 From: eric.schoeller at Colorado.EDU (Eric Schoeller) Date: Thu, 16 Aug 2012 19:41:11 -0600 Subject: [Nagiosplug-devel] check_snmp multiplier / divisor Message-ID: <502DA137.9050408@colorado.edu> Hello list, We have a fair number of checks using check_snmp, and it is very common that an INTEGER is reported in 'tenths' or even 'hundredths'. To use check_snmp natively against these OIDs we are forced to set thresholds such as '700' to represent '70.0' Fahrenheit. This isn't too big of a problem except when tired admins get pages about temperatures reaching (what appears to be) 700 degrees Fahrenheit. In such cases we could simply write our own plugins, but there are a lot of these cases. It would be far more desirable to just use check_snmp. I was considering developing and submitting a patch for options such as --multiplier or --divisor ... or even perhaps --mangle where in you could perform a bit of math on any values returned from the SNMP agent. Thresholds would then be applied to the "mangled" value of the OID. Would there be support for such a change if we submitted a patch? Is there a reason why it would be unnecessary? Thanks, Eric Schoeller University of Colorado Boulder Office of Information Technology From william at leibzon.org Fri Aug 17 04:48:46 2012 From: william at leibzon.org (William Leibzon) Date: Thu, 16 Aug 2012 19:48:46 -0700 Subject: [Nagiosplug-devel] check_snmp multiplier / divisor In-Reply-To: <502DA137.9050408@colorado.edu> References: <502DA137.9050408@colorado.edu> Message-ID: Use http://exchange.nagios.org/directory/Plugins/Hardware/Environmental/check_snmp_temperature/details On Thu, Aug 16, 2012 at 6:41 PM, Eric Schoeller wrote: > Hello list, > > We have a fair number of checks using check_snmp, and it is very common > that an INTEGER is reported in 'tenths' or even 'hundredths'. To use > check_snmp natively against these OIDs we are forced to set thresholds > such as '700' to represent '70.0' Fahrenheit. This isn't too big of a > problem except when tired admins get pages about temperatures reaching > (what appears to be) 700 degrees Fahrenheit. > > In such cases we could simply write our own plugins, but there are a lot > of these cases. It would be far more desirable to just use check_snmp. I > was considering developing and submitting a patch for options such as > --multiplier or --divisor ... or even perhaps --mangle where in you > could perform a bit of math on any values returned from the SNMP agent. > Thresholds would then be applied to the "mangled" value of the OID. > > Would there be support for such a change if we submitted a patch? Is > there a reason why it would be unnecessary? > > Thanks, > > Eric Schoeller > University of Colorado Boulder > Office of Information Technology > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________________ > 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 ae at op5.se Fri Aug 17 11:15:25 2012 From: ae at op5.se (Andreas Ericsson) Date: Fri, 17 Aug 2012 11:15:25 +0200 Subject: [Nagiosplug-devel] check_snmp multiplier / divisor In-Reply-To: <502DA137.9050408@colorado.edu> References: <502DA137.9050408@colorado.edu> Message-ID: <502E0BAD.9040702@op5.se> On 08/17/2012 03:41 AM, Eric Schoeller wrote: > Hello list, > > We have a fair number of checks using check_snmp, and it is very common > that an INTEGER is reported in 'tenths' or even 'hundredths'. To use > check_snmp natively against these OIDs we are forced to set thresholds > such as '700' to represent '70.0' Fahrenheit. This isn't too big of a > problem except when tired admins get pages about temperatures reaching > (what appears to be) 700 degrees Fahrenheit. > > In such cases we could simply write our own plugins, but there are a lot > of these cases. It would be far more desirable to just use check_snmp. I > was considering developing and submitting a patch for options such as > --multiplier or --divisor ... or even perhaps --mangle where in you > could perform a bit of math on any values returned from the SNMP agent. > Thresholds would then be applied to the "mangled" value of the OID. > > Would there be support for such a change if we submitted a patch? Is > there a reason why it would be unnecessary? > I would love such a patch. Sounds like a generally awesome idea. In order to sanely implement it, I suggest supporting only simple math that can be parsed easily and unambiguously. It's likely to cover 99% of the cases, and for the rest, people will have to write their own plugins. You'd possibly want some "power of 2 to percent" thing though, since a lot of snmp-capable devices use all available precision to report some available resource, so "--formula=pct(256)" would transform "128" into "50". I'd implement the math part as macros if I were you. That way they'll be type-agnostic and work well in a wide range of scenarios. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. From eric.schoeller at Colorado.EDU Fri Aug 17 19:18:25 2012 From: eric.schoeller at Colorado.EDU (Eric Schoeller) Date: Fri, 17 Aug 2012 11:18:25 -0600 Subject: [Nagiosplug-devel] check_snmp multiplier / divisor In-Reply-To: <502E0BAD.9040702@op5.se> References: <502DA137.9050408@colorado.edu> <502E0BAD.9040702@op5.se> Message-ID: <502E7CE1.2090602@Colorado.EDU> On 08/17/12 03:15, Andreas Ericsson wrote: > On 08/17/2012 03:41 AM, Eric Schoeller wrote: >> Hello list, >> >> We have a fair number of checks using check_snmp, and it is very common >> that an INTEGER is reported in 'tenths' or even 'hundredths'. To use >> check_snmp natively against these OIDs we are forced to set thresholds >> such as '700' to represent '70.0' Fahrenheit. This isn't too big of a >> problem except when tired admins get pages about temperatures reaching >> (what appears to be) 700 degrees Fahrenheit. >> >> In such cases we could simply write our own plugins, but there are a lot >> of these cases. It would be far more desirable to just use check_snmp. I >> was considering developing and submitting a patch for options such as >> --multiplier or --divisor ... or even perhaps --mangle where in you >> could perform a bit of math on any values returned from the SNMP agent. >> Thresholds would then be applied to the "mangled" value of the OID. >> >> Would there be support for such a change if we submitted a patch? Is >> there a reason why it would be unnecessary? >> > I would love such a patch. Sounds like a generally awesome idea. In order > to sanely implement it, I suggest supporting only simple math that can be > parsed easily and unambiguously. It's likely to cover 99% of the cases, > and for the rest, people will have to write their own plugins. > > You'd possibly want some "power of 2 to percent" thing though, since a > lot of snmp-capable devices use all available precision to report > some available resource, so "--formula=pct(256)" would transform "128" > into "50". > > I'd implement the math part as macros if I were you. That way they'll be > type-agnostic and work well in a wide range of scenarios. > Great, I'm glad you are interested in the idea. We will take a look at submitting a patch. William, I just deployed your check_snmp_temperature plugin across 19 of our Dell servers. Looks really good so far. Looks like this plugin will cover about 30% of our needs - the 'formula' option to check_snmp will be useful for things other than temperature. Some examples are UPS runtime, RAID latency, differential pressure, % valve opening, humidity, voltage, amperage, watts ... etc. One suggestion, and this may sound crazy, but it might be nice to have a range implemented for check_snmp_temperature similar to how check_snmp handles ranges. Strangely enough, in some cases I would like to know if devices get TOO cold ! Thanks, Eric From william at leibzon.org Fri Aug 17 21:24:58 2012 From: william at leibzon.org (William Leibzon) Date: Fri, 17 Aug 2012 12:24:58 -0700 Subject: [Nagiosplug-devel] check_snmp multiplier / divisor In-Reply-To: <502E7CE1.2090602@Colorado.EDU> References: <502DA137.9050408@colorado.edu> <502E0BAD.9040702@op5.se> <502E7CE1.2090602@Colorado.EDU> Message-ID: On Fri, Aug 17, 2012 at 10:18 AM, Eric Schoeller < eric.schoeller at colorado.edu> wrote: > > I would love such a patch. Sounds like a generally awesome idea. In order > > to sanely implement it, I suggest supporting only simple math that can be > > parsed easily and unambiguously. It's likely to cover 99% of the cases, > > and for the rest, people will have to write their own plugins. > At some point I wrote a bit weird plugin/plugin-library. It implements internally something similar to Forth machine but also with support for overloading operators and auto-typing, and all in perl of all languages :) http://exchange.nagios.org/directory/Plugins/%2A-Plugin-Development-Tools/check_snmp_attributes-2Epl--2D-experimental-plugin-base-%26-library/details Read what I wrote in description and how it started from trying to more comprehensive expression to make something more general than check_snmp_temperature. Of course I've over-done it a little :) I'm still undecided what will happen to this code, most likely I'll use expression part of it for a perl plugin library I'm working with. You can already see what this library would be from check_memcached and check_redis plugins: https://github.com/willixix/WL-NagiosPlugins/blob/master/check_redis.pl Check_snmp_temperature will use it as most of my other plugins. Probably 6 months before it becomes a full library. > You'd possibly want some "power of 2 to percent" thing though, since a > > lot of snmp-capable devices use all available precision to report > > some available resource, so "--formula=pct(256)" would transform "128" > > into "50". > > > > I'd implement the math part as macros if I were you. That way they'll be > > type-agnostic and work well in a wide range of scenarios. > > > > Great, I'm glad you are interested in the idea. We will take a look at > submitting a patch. > > William, > > I just deployed your check_snmp_temperature plugin across 19 of our Dell > servers. Looks really good so far. Looks like this plugin will cover > about 30% of our needs - the 'formula' option to check_snmp will be > useful for things other than temperature. Some examples are UPS runtime, > RAID latency, differential pressure, % valve opening, humidity, voltage, > amperage, watts ... etc. > Those are all environmental data very similar to temperature. I will mostly likely extend check_snmp_temperature to handle things other than just temperature and rename it check_env (or something like it) in the future. Basically plans are to merge it with Patrick Proy's check_snmp_env as well as support getting environment data directly on linux machine. Voltage is most important of what I want to support in addition to temperature. And you can just use check_snmp_temperature directly as is for other environmental data. I also extended it to support voltage, amperage and power (watts) for a specific device: http://exchange.nagios.org/directory/Plugins/Hardware/Environmental/Baytech-PDU-Monitoring-Plugin/details You're welcome to use this as a base for some other device you may have. Properly supporting every type of device with just one plugin is really difficult. One suggestion, and this may sound crazy, but it might be nice to have a > range implemented for check_snmp_temperature similar to how check_snmp > handles ranges. Strangely enough, in some cases I would like to know if > devices get TOO cold ! > This plugin is being used at a hadron collider in Switzerland (hopefully only for network equipment there), so apparently you're not the first to want it :) And it actually does support it. 0.4 beta of check_snmp_temperature supports ranges in full: https://github.com/willixix/WL-NagiosPlugins/blob/master/check_snmp_temperature.pl You're welcome to test it, the range code should be working, through I've not extensively tested it myself. And its no longer the best code, I'll replace it with newest generation of functions from check_redis when I get to it. Don't know when though - check_snmp_temperature is not a priority right now, I'll work on enhancing check_mysqld first after I've done with bunch of other things. To include support for APC OIDs you should send me a patch for it. But please do test it. And my experience with APC though is that they are hard to support with a general plugin and would require a custom-coded plugin, i.e. its better to write a plugin similar to one I pointed above for baytech. William -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Thu Aug 23 03:02:43 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Aug 2012 18:02:43 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3560843 ] check_disk: -M meanting swapped? and -M documentation Message-ID: Bugs item #3560843, was opened at 2012-08-22 18:02 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3560843&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk: -M meanting swapped? and -M documentation Initial Comment: Hi. With check_disk v1.4.15 (nagios-plugins 1.4.15): # /usr/lib/nagios/plugins/check_disk -l -u bytes -x /dev -x /lib/init/rw -x /dev/shm DISK OK - free space: / 5560602624 B (61% inode=81%);| /=3483860992B;;;0;9528483840 # /usr/lib/nagios/plugins/check_disk -l -u bytes -x /dev -x /lib/init/rw -x /dev/shm -M DISK OK - free space: /dev/mapper/vg_system-root 5560578048 B (61% inode=81%);| /dev/mapper/vg_system-root=3483885568B;;;0;9528483840 When I add -M the device and not the mountpoint is given; so the behaviour seems to be just swapped as documented. Also, the documentation speaks about mountpoints vs. partitions. Please use "devices" instead of partitions, as the devices need not to be partitions. Cheers, Chris. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3560843&group_id=29880 From noreply at sourceforge.net Thu Aug 23 13:42:42 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Aug 2012 04:42:42 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3560976 ] check_disk: implement --include-type Message-ID: Bugs item #3560976, was opened at 2012-08-23 04:42 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3560976&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk: implement --include-type Initial Comment: Hi. It would be great if, in addition to -X, --exclude-type=TYPE, there was a --include-type option.... If include-type is given (first) then per default no fs type shall be included but the ones given there. Cheers, Chris. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3560976&group_id=29880 From noreply at sourceforge.net Thu Aug 23 13:50:16 2012 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Aug 2012 04:50:16 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3560978 ] document the base of binary units and support/use SI bases Message-ID: Bugs item #3560978, was opened at 2012-08-23 04:50 Message generated for change (Tracker Item Submitted) made by calestyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3560978&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: Open Resolution: None Priority: 5 Private: No Submitted By: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: document the base of binary units and support/use SI bases Initial Comment: Hi. Currently the base of binary units in most (all?) plugins, e.g. check_disk which use them seems to be 1024. This is though usually not documented, which makes the whole thing ambigous. Please support SI units and use the correct units: First that means that things like kB, MB or --megabytes of e.g. check_disk should no longer use the incorrect basis 1024. k is always 1000, etc. pp. The IEC standardised the use of e.g. KiB, MiB, GiB, TiB as units with the basis 1024. Cheers, Chris. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3560978&group_id=29880