From noreply at sourceforge.net Thu Jun 2 09:19:42 2011 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 2 Jun 2011 09:19:42 +0200 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3310487 ] Confirm licensing of nagios-plugins Message-ID: Bugs item #3310487, was opened at 2011-06-02 09:19 Message generated for change (Tracker Item Submitted) made by lrupp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3310487&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: release-1.4.15 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lars Vogdt (lrupp) Assigned to: Nobody/Anonymous (nobody) Summary: Confirm licensing of nagios-plugins Initial Comment: The COPYING file inside the tarball declares the package to be GPLv2+. However, the entire gl/ subdirectory is GPLv3+ and seems to be kept in sync with gnulib upstream (also GPLv3). The statement on the nagios-plugins website does not help: "The Nagios Plugins is currently distributed using the GNU General Public License version 2. There is a task to convert the project to be under GPLv3. This is because some C code that we depend upon, from the GNUlib project, is under GPLv3 and therefore some of our C plugins also need to be GPLv3. So the team has decided rather than having a mixed license, we'll distribute the core Nagios Plugins code as GPLv3. This page will be updated when this has been completed." Posted by tonvoon on 25 January 2008 Looks like there is no update, but the license questions is important for distributions like Debian, Fedora and openSUSE to include it. So can you please clarify the license status? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3310487&group_id=29880 From noreply at sourceforge.net Mon Jun 6 17:14:27 2011 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 6 Jun 2011 17:14:27 +0200 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3312534 ] check_disk_smb - Samba shares upper 2 To Message-ID: Bugs item #3312534, was opened at 2011-06-06 17:14 Message generated for change (Tracker Item Submitted) made by olikamm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3312534&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: release-1.4.15 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Olivier (olikamm) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk_smb - Samba shares upper 2 To Initial Comment: Plugin Version (-V output): nagios-plugins 1.4.15 Plugin Name: check_disk_smb Plugin Commandline showing issues: none Operating System: CentOS release 5.6 (Final) The plugin cannot detect space on Samba shares over 2To. It still works, but if I have a 8To share with 2To used, the plugin will write 2047.93G (100%) free. I guess this is a limitation on a int32 variable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3312534&group_id=29880 From noreply at sourceforge.net Tue Jun 7 09:25:09 2011 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 7 Jun 2011 09:25:09 +0200 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3312946 ] check_disk_smb - Samba shares upper 2 To Message-ID: Bugs item #3312946, was opened at 2011-06-07 09:25 Message generated for change (Tracker Item Submitted) made by olikamm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3312946&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: release-1.4.15 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Olivier (olikamm) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk_smb - Samba shares upper 2 To Initial Comment: Plugin Version (-V output): nagios-plugins 1.4.15 Plugin Name: check_disk_smb Plugin Commandline showing issues: none Operating System: CentOS release 5.6 (Final) The plugin cannot detect space on Samba shares over 2To. It still works, but if I have a 8To share with 2To used, the plugin will write 2047.93G (100%) free. I guess this is a limitation on a int32 variable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3312946&group_id=29880 From noreply at sourceforge.net Tue Jun 7 16:17:18 2011 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 7 Jun 2011 14:17:18 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3313190 ] check_snmp processes wrong numeric part of response Message-ID: Bugs item #3313190, was opened at 2011-06-07 14:17 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3313190&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: Parsing problem Group: release-1.4.15 Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: check_snmp processes wrong numeric part of response Initial Comment: check_snmp returns the first numeric part of the response, not necessarily the returned value, when a MIB is in use and leaf name includes digits. Checked on Debian Squeeze i386 with packaged version, and trunk, same problem. libsnmp-base 5.4.3~dfsg-2 $ ./check_snmp -V check_snmp v1.4.15-24-g5ebe (nagios-plugins 1.4.15) $ snmpwalk -v 1 -c readme 10.254.5.99 .1.3.6.1.4.1.12394.1.1.1.16.0 -m ALVARION-DOT11-WLAN-MIB ALVARION-DOT11-WLAN-MIB::brzaccVLCurrentEthernetPortState.0 = INTEGER: fullDuplexAnd100Mbps(4) $ ./check_snmp -H 10.254.5.99 -C readme -w 1 -c 2 -o .1.3.6.1.4.1.12394.1.1.1.16.0 -vvv /usr/bin/snmpget -t 1 -r 5 -m '' -v 1 [authpriv] 10.254.5.99:161 .1.3.6.1.4.1.12394.1.1.1.16.0 iso.3.6.1.4.1.12394.1.1.1.16.0 = INTEGER: 4 Processing oid 1 (line 1) oidname: iso.3.6.1.4.1.12394.1.1.1.16.0 response: = INTEGER: 4 SNMP CRITICAL - *4* | iso.3.6.1.4.1.12394.1.1.1.16.0=4 $ ./check_snmp -H 10.254.5.99 -C readme -w 1 -c 2 -o .1.3.6.1.4.1.12394.1.1.1.16.0 -m ALVARION-DOT11-WLAN-MIB -vvv /usr/bin/snmpget -t 1 -r 5 -m ALVARION-DOT11-WLAN-MIB -v 1 [authpriv] 10.254.5.99:161 .1.3.6.1.4.1.12394.1.1.1.16.0 ALVARION-DOT11-WLAN-MIB::brzaccVLCurrentEthernetPortState.0 = INTEGER: fullDuplexAnd100Mbps(4) Processing oid 1 (line 1) oidname: ALVARION-DOT11-WLAN-MIB::brzaccVLCurrentEthernetPortState.0 response: = INTEGER: fullDuplexAnd100Mbps(4) SNMP CRITICAL - *100* | ALVARION-DOT11-WLAN-MIB::brzaccVLCurrentEthernetPortState.0=100 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3313190&group_id=29880 From nathan.vonnahme at bannerhealth.com Thu Jun 9 00:25:58 2011 From: nathan.vonnahme at bannerhealth.com (Vonnahme, Nathan) Date: Wed, 8 Jun 2011 14:25:58 -0800 Subject: [Nagiosplug-devel] Integrating Nagios with Test Driven Development Message-ID: <4438E9AD19D31044BDBD63937F86BF8915DA8600E9@FAI01400.bhs.bannerhealth.com> Hello Nagios devs, I've been pretty dormant on these lists for a while, partly because our Nagios installation is humming along so merrily, and partly because my job has changed to be more development-oriented and less sysadmin-oriented. But I had a great idea (imho) last week and I've implemented and wrote about it and I want to share it with you and solicit feedback. In a nutshell, I've written a plugin to integrate Nagios with any software testing tool that emits TAP (Test Anything Protocol), such as Perl test scripts and unit and functional tests written in a bunch of different languages. I've described it in detail in a blog post: http://n8v.enteuxis.org/2011/06/integrating-nagios-with-test-driven-development/ And the code is on GitHub: https://gist.github.com/1005409 I've been pretty excited about the idea and have already been using it in production to improve several parts of our Nagios monitoring. Please take a look at it and let me know your thoughts via these lists or comments on the blog or Gist. Thanks, nathan -- Nathan.Vonnahme at BannerHealth.com Software Engineer Sr at Fairbanks Memorial Hospital 1650 Cowles St, Fairbanks, Alaska 99701 907-458-5464 -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Thu Jun 9 15:20:16 2011 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 9 Jun 2011 13:20:16 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3306880 ] Negate doesn't seem to do anything Message-ID: Bugs item #3306880, was opened at 2011-05-24 12:16 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3306880&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: release-1.4.15 >Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: MikeM-2468 (mikem-2468) Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: Negate doesn't seem to do anything Initial Comment: The negate plugin doesn't seem to work as it should. With or without negate, I get the same results. I used the following command as a test but get the same result with or without using negate. negate check_ping -H 192.168.100.1 -w 3000.0,80% -c 5000.0,100% -p 5 I've tried v1.4.15 and v1.4.15.-24-g5ebe. Running gcc version 4.3.2 (Debian 4.3.2-1.1) x86. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2011-06-09 13:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2011-05-27 04:03 Message: Yes, it actually change the nagios status, which is not directly connected to the output text. Normally the text always match the status, but negate alters the nagios status only (not the output text). This is particularly useful when different statuses are handled differently (ex. email vs pagers). Also usually email subjects use a nagios macro which returns the correct status text, with the plugin output in the body. And as I pointed out, the -s switch (available in recent versions) can be used to replace the output text as well. ---------------------------------------------------------------------- Comment By: MikeM-2468 (mikem-2468) Date: 2011-05-26 12:46 Message: OK. The Manpage seemed to indicate that it would change OK to CRITICAL and vice versa. I get 0 vs 2 with your example. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2011-05-26 12:34 Message: Negate by default only change the return code, which is what matters for Nagios. try: check_ping -H 192.168.100.1 -w 3000.0,80% -c 5000.0,100% -p 5; echo $? vs. negate check_ping -H 192.168.100.1 -w 3000.0,80% -c 5000.0,100% -p 5; echo $? You can also use the -s switch in negate to also change the returned string, but it'll only work for standard results like "CRITICAL" - ex a plugin returning "Error" will not be altered besides the return code. I'm marking the bug as invalid for now, I'll reopen if you can demonstrate an issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3306880&group_id=29880 From noreply at sourceforge.net Fri Jun 10 14:56:22 2011 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Jun 2011 08:56:22 -0400 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3314686 ] check_ntp_time and check_ntp_peers cannot find offset Message-ID: Bugs item #3314686, was opened at 2011-06-10 08:56 Message generated for change (Tracker Item Submitted) made by silfreed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3314686&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: v1.4.14 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Douglas E. Warner (silfreed) Assigned to: Nobody/Anonymous (nobody) Summary: check_ntp_time and check_ntp_peers cannot find offset Initial Comment: I'm having a similar problem with the "offset unknown" that others have had in the past, although I'm running 1.4.14 of the plugins using check_ntp_time and check_ntp_peer. Below is the output of some of the commands. For some reason check_ntp_peer doesn't even seem to be able to find the peers, although check_ntp_time seems fine, but doesn't get the correct offset. # ntpdc -n -s localhost remote local st poll reach delay offset disp ======================================================================= 208.53.158.34 10.128.0.45 2 64 3 0.02493 -0.088040 1.98438 204.9.54.119 10.128.0.45 1 64 3 0.00943 -0.035220 1.98444 199.4.29.166 10.128.0.45 2 64 3 0.02950 -0.021567 1.98444 216.129.110.22 10.128.0.45 2 64 3 0.01813 -0.027695 1.98444 # /usr/lib/nagios/plugins/check_ntp_peer -H 127.0.0.1 -w 5 -c 10 -v 0 candiate peers available warning: no synchronization source found warning: LI_ALARM bit is set NTP CRITICAL: Server not synchronized, Offset unknown| # /usr/lib/nagios/plugins/check_ntp_time -H 127.0.0.1 -w 5 -c 10 -v sending request to peer 0 response from peer 0: offset 2.74181366e-06 sending request to peer 0 response from peer 0: offset -4.291534424e-06 sending request to peer 0 response from peer 0: offset -3.457069397e-06 sending request to peer 0 response from peer 0: offset -3.576278687e-06 discarding peer 0: stratum=0 overall average offset: 0 NTP CRITICAL: Offset unknown| ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3314686&group_id=29880 From noreply at sourceforge.net Tue Jun 14 17:07:58 2011 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Jun 2011 17:07:58 +0200 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-3316300 ] Intermediate perfdata metrics for check_http Message-ID: Patches item #3316300, was opened at 2011-06-14 17:07 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=3316300&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: Sebastian Nohn () Assigned to: Nobody/Anonymous (nobody) Summary: Intermediate perfdata metrics for check_http Initial Comment: Patch against Plugin Version (-V output): check_http v1.4.15.24.g5ebe.dirty (nagios-plugins 1.4.15) Plugin Name: check_http Example Plugin Commandline: ./check_http --ssl -H sourceforge.net -I sourceforge.net -u "/" Tested on operating system: Ubuntu 6.06 - 10.10 Tested on architecture: x86 Tested with compiler: gcc version 4.0.3 - gcc version 4.4.5 Adds more metrics to perfdata: HTTP OK: HTTP/1.1 302 Found - 686 bytes in 2.168 second response time |time=2.168183s;;;0.000000 size=686B;;;0 time_connect=1.702106s;;; time_ssl=0.248949s;;; time_headers=0.000066s;;; time_firstbyte=0.216779s;;; time_transfer=0.216811s;;; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=3316300&group_id=29880 From noreply at sourceforge.net Tue Jun 14 20:50:00 2011 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Jun 2011 13:50:00 -0500 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3316383 ] check_disk_smb uses -w and -c can't be set to be equal Message-ID: Bugs item #3316383, was opened at 2011-06-14 13:50 Message generated for change (Tracker Item Submitted) made by mfrostp83 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3316383&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: release-1.4.15 Status: Open Resolution: None Priority: 5 Private: No Submitted By: mfrostp83 (mfrostp83) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk_smb uses -w and -c can't be set to be equal Initial Comment: The check_disk_smb plugin seems to behave differently from other plugins in that it will not allow you to set them to be equal. Commonly, we only want a critical alert and not a warning so we set them to be equal for a plugin (i.e. "-w 90% -c 90%"). When you do this with check_disk_smb, you get Percentage: warning (90%) should be less than critical (90%) Other plugins allow them to be set equal. When they are equal, they seem to just ignore the warning threshold. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3316383&group_id=29880 From noreply at sourceforge.net Tue Jun 14 21:00:10 2011 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Jun 2011 14:00:10 -0500 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3316383 ] check_disk_smb uses -w and -c can't be set to be equal Message-ID: Bugs item #3316383, was opened at 2011-06-14 13:50 Message generated for change (Comment added) made by mfrostp83 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3316383&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: release-1.4.15 Status: Open Resolution: None Priority: 5 Private: No Submitted By: mfrostp83 (mfrostp83) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk_smb uses -w and -c can't be set to be equal Initial Comment: The check_disk_smb plugin seems to behave differently from other plugins in that it will not allow you to set them to be equal. Commonly, we only want a critical alert and not a warning so we set them to be equal for a plugin (i.e. "-w 90% -c 90%"). When you do this with check_disk_smb, you get Percentage: warning (90%) should be less than critical (90%) Other plugins allow them to be set equal. When they are equal, they seem to just ignore the warning threshold. ---------------------------------------------------------------------- >Comment By: mfrostp83 (mfrostp83) Date: 2011-06-14 14:00 Message: Note that I'm running this on SLES 11.1 Linux. I also notice that there's some strange behavior when the -w argument is not specified. It's as if there's an implicit definition of 85% for warning if you don't set it which breaks when you use only -c: $ check_disk_smb -H host -W domain -s share -u user -p pass --critical 81% Percentage: warning (85) should be less than critical (81%) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3316383&group_id=29880 From noreply at sourceforge.net Wed Jun 15 02:26:34 2011 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Jun 2011 02:26:34 +0200 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1180762 ] check_ssh does not properly close connection Message-ID: Bugs item #1180762, was opened at 2005-04-11 16:41 Message generated for change (Comment added) made by chninkel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1180762&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: M. Sean Finney (seanius) Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: check_ssh does not properly close connection Initial Comment: with 1.4 and later, it looks like check_ssh doesn't properly close connections. for example, this is the previous behaviour of check_ssh in the 1.3 series: Apr 11 10:24:03 appsrv1 sshd[9822]: Connection closed by xxx.xxx.64.52 but in 1.4: appsrv1 sshd[10154]: fatal: Read from socket failed: Connection reset by peer i think this is just because close() isn't being called. i will verify this shortly... ---------------------------------------------------------------------- Comment By: Yann Rouillard (chninkel) Date: 2011-06-15 02:26 Message: I can confirm this problem, it doesn't happen every time but often enough to be reproduceable with launching The randomness seems to be caused by some timing condition. As soon as openssh receive the agent string, it replies with some key exchange data. It seems that if the close happens after the nagios host has received the data, the ssh server will receive a ECONNRESET and log the "Connection reset by peer" message. If the close happens before the nagios host has received the data, the connection is properly closed. I made the following modification in check_ssh.c to be sure to flush the incoming data before closing the socket and it solved the problem, no more error log whatever the number of check_ssh call. --- check_ssh.c 2011-06-15 02:24:31.000000000 +0200 +++ check_ssh.c.new 2011-06-15 02:24:04.000000000 +0200 @@ -45,7 +45,7 @@ #endif #define SSH_DFL_PORT 22 -#define BUFF_SZ 256 +#define BUFF_SZ 1024 int port = -1; char *server_name = NULL; @@ -252,6 +252,7 @@ printf (_("SSH WARNING - %s (protocol %s) version mismatch, expected '%s'\n"), ssh_server, ssh_proto, remote_version); + recv (sd, output, BUFF_SZ, 0); close(sd); exit (STATE_WARNING); } @@ -259,6 +260,7 @@ printf (_("SSH OK - %s (protocol %s)\n"), ssh_server, ssh_proto); + recv (sd, output, BUFF_SZ, 0); close(sd); exit (STATE_OK); } ---------------------------------------------------------------------- Comment By: Pedro Albuquerque (pedroalb84) Date: 2011-05-26 16:43 Message: Hi all, is there any fixes for this issue? cheers. Pedro ---------------------------------------------------------------------- Comment By: Christian (christian42) Date: 2010-03-27 08:21 Message: Sorry to revive such an old issue, but I don't think this is resolved yet. I just built nagiosplugins-1.4.14 on Solaris 10/x86 and see the same old issue: --------------------------------------------------------- ray1# uname -a SunOS ray1 5.10 Generic_141445-09 i86pc i386 i86pc ray1# pwd /home/c/nagios-plugins-1.4.14 ray1# file ./plugins/check_ssh ./plugins/check_ssh: ELF 32-bit LSB executable 80386 Version 1, dynamically linked, not stripped ray1# ./plugins/check_ssh localhost SSH OK - Sun_SSH_1.1.2 (protocol 2.0) ray1# dmesg | tail -1 Mar 27 08:06:43 ray1 sshd[7169]: [ID 800047 auth.crit] fatal: Read from socket failed: Connection reset by peer --------------------------------------------------------- A similar installation on sparc (also with 1.4.14) shows the same result. When running through truss(1) it seems that the socket /is/ being closed though: ------------------------------- 10758/1: 0.0278 so_socket(PF_INET, SOCK_STREAM, IPPROTO_IP, "", SOV_DEFAULT) = 3 10758/1: 0.0280 connect(3, 0x0002CF10, 16, SOV_DEFAULT) = 0 [...] 10758/1: 0.0338 close(3) = 0 ------------------------------- So, maybe it's something else (and not a missing close()) causing these messages? During the connect and when one is fast enough, for a second or so one can see in netstat: 127.0.0.1.33748 127.0.0.1.22 49152 0 49152 0 FIN_WAIT_2 127.0.0.1.22 127.0.0.1.33748 49152 0 49152 0 CLOSE_WAIT Any ideas how to debug this further? Thanks, Christian. PS: Why was this closed as "Wont Fix" when clearly a change has been commited? ---------------------------------------------------------------------- Comment By: Sergey Svishchev (shattered) Date: 2007-11-06 09:13 Message: Logged In: YES user_id=45207 Originator: NO I'm using OpenSSH_3.8.1p1 FreeBSD-20060123 (shipped in FreeBSD 5.5) and can reproduce it at will. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2007-11-02 13:58 Message: Logged In: YES user_id=375623 Originator: NO Yes, emias made me realize that on IRC yesterday. I looked into it and I won't fix this because: 1. I can't reproduce it on OpenSSH, even with DEBUG logging (What SSH server/version are you using?) 2. There's no simple way to do that. It would at the very least require implementing the key exchange part of the protocol; I didn't even look further as this is way beyond the scope of this plugin. I suggest that you rather look into your SSH daemon or logging daemon configuration; or get this fixed with your ssh vendor. ---------------------------------------------------------------------- Comment By: Sergey Svishchev (shattered) Date: 2007-11-02 06:32 Message: Logged In: YES user_id=45207 Originator: NO It's check_ssh, not check_by_ssh. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2007-11-02 03:29 Message: Logged In: YES user_id=375623 Originator: NO There's no close in there, and no signs of seanius's commit. He either forgot to commit or commited it to the wrong branch... I'll take a look shortly. Since I never used check_by_ssh it'll help if you can give me a sample command-ling and what to look for (In logs I guess), so I won't have to reinvent the wheel :) Thanks ---------------------------------------------------------------------- Comment By: Sergey Svishchev (shattered) Date: 2007-10-31 15:34 Message: Logged In: YES user_id=45207 Originator: NO This is still a problem in 1.4.3 -- evidently, close() is not enough. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-04-11 20:07 Message: Logged In: YES user_id=226838 yup, calling close() before exiting resolves this problem, i've committed a change to cvs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1180762&group_id=29880 From noreply at sourceforge.net Wed Jun 15 02:29:00 2011 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Jun 2011 02:29:00 +0200 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1180762 ] check_ssh does not properly close connection Message-ID: Bugs item #1180762, was opened at 2005-04-11 16:41 Message generated for change (Comment added) made by chninkel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1180762&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: M. Sean Finney (seanius) Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: check_ssh does not properly close connection Initial Comment: with 1.4 and later, it looks like check_ssh doesn't properly close connections. for example, this is the previous behaviour of check_ssh in the 1.3 series: Apr 11 10:24:03 appsrv1 sshd[9822]: Connection closed by xxx.xxx.64.52 but in 1.4: appsrv1 sshd[10154]: fatal: Read from socket failed: Connection reset by peer i think this is just because close() isn't being called. i will verify this shortly... ---------------------------------------------------------------------- Comment By: Yann Rouillard (chninkel) Date: 2011-06-15 02:29 Message: After some reading, it seems using SO_LINGER socket option might be a better way. ---------------------------------------------------------------------- Comment By: Yann Rouillard (chninkel) Date: 2011-06-15 02:26 Message: I can confirm this problem, it doesn't happen every time but often enough to be reproduceable with launching The randomness seems to be caused by some timing condition. As soon as openssh receive the agent string, it replies with some key exchange data. It seems that if the close happens after the nagios host has received the data, the ssh server will receive a ECONNRESET and log the "Connection reset by peer" message. If the close happens before the nagios host has received the data, the connection is properly closed. I made the following modification in check_ssh.c to be sure to flush the incoming data before closing the socket and it solved the problem, no more error log whatever the number of check_ssh call. --- check_ssh.c 2011-06-15 02:24:31.000000000 +0200 +++ check_ssh.c.new 2011-06-15 02:24:04.000000000 +0200 @@ -45,7 +45,7 @@ #endif #define SSH_DFL_PORT 22 -#define BUFF_SZ 256 +#define BUFF_SZ 1024 int port = -1; char *server_name = NULL; @@ -252,6 +252,7 @@ printf (_("SSH WARNING - %s (protocol %s) version mismatch, expected '%s'\n"), ssh_server, ssh_proto, remote_version); + recv (sd, output, BUFF_SZ, 0); close(sd); exit (STATE_WARNING); } @@ -259,6 +260,7 @@ printf (_("SSH OK - %s (protocol %s)\n"), ssh_server, ssh_proto); + recv (sd, output, BUFF_SZ, 0); close(sd); exit (STATE_OK); } ---------------------------------------------------------------------- Comment By: Pedro Albuquerque (pedroalb84) Date: 2011-05-26 16:43 Message: Hi all, is there any fixes for this issue? cheers. Pedro ---------------------------------------------------------------------- Comment By: Christian (christian42) Date: 2010-03-27 08:21 Message: Sorry to revive such an old issue, but I don't think this is resolved yet. I just built nagiosplugins-1.4.14 on Solaris 10/x86 and see the same old issue: --------------------------------------------------------- ray1# uname -a SunOS ray1 5.10 Generic_141445-09 i86pc i386 i86pc ray1# pwd /home/c/nagios-plugins-1.4.14 ray1# file ./plugins/check_ssh ./plugins/check_ssh: ELF 32-bit LSB executable 80386 Version 1, dynamically linked, not stripped ray1# ./plugins/check_ssh localhost SSH OK - Sun_SSH_1.1.2 (protocol 2.0) ray1# dmesg | tail -1 Mar 27 08:06:43 ray1 sshd[7169]: [ID 800047 auth.crit] fatal: Read from socket failed: Connection reset by peer --------------------------------------------------------- A similar installation on sparc (also with 1.4.14) shows the same result. When running through truss(1) it seems that the socket /is/ being closed though: ------------------------------- 10758/1: 0.0278 so_socket(PF_INET, SOCK_STREAM, IPPROTO_IP, "", SOV_DEFAULT) = 3 10758/1: 0.0280 connect(3, 0x0002CF10, 16, SOV_DEFAULT) = 0 [...] 10758/1: 0.0338 close(3) = 0 ------------------------------- So, maybe it's something else (and not a missing close()) causing these messages? During the connect and when one is fast enough, for a second or so one can see in netstat: 127.0.0.1.33748 127.0.0.1.22 49152 0 49152 0 FIN_WAIT_2 127.0.0.1.22 127.0.0.1.33748 49152 0 49152 0 CLOSE_WAIT Any ideas how to debug this further? Thanks, Christian. PS: Why was this closed as "Wont Fix" when clearly a change has been commited? ---------------------------------------------------------------------- Comment By: Sergey Svishchev (shattered) Date: 2007-11-06 09:13 Message: Logged In: YES user_id=45207 Originator: NO I'm using OpenSSH_3.8.1p1 FreeBSD-20060123 (shipped in FreeBSD 5.5) and can reproduce it at will. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2007-11-02 13:58 Message: Logged In: YES user_id=375623 Originator: NO Yes, emias made me realize that on IRC yesterday. I looked into it and I won't fix this because: 1. I can't reproduce it on OpenSSH, even with DEBUG logging (What SSH server/version are you using?) 2. There's no simple way to do that. It would at the very least require implementing the key exchange part of the protocol; I didn't even look further as this is way beyond the scope of this plugin. I suggest that you rather look into your SSH daemon or logging daemon configuration; or get this fixed with your ssh vendor. ---------------------------------------------------------------------- Comment By: Sergey Svishchev (shattered) Date: 2007-11-02 06:32 Message: Logged In: YES user_id=45207 Originator: NO It's check_ssh, not check_by_ssh. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2007-11-02 03:29 Message: Logged In: YES user_id=375623 Originator: NO There's no close in there, and no signs of seanius's commit. He either forgot to commit or commited it to the wrong branch... I'll take a look shortly. Since I never used check_by_ssh it'll help if you can give me a sample command-ling and what to look for (In logs I guess), so I won't have to reinvent the wheel :) Thanks ---------------------------------------------------------------------- Comment By: Sergey Svishchev (shattered) Date: 2007-10-31 15:34 Message: Logged In: YES user_id=45207 Originator: NO This is still a problem in 1.4.3 -- evidently, close() is not enough. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-04-11 20:07 Message: Logged In: YES user_id=226838 yup, calling close() before exiting resolves this problem, i've committed a change to cvs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1180762&group_id=29880 From noreply at sourceforge.net Wed Jun 15 09:15:56 2011 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Jun 2011 09:15:56 +0200 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-3316300 ] Intermediate perfdata metrics for check_http Message-ID: Patches item #3316300, was opened at 2011-06-14 17:07 Message generated for change (Settings changed) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=3316300&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: Perf data Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sebastian Nohn () Assigned to: Nobody/Anonymous (nobody) Summary: Intermediate perfdata metrics for check_http Initial Comment: Patch against Plugin Version (-V output): check_http v1.4.15.24.g5ebe.dirty (nagios-plugins 1.4.15) Plugin Name: check_http Example Plugin Commandline: ./check_http --ssl -H sourceforge.net -I sourceforge.net -u "/" Tested on operating system: Ubuntu 6.06 - 10.10 Tested on architecture: x86 Tested with compiler: gcc version 4.0.3 - gcc version 4.4.5 Adds more metrics to perfdata: HTTP OK: HTTP/1.1 302 Found - 686 bytes in 2.168 second response time |time=2.168183s;;;0.000000 size=686B;;;0 time_connect=1.702106s;;; time_ssl=0.248949s;;; time_headers=0.000066s;;; time_firstbyte=0.216779s;;; time_transfer=0.216811s;;; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=3316300&group_id=29880 From bricechappe at gmail.com Fri Jun 17 10:06:06 2011 From: bricechappe at gmail.com (CHAPPE Brice) Date: Fri, 17 Jun 2011 10:06:06 +0200 Subject: [Nagiosplug-devel] About check_smtp and check_ssmtp Message-ID: <003701cc2cc5$698adf30$3ca09d90$@com> Hello, Why don't add for example an -m option to say to nagios to send mail notification (when critical) on other email address than the email address use by nagios by default for notification ? If you check STMP smtp.example.com and your notification email address for nagios is nagios at example.com, If smtp.example.com is down, you can't receive a mail notification from nagios on nagios at example.com . Best regards, Brice -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Fri Jun 17 22:31:38 2011 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Jun 2011 20:31:38 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-3319604 ] check_icmp : disable rtmin/rtmax perfomance data Message-ID: Patches item #3319604, was opened at 2011-06-17 20:31 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=3319604&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: S?bastien Prud'homme () Assigned to: Nobody/Anonymous (nobody) Summary: check_icmp : disable rtmin/rtmax perfomance data Initial Comment: Patch against Plugin Version (-V output): check_icmp v1.4.15 (nagios-plugins 1.4.15) Plugin Name: Example Plugin Commandline: Tested on operating system: Centos 5 Tested on architecture: i386 Tested with compiler: gcc ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=3319604&group_id=29880 From noreply at sourceforge.net Mon Jun 20 18:51:35 2011 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Jun 2011 12:51:35 -0400 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-3319604 ] check_icmp : disable rtmin/rtmax perfomance data Message-ID: Patches item #3319604, was opened at 2011-06-17 16:31 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=3319604&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: S?bastien Prud'homme () Assigned to: Nobody/Anonymous (nobody) Summary: check_icmp : disable rtmin/rtmax perfomance data Initial Comment: Patch against Plugin Version (-V output): check_icmp v1.4.15 (nagios-plugins 1.4.15) Plugin Name: Example Plugin Commandline: Tested on operating system: Centos 5 Tested on architecture: i386 Tested with compiler: gcc ---------------------------------------------------------------------- >Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2011-06-20 12:51 Message: Why would you want to disable perfdata items? I see no rational for this patch and it doesn't sounds like something that could be useful for the vast majority of users. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=3319604&group_id=29880 From noreply at sourceforge.net Thu Jun 23 13:32:18 2011 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Jun 2011 13:32:18 +0200 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3003419 ] check_snmp converts negative values to positive Message-ID: Bugs item #3003419, was opened at 2010-05-18 17:59 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3003419&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: Parsing problem Group: v1.4.14 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matt Rose (oesor) Assigned to: Nobody/Anonymous (nobody) Summary: check_snmp converts negative values to positive Initial Comment: When thresholds are defined, check_snmp converts negative integer snmp get values to positive: root at ops-00:/usr/local/nagios/libexec# ./check_snmp -V check_snmp v1.4.14 (nagios-plugins 1.4.14) root at ops-00:/usr/local/nagios/libexec# ./check_snmp -H 192.168.1.100 -o DEVICE-MIB::CurrentNoiseFloor.0 -w=~:-85 -c=~:-80 -vvvv /usr/bin/snmpget -t 1 -r 5 -m ALL -v 1 [authpriv] 192.168.1.100:161 DEVICE-MIB::CurrentNoiseFloor.0 DEVICE-MIB::CurrentNoiseFloor.0 = INTEGER: -97 Processing line 1 oidname: DEVICE-MIB::CurrentNoiseFloor.0 response: = INTEGER: -97 SNMP CRITICAL - *97* | DEVICE-MIB::CurrentNoiseFloor.0=97 root at ops-00:/usr/local/nagios/libexec# ./check_snmp -H 192.168.1.100 -o DEVICE-MIB::CurrentNoiseFloor.0 -vvvv /usr/bin/snmpget -t 1 -r 5 -m ALL -v 1 [authpriv] 192.168.1.100:161 DEVICE-MIB::CurrentNoiseFloor.0 DEVICE-MIB::CurrentNoiseFloor.0 = INTEGER: -97 Processing line 1 oidname: DEVICE-MIB::CurrentNoiseFloor.0 response: = INTEGER: -97 SNMP OK - -97 | DEVICE-MIB::CurrentNoiseFloor.0=-97 ---------------------------------------------------------------------- Comment By: Jan Sach () Date: 2011-06-23 13:32 Message: Also when defining warning and critical tresholds it doesn't work correctly when it comes to negative numbers: It is possible to set the negative infinity and negative integer - for example "~:-20" or set the negative infinity and positive integer: "~:15". That works as it should. But the combined treshold "-10:30" wrongly puts the value "-8" outside these limits, causing a warning or critical state (and the value "+8" is correctly considered to be inside). (note: I fixed the negative to positive perfdata converting bug using the advice in the 1st comment, but i ran into this treshold problem) I think it is important when fixing this bug to fix the tresholds parsing as well. The tresholds with both negative and positive limits are handy for temperature measurement, power to batteries (which could be negative when running from batteries and positive when charging them), etc. ---------------------------------------------------------------------- Comment By: Nobody (nobody42) Date: 2011-03-19 14:49 Message: The bug is located in line 404 of actual code 404 ptr = strpbrk (show, "0123456789"); should be changed to 404 ptr = strpbrk (show, "-0123456789"); 403 if (thlds[i]->warning || thlds[i]->critical || calculate_rate) { 404 ptr = strpbrk (show, "0123456789"); 405 if (ptr == NULL) Can someone fix please ? ---------------------------------------------------------------------- Comment By: Matt Rose (oesor) Date: 2010-05-18 18:20 Message: s/thresholds are defined/thresholds are triggered/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3003419&group_id=29880 From noreply at sourceforge.net Mon Jun 27 19:57:42 2011 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Jun 2011 13:57:42 -0400 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3314686 ] check_ntp_time and check_ntp_peers cannot find offset Message-ID: Bugs item #3314686, was opened at 2011-06-10 08:56 Message generated for change (Comment added) made by silfreed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3314686&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution >Group: release-1.4.15 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Douglas E. Warner (silfreed) Assigned to: Nobody/Anonymous (nobody) Summary: check_ntp_time and check_ntp_peers cannot find offset Initial Comment: I'm having a similar problem with the "offset unknown" that others have had in the past, although I'm running 1.4.14 of the plugins using check_ntp_time and check_ntp_peer. Below is the output of some of the commands. For some reason check_ntp_peer doesn't even seem to be able to find the peers, although check_ntp_time seems fine, but doesn't get the correct offset. # ntpdc -n -s localhost remote local st poll reach delay offset disp ======================================================================= 208.53.158.34 10.128.0.45 2 64 3 0.02493 -0.088040 1.98438 204.9.54.119 10.128.0.45 1 64 3 0.00943 -0.035220 1.98444 199.4.29.166 10.128.0.45 2 64 3 0.02950 -0.021567 1.98444 216.129.110.22 10.128.0.45 2 64 3 0.01813 -0.027695 1.98444 # /usr/lib/nagios/plugins/check_ntp_peer -H 127.0.0.1 -w 5 -c 10 -v 0 candiate peers available warning: no synchronization source found warning: LI_ALARM bit is set NTP CRITICAL: Server not synchronized, Offset unknown| # /usr/lib/nagios/plugins/check_ntp_time -H 127.0.0.1 -w 5 -c 10 -v sending request to peer 0 response from peer 0: offset 2.74181366e-06 sending request to peer 0 response from peer 0: offset -4.291534424e-06 sending request to peer 0 response from peer 0: offset -3.457069397e-06 sending request to peer 0 response from peer 0: offset -3.576278687e-06 discarding peer 0: stratum=0 overall average offset: 0 NTP CRITICAL: Offset unknown| ---------------------------------------------------------------------- >Comment By: Douglas E. Warner (silfreed) Date: 2011-06-27 13:57 Message: Confirmed this also exists w/ 1.4.15. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3314686&group_id=29880 From noreply at sourceforge.net Wed Jun 29 10:03:17 2011 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Jun 2011 10:03:17 +0200 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3343431 ] check_ide_smart: Invalid argument Message-ID: Bugs item #3343431, was opened at 2011-06-29 10:03 Message generated for change (Tracker Item Submitted) made by domibarton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3343431&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: release-1.4.15 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Domi Barton (domibarton) Assigned to: Nobody/Anonymous (nobody) Summary: check_ide_smart: Invalid argument Initial Comment: The check_ide_smart plugin fails on some disks w/ the following output: # ./check_ide_smart -n -d /dev/sda CRITICAL - SMART_ENABLE: Invalid argument CRITICAL - SMART_CMD_ENABLE But the disk is SMART capable: # smartctl -i /dev/sda smartctl version 5.33 [i686-redhat-linux-gnu] Copyright (C) 2002-4 Bruce Allen Home page is http://smartmontools.sourceforge.net/ Device: MAXTOR ATLAS10K4_36SCA Version: DFV0 Serial number: B2SM1QGM Device type: disk Transport protocol: Parallel SCSI (SPI-4) Local Time is: Wed Jun 29 10:02:31 2011 CEST Device supports SMART and is Enabled Temperature Warning Enabled ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3343431&group_id=29880