From listen2007 at lantschner.name Sun Jun 1 23:43:39 2008 From: listen2007 at lantschner.name (Ingo Lantschner) Date: Sun, 1 Jun 2008 23:43:39 +0200 Subject: [Nagiosplug-devel] How to know, which nagios-version calls a plugin? In-Reply-To: <483ED1A5.40002@op5.se> References: <46DE1BCE-B307-4D63-9142-000E9C4D6DEB@lantschner.name> <483ED1A5.40002@op5.se> Message-ID: Am 29.05.2008 um 17:54 schrieb Andreas Ericsson: > Although I must say I'm incredibly against a plugin that > will act one way when run by Nagios and another way when > run by an unsuspecting user from the command-prompt. good point ... > Is there no way the information can be distilled down to > some reasonably descriptive yet sufficiently short format? of course, there is - but if it's a customers wish, ... Thanks for your comments, Ingo From listen2007 at lantschner.name Sun Jun 1 23:45:38 2008 From: listen2007 at lantschner.name (Ingo Lantschner) Date: Sun, 1 Jun 2008 23:45:38 +0200 Subject: [Nagiosplug-devel] How to know, which nagios-version calls a plugin? In-Reply-To: <483ED544.60501@zango.com> References: <46DE1BCE-B307-4D63-9142-000E9C4D6DEB@lantschner.name> <483ED1A5.40002@op5.se> <483ED544.60501@zango.com> Message-ID: <94B89ADB-B841-4265-94AD-4CE89C5EB286@lantschner.name> Am 29.05.2008 um 18:09 schrieb Thomas Guyot-Sionnest: > As > long as we want to keep the plugin output simple I'd just add a > standard > switch for multi-line output (that would eventually be removed once > nagios 2 becomes deprecated). ok, lets do it this simple way - thanks, Ingo. From noreply at sourceforge.net Tue Jun 3 13:58:52 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jun 2008 04:58:52 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1878971 ] several typos Message-ID: Bugs item #1878971, was opened at 2008-01-24 16:44 Message generated for change (Comment added) made by cyco_dd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1878971&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 (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: several typos Initial Comment: the attached patch fixes several typos and was commited to Debian Nagios Maintainer Group. ---------------------------------------------------------------------- >Comment By: Jan Wagner (cyco_dd) Date: 2008-06-03 13:58 Message: Logged In: YES user_id=1345239 Originator: YES File Added: 50_misc_typos.dpatch ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2008-02-05 22:56 Message: Logged In: YES user_id=1345239 Originator: YES see also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=435525 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453012 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1878971&group_id=29880 From noreply at sourceforge.net Tue Jun 3 14:01:55 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jun 2008 05:01:55 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1878971 ] several typos Message-ID: Bugs item #1878971, was opened at 2008-01-24 16:44 Message generated for change (Comment added) made by cyco_dd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1878971&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 (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: several typos Initial Comment: the attached patch fixes several typos and was commited to Debian Nagios Maintainer Group. ---------------------------------------------------------------------- >Comment By: Jan Wagner (cyco_dd) Date: 2008-06-03 14:01 Message: Logged In: YES user_id=1345239 Originator: YES Is there anything blocking the commit ot the patch? Is there anythin what i can do to make it more easy? ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2008-06-03 13:58 Message: Logged In: YES user_id=1345239 Originator: YES File Added: 50_misc_typos.dpatch ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2008-02-05 22:56 Message: Logged In: YES user_id=1345239 Originator: YES see also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=435525 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453012 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1878971&group_id=29880 From waja at cyconet.org Tue Jun 3 15:04:42 2008 From: waja at cyconet.org (Jan Wagner) Date: Tue, 3 Jun 2008 15:04:42 +0200 Subject: [Nagiosplug-devel] different licenses (both gpl3) used Message-ID: <200806031504.45712.waja@cyconet.org> hi there, you have 2 different licenses used for your project. could you please verify if that is a bug or a feature? :) in detail: lib/*.c lib/tests/*.c plugins/*.c plugins/runcmd.h plugins/common.h plugins/netutils.h plugins-root/check_*.c gl/basename.c gl/cloexec.c gl/creat-safer.c gl/c-strtod.c gl/d* gl/e* gl/fcntl* gl/fd-safer.c gl/float.* gl/floorf.c gl/fsusage* gl/full* gl/gethostname.c gl/getloadavg.c gl/getopt* gl/intprops.h gl/math.in.h gl/mountlist* gl/open-safer.c gl/pipe-safer.c gl/safe-* gl/stdlib.in.h gl/strerror.c gl/stripslash.c gl/unistd-* gl/xalloc* gl/xmalloc.c gl/xstrndup* This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see gl/alloca.in.h gl/as* gl/base64* gl/config.charset gl/float+.h gl/gai_strerror.c gl/getaddrinfo* gl/gettext.h gl/inet_ntop* gl/localcharset* gl/malloc.c gl/netinet_in.in.h gl/printf-* gl/ref-* gl/reg* gl/size_max.h gl/snprintf.c gl/stdbool.in.h gl/stdint.in.h gl/stdio.in.h gl/strdup.c gl/string.in.h gl/strndup.c gl/strnlen.c gl/sys_socket.in.h gl/unistd.in.h gl/v* gl/wchar.in.h gl/wctype.in.h gl/xsize.h This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. thanks and with kind regards, jan. -- Never write mail to , you have been warned! -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GIT d-- s+: a- C+++ UL++++ P+ L+++ E- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++ ------END GEEK CODE BLOCK------ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thomas at zango.com Tue Jun 3 18:22:59 2008 From: thomas at zango.com (Thomas Guyot-Sionnest) Date: Tue, 03 Jun 2008 12:22:59 -0400 Subject: [Nagiosplug-devel] different licenses (both gpl3) used In-Reply-To: <200806031504.45712.waja@cyconet.org> References: <200806031504.45712.waja@cyconet.org> Message-ID: <48456FE3.30006@zango.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jan Wagner wrote: | hi there, | | you have 2 different licenses used for your project. could you please verify | if that is a bug or a feature? :) | | in detail: | | lib/*.c | lib/tests/*.c | plugins/*.c | plugins/runcmd.h | plugins/common.h | plugins/netutils.h | plugins-root/check_*.c | gl/basename.c | gl/cloexec.c | gl/creat-safer.c | gl/c-strtod.c | gl/d* | gl/e* | gl/fcntl* | gl/fd-safer.c | gl/float.* | gl/floorf.c | gl/fsusage* | gl/full* | gl/gethostname.c | gl/getloadavg.c | gl/getopt* | gl/intprops.h | gl/math.in.h | gl/mountlist* | gl/open-safer.c | gl/pipe-safer.c | gl/safe-* | gl/stdlib.in.h | gl/strerror.c | gl/stripslash.c | gl/unistd-* | gl/xalloc* | gl/xmalloc.c | gl/xstrndup* | | This program is free software: you can redistribute it and/or modify | it under the terms of the GNU General Public License as published by | the Free Software Foundation; either version 3 of the License, or | (at your option) any later version. | | This program is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | GNU General Public License for more details. | | You should have received a copy of the GNU General Public License | along with this program. If not, see | | gl/alloca.in.h | gl/as* | gl/base64* | gl/config.charset | gl/float+.h | gl/gai_strerror.c | gl/getaddrinfo* | gl/gettext.h | gl/inet_ntop* | gl/localcharset* | gl/malloc.c | gl/netinet_in.in.h | gl/printf-* | gl/ref-* | gl/reg* | gl/size_max.h | gl/snprintf.c | gl/stdbool.in.h | gl/stdint.in.h | gl/stdio.in.h | gl/strdup.c | gl/string.in.h | gl/strndup.c | gl/strnlen.c | gl/sys_socket.in.h | gl/unistd.in.h | gl/v* | gl/wchar.in.h | gl/wctype.in.h | gl/xsize.h | | This program is free software; you can redistribute it and/or modify it | under the terms of the GNU General Public License as published | by the Free Software Foundation; either version 3, or (at your option) | any later version. | | This program is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | General Public License for more details. | | You should have received a copy of the GNU General Public | License along with this program; if not, write to the Free Software | Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, | USA. | | thanks and with kind regards, jan. Everything in gl/ is installed by gnulib (which allows multiple licenses depending on the module). The core plugins are v3 or higher as some of the required gnulib libraries are now only available in v3. If you see differences in gl/ then you may bring is up to the gnulib mailing list. However I don't see much differences beside some wording. The GPL v3 is an official document and both license text specify to use GPL v3 or higher. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRW/j6dZ+Kt5BchYRAj/5AJ40T58XLbsG/DH8pFl+A2eMj9Qm6gCguBxx zwcft9cXFMVJKbj25t/l39w= =3Qi8 -----END PGP SIGNATURE----- From noreply at sourceforge.net Wed Jun 4 10:19:44 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jun 2008 01:19:44 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1984240 ] check_tcp Segmentation fault on HP-UX 11.23 Message-ID: Bugs item #1984240, was opened at 2008-06-04 10:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1984240&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: Wilfried Brunken (df7be) Assigned to: Nobody/Anonymous (nobody) Summary: check_tcp Segmentation fault on HP-UX 11.23 Initial Comment: Hello, compiled Plugins Version 1.4.12 with gcc (GCC) 4.1.1 the check_tcp cored at call (with no or any options) here comes the GDB Backtrace, i hope ths helps. 73 de DF7BE /usr/local/nagios/libexec> gdb check_tcp core HP gdb 3.1 for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00. Copyright 1986 - 2001 Free Software Foundation, Inc. Hewlett-Packard Wildebeest 3.1 (based on GDB) is covered by the GNU General Public License. Type "show copying" to see the conditions to change it and/or distribute copies. Type "show warranty" for warranty/support. .. Core was generated by `check_tcp'. Program terminated with signal 11, Segmentation fault. warning: The shared libraries were not privately mapped; setting a breakpoint in a shared library will not work until you rerun the program. Process ID is greater than 65535. #0 0xc06ba404 in pthread_mutex_lock+0x64 () from /usr/lib/libcma.2 (gdb) bt #0 0xc06ba404 in pthread_mutex_lock+0x64 () from /usr/lib/libcma.2 Cannot access memory at address 0xc06ba390 (gdb) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1984240&group_id=29880 From noreply at sourceforge.net Wed Jun 4 10:37:09 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jun 2008 01:37:09 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1984255 ] check_swap not build on UNIX Message-ID: Bugs item #1984255, was opened at 2008-06-04 10:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1984255&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: Wilfried Brunken (df7be) Assigned to: Nobody/Anonymous (nobody) Summary: check_swap not build on UNIX Initial Comment: Hello, on Solaris 10, HP-UX 11.11, 11.23 the Plugins was not build. The latest Version of this Plugin avaulable on HP-UX was: ./check_swap --version check_swap (nagios-plugins 1.4.6) 1.58 On Solaris 10: ./check_swap --version check_swap v1859 (nagios-plugins 1.4.11) I attached the config-Log of our HP-UX 11.23 Machine (PA-RISC 2.0 64bit) with gcc 4.1.1 73 de DF7BE ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1984255&group_id=29880 From noreply at sourceforge.net Thu Jun 5 10:46:09 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jun 2008 01:46:09 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1985230 ] check_snmp does not allow " chars in cmdline Message-ID: Bugs item #1985230, was opened at 2008-06-05 10:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985230&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: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: check_snmp does not allow " chars in cmdline Initial Comment: The following Bugreport we got against our debian package: snmpd can be queried for customized "extend"s. A configured extend like extend avail_mem /usr/local/bin/check_avail_mem.pl can be queried as snmpget -c public -v1 ds9 'nsExtendOutput1Line."avail_mem"' NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."avail_mem" = STRING: 749764 If you try to query this with check_snmp like check_snmp -H $HOSTADDRESS$ -C public -o 'nsExtendOutput1Line."syslog-idletime"' this results into Could not open pipe: /usr/bin/snmpget -t 1 -r 5 -m ALL -v 1 -c public ds9:161 nsExtendOutput1Line."syslog-idletime" Unfortuantely, check_snmp contains code in popen.c that does not allow any " chars in the command line and bails out with above error. I fixed this by commenting out the follwing block: --- popen.c.old 2008-01-12 14:16:39.000000000 +0100 +++ popen.c 2008-01-12 14:16:54.000000000 +0100 @@ -133,8 +133,10 @@ strcpy (cmd, cmdstring); /* This is not a shell, so we don't handle "???" */ +/* if (strstr (cmdstring, "\"")) return NULL; +*/ /* allow single quotes, but only if non-whitesapce doesn't occur on both sides */ if (strstr (cmdstring, " ' ") || strstr (cmdstring, "'''")) You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460405 Thanks and kind regards, Jan. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985230&group_id=29880 From noreply at sourceforge.net Thu Jun 5 11:16:37 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jun 2008 02:16:37 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1985246 ] ssh_disk dont interpret -C with single quotes correct Message-ID: Bugs item #1985246, was opened at 2008-06-05 11:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985246&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: ssh_disk dont interpret -C with single quotes correct Initial Comment: The following Bugreport we got against our debian package: By default, the ssh_disk configuration has the following command line... /usr/lib/nagios/plugins/check_by_ssh -H $HOSTADDRESS$ -C '/usr/lib/nagios/plugins/check_disk -w $ARG1$ -c $ARG2$ -p $ARG3$' This creates the following error when trying to check a remote system... [1179694002] SERVICE ALERT: tagboard;/dev/hda1 Free Space;UNKNOWN;SOFT;1;Could not open pipe: /usr/bin/ssh 172.24.32.1 '/usr/lib/nagios/plugins/check_disk -w 5% -c 3% -p "/dev/hda1"' Changing the single quotes to be double quotes in the config resolves this problem. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425312 Thanks and kind regards, Jan. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985246&group_id=29880 From noreply at sourceforge.net Thu Jun 5 11:29:31 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jun 2008 02:29:31 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1985263 ] check_ups doesn't disconnect cleanly Message-ID: Bugs item #1985263, was opened at 2008-06-05 11:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985263&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: check_ups doesn't disconnect cleanly Initial Comment: The following Bugreport we got against our debian package: everytime check_ups connects to my upsd, the following line is left in my syslog: Sep 11 17:39:09 holly upsd[15381]: Host 127.0.0.1 disconnected (read failure) What happens is that check_ups drops the connection to upsd as soon as it has queried for a variable. upsd expects 'LOGOUT' before terminating the connection, and happily writes "Client on 127.0.0.1 logged out" to syslog if it sees it. This is slightly annoying in conjunction with tools like logcheck: While I'm quite happy to ignore the "logged out" line in a upsd-specific rule, the word "failure" triggers a global logcheck rule and notifies me hour for hour. The attached patch should do away with this problem; check_ups works now fine in my installation. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387001 Thanks and kind regards, Jan. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985263&group_id=29880 From noreply at sourceforge.net Thu Jun 5 11:52:24 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jun 2008 02:52:24 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1985276 ] check_disk --local does not exclude cifs mounts Message-ID: Bugs item #1985276, was opened at 2008-06-05 11:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985276&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk --local does not exclude cifs mounts Initial Comment: The following Bugreport we got against our debian package: $ /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -l DISK WARNING - free space: / 142 MB (77% inode=85%); /dev/shm 92 MB (100% inode=99%); /mnt/usr 840 MB (73% inode=86%); /mnt/home 1055 MB (92% inode=99%); /mnt/var 1971 MB (58% inode=99%); /mnt/amanda 2487 MB (30% inode=99%); /tmp 92 MB (99% inode=99%); /media/linux-backup 56546 MB (13% inode=-);| /=41MB;154;173;0;193 /dev/shm=0MB;73;82;0;92 /mnt/usr=296MB;73;82;0;1196 /mnt/home=80MB;73;82;0;1196 /mnt/var=1406MB;73;82;0;3559 /mnt/amanda=5614MB;73;82;0;8535 /tmp=0MB;73;82;0;92 /media/linux-backup=355477MB;73;82;0;412023 The only filesystem that is below the warning threshold is /media/linux-back, which is not a local file system: $ grep linux-backup /proc/mounts //windows-server.domain.example/linux_backup$ /media/linux-backup cifs rw,mand,unc=\\windows-server.domain.example\linux_backup$,username=user,rsize=16384,wsize=57344 0 0 cifs mounts should be excluded if --local is used. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405539 Thanks and kind regards, Jan. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985276&group_id=29880 From noreply at sourceforge.net Thu Jun 5 12:47:18 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jun 2008 03:47:18 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1985317 ] check_ldap fails to report actual LDAP errors Message-ID: Bugs item #1985317, was opened at 2008-06-05 12:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985317&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: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: check_ldap fails to report actual LDAP errors Initial Comment: The following Bugreport we got against our debian package: The check_ldap plugin does this: % /usr/lib/nagios/plugins/check_ldap -H '' -b '' Could not bind to the ldap-server Whereas, tethereal reveals that the message received was: Lightweight Directory Access Protocol LDAP Message, Bind Result Message Id: 1 Message Type: Bind Result (0x01) Message Length: 64 Response To: 4 Time: 0.000067000 seconds Result Code: protocolError (0x02) Matched DN: (null) Error Message: historical protocol version requested, use LDAPv3 instead Now, why didn't check_ldap communicate that? Because it has this in the code (plugins/check_ldap.c): /* bind to the ldap server */ if (ldap_bind_s (ld, ld_binddn, ld_passwd, LDAP_AUTH_SIMPLE) != LDAP_SUCCESS) { /*ldap_perror(ld, "ldap_bind"); */ printf (_("Could not bind to the ldap-server\n")); return STATE_CRITICAL; } How hard was it to put that ldap_perror() string in the printf'ed error message? :( A quick grep for ldap_perror shows that there are other occurences of the same problem in the same file. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425137 Thanks and kind regards, Jan. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985317&group_id=29880 From noreply at sourceforge.net Thu Jun 5 13:11:43 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jun 2008 04:11:43 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1985338 ] perl plugins failure when run by embedded perl interpreter Message-ID: Bugs item #1985338, was opened at 2008-06-05 13:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985338&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: Embedded Perl failure Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: perl plugins failure when run by embedded perl interpreter Initial Comment: The following Bugreport we got against our debian package: When perl plugin scripts are run with the embedded perl interpreter in nagios3, the "shift" perl command doesn't shift @ARGV, but @_ (which happens to contain the same thing as @ARGV at the time the script was started). So, if we take the example of: /usr/lib/nagios/plugins/check_disk_smb we have: Getopt::Long::Configure('bundling'); GetOptions ("v" => \$verbose, "verbose" => \$verbose, [...] ($opt_H) || ($opt_H = shift) || usage("Host name not specified\n"); my $host = $1 if ($opt_H =~ /^([-_.A-Za-z0-9 ]+\$?)$/); The "GetOptions" will process the option part of @ARGV (not @_) and shift the processed arguments from there but will leave @_ untouched, so the "shift" above will return the first option, not the first argument after the options. with a /etc/nagios3/conf.d/local.cfg file containing: define service{ use generic-service ; Name of service template to use host_name localhost service_description SMB check_command check_disk_smb_user!host!share!me!mypasswd } You end up getting the status result of the check being: Invalid warning threshold: -H This is because the perl script is called with: -H host -s share -u me -p mypasswd The -w option is not provided, so: ($opt_w) || ($opt_w = shift) || ($opt_w = 85); my $warn = $1 if ($opt_w =~ /^([0-9]{1,2}\%?|100\%?|[0-9]+[kMG])$/); ($warn) || usage("Invalid warning threshold: $opt_w\n"); sets $opt_w to the first item in @_ (instead of @ARGV), that is "-H" instead of "85" (as @ARGV is empty at that point). A fix is to replace all the instances of "shift" with "shift @ARGV". Other perl plugins are affected by that. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478906 Thanks and kind regards, Jan. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985338&group_id=29880 From noreply at sourceforge.net Thu Jun 5 13:34:32 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jun 2008 04:34:32 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1090549 ] check_dhcp ignores DHCP replies Message-ID: Bugs item #1090549, was opened at 2004-12-23 21:21 Message generated for change (Comment added) made by tigalch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1090549&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: CVS Status: Open Resolution: None Priority: 5 Private: No Submitted By: Laurentiu C. Badea (L.C.) (wotevah) Assigned to: Ethan Galstad (egalstad) Summary: check_dhcp ignores DHCP replies Initial Comment: check_dhcp ignores the DHCP replies apparently because they are broadcast to 255.255.255.255. .bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from , length: 548, flags: [Broadcast] .bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 420, flags: [Broadcast] (0x8000) I believe the problem may be that recvfrom is not expecting a possible broadcast packet in response, so it ignores it. Relevant part from strace below: sendto(3, , 548, 0, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("255.255.255.255")}, 16) = 548 time([1103833074]) = 1103833074 time([1103833074]) = 1103833074 select(4, [3], NULL, NULL, {2, 0}) = 1 (in [3], left {1, 999000}) recvfrom(3, 0xfef67370, 548, 2, 0xfef67280, 0xfef67274) = -1 EINVAL (Invalid argument) recvfrom(3, 0xfef67370, 548, 0, 0xfef67280, 0xfef67274) = -1 EINVAL (Invalid argument) Client is Fedora Core 2 with nagios-plugins-1.3.1-10.1.fc2.dag. Server is Red Hat 9 with dhcp-3.0pl1-23. ---------------------------------------------------------------------- Comment By: tigalch (tigalch) Date: 2008-06-05 13:34 Message: Logged In: YES user_id=2108467 Originator: NO Hello, I would like to know if a solution to this problem is allready available or will be available soon? With the most recent plugins (1.4.12)the problem still remains. thanks and regards ---------------------------------------------------------------------- Comment By: liosme (lisme) Date: 2007-07-26 22:49 Message: Logged In: YES user_id=1854343 Originator: NO hello, i want to know if you resolv the problem with check_dhcp. I have tha same problem it is: ============================================ [root at desarrollo libexec]# ./check_dhcp -v DHCP socket: 3 Hardware address: 00e07dd6dd58 DHCPDISCOVER to 255.255.255.255 port 68 DHCPDISCOVER XID: 116527212 (0x6F2106C) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 0.0.0.0 send_dhcp_packet result: 548 No (more) data received Result=ERROR Total responses seen on the wire: 0 Valid responses for this machine: 0 CRITICAL: No DHCPOFFERs were received. ========================================= i use fedora 4 nagios 3.0a4 and plugin 1.4.7 if you resolv this problem with check_dhcp, woud you tell me how you resolv this. or explained more please. ---------------------------------------------------------------------- Comment By: Loic Dachary (loic) Date: 2007-05-20 23:53 Message: Logged In: YES user_id=1537 Originator: NO I experienced the problem today. On debian etch. I'm running check_dhcp and the dhcp server on the same interface. The dhcp server otherwise runs fine. strace /usr/lib/nagios/plugins/check_dhcp -s dhcp.dmz.tld -i eth2 ... read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\26"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=78500, ...}) = 0 mmap2(NULL, 81456, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7c17000 mmap2(0xb7c2a000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12) = 0xb7c2a000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7c16000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7c15000 mprotect(0xb7d57000, 20480, PROT_READ) = 0 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7c156c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 munmap(0xb7f04000, 8510) = 0 brk(0) = 0x804f000 brk(0x8070000) = 0x8070000 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 setsockopt(3, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0 setsockopt(3, SOL_SOCKET, SO_BINDTODEVICE, "eth2\0\0\0\0\0\0\0\0\0\0\0\0\17\0\0\0\4\0\0\0\5\0\0\0$"..., 32) = 0 bind(3, {sa_family=AF_INET, sin_port=htons(68), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 ioctl(3, SIOCGIFHWADDR, {ifr_name="eth2", ifr_hwaddr=00:13:72:40:39:0a}) = 0 time(NULL) = 1179697853 sendto(3, "\1\1\6\0b\\:\347\377\0\200\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 548, 0, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("255.255.255.255")}, 16) = 548 time([1179697853]) = 1179697853 time([1179697853]) = 1179697853 select(4, [3], NULL, NULL, {2, 0}) = 0 (Timeout) time([1179697855]) = 1179697855 close(3) = 0 fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 11), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f06000 write(1, "CRITICAL: No DHCPOFFERs were rec"..., 39CRITICAL: No DHCPOFFERs were received. ) = 39 munmap(0xb7f06000, 4096) = 0 exit_group(2) = ? Process 15586 detached ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-20 16:35 Message: Logged In: YES user_id=1694341 Originator: NO Hi all, I'm setting this one back to Resolution: None, because reuben's problem is reproducable using the cvs version for me. First i didn't get dhcpd to send a reply at all. That was caused by incorrect udp checksums which dhcpd didn't like. So I switched off checksum offloading in the network driver and finally came into reuben's situation. So I did some investigations and have following notes now: - problem encounters if check_dhcp is run from the same system serving dhcp - the select times out according to strace - offers are sent according to tcpdump/ethereal - dhcpcd-test works flawlessly - check_dhcp works on remote system The fact that select times out makes me think that no data actually arrives at the socket. If two servers are online, i get only the response from the remote server. One more thing I noticed is that dhcpcd-test sends discovers with source ip 0.0.0.0 but the offers are sent to the offered destination ip. A dest-ip the client doesn't even know - and cannot bind a socket on. I can't imagine how this works at all. Any hints? Matthias ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2007-05-19 15:42 Message: Logged In: YES user_id=26209 Originator: NO Yes seems that the issue still persists: tornado libexec # ./check_dhcp -v -i vlan10 -s 192.168.10.12 Requested server address: 192.168.10.12 DHCP socket: 3 Hardware address: 001676ce4a2c DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 348330319 (0x14C3194F) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 0.0.0.0 send_dhcp_packet result: 548 No (more) data received Result=ERROR Total responses seen on the wire: 0 Valid responses for this machine: 0 CRITICAL: No DHCPOFFERs were received. tornado libexec # Meanwhile, the server logged: May 19 23:34:51 tornado dhcpd: DHCPDISCOVER from 00:16:76:ce:4a:2c via vlan10 May 19 23:34:51 tornado dhcpd: DHCPOFFER on 192.168.10.24 to 00:16:76:ce:4a:2c via vlan10 Running just: ./check_dhcp results in a "CRITICAL: No DHCPOFFERs were received" message. I'm now running Gentoo not Fedora, but I gather that's probably not that critical anyway. I have a second, FC6 system which I manage which exhibits the same problem with this plugin (it doesn't use a vlan interface either, it has only a single eth0 e100 NIC in it). reuben ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-18 13:14 Message: Logged In: YES user_id=1694341 Originator: NO sent an email to reuben, to ask if the problem still persists ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2006-05-28 15:29 Message: Logged In: YES user_id=26209 In my case the problem seems to be caused by the plugin being run on the *same system* as the DHCP server. I did raise this earlier but I don't think it was investigated and obviously not fixed. Regardless, that is still the case and seems to be the cause of the problem for me. ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2006-05-26 06:32 Message: Logged In: YES user_id=26209 Nope, still broken for me with current CVS. The DHCP server offers the lease but it is not responded to..and the check_dhcp test fails. I'll do some more looking into this this weekend. ---------------------------------------------------------------------- Comment By: Ethan Galstad (egalstad) Date: 2006-05-25 20:11 Message: Logged In: YES user_id=2225 Based on previous comments, it looks like this was already fixed in CVS a while ago... ---------------------------------------------------------------------- Comment By: Ethan Galstad (egalstad) Date: 2006-05-25 19:57 Message: Logged In: YES user_id=2225 Can the folks who were experiencing this problem please check out the latest CVS version of check_dhcp? If I don't hear any problem reports in the next few weeks, I'll be closing this item. Thanks! ---------------------------------------------------------------------- Comment By: Laurentiu C. Badea (L.C.) (wotevah) Date: 2005-02-08 09:33 Message: Logged In: YES user_id=724669 Right. I *should have* tried the CVS. I compiled it on my dev box (FC3), copied it to my FC2 machine and it worked fine there. So I suppose the bug isn't all that, now. But that made me curious. I went and got each previous revision of check_dhcp.c, recompiled and they all worked. So I suspected a problem in Dag's rpm package. I copied the "bad" binary to another FC2 machine and there it works. The only difference is an SMP kernel where it failed, and the UP kernel (same version) on the other. But that's just useless trivia now I suppose since the version compiled by hand works either way. ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2005-02-08 00:17 Message: Logged In: YES user_id=395628 Dear Laurentiu, I think you are correct there are _two_ problems. I think that one has been dealt with (ie packet filtering and or alias interface misbehaviour). I agree with your analysis - why should recv() fail when select says the read handle is ready for reading. Are you familair with gdb ? A gdb session with check_dhcp is the way to deal with this. recvfrom(3, 0xfef67370, 548, 2, 0xfef67280, 0xfef67274) socket, pointer to buffer, buffer len, flags, pointer to from and pointer to from len. I guess that 2 is MSG_PEEK (from the notes in the text). Is 2 the value of MSG_PEEK on your system. Hey ! The plugin is 1.3. You must try the CVS. Yours sincerely. ---------------------------------------------------------------------- Comment By: Laurentiu C. Badea (L.C.) (wotevah) Date: 2005-02-07 19:45 Message: Logged In: YES user_id=724669 I have to apologize, I haven't been monitoring this report (I was kind of hoping SF would send notification emails on activity, but it didn't). Anyway, I noticed a difference between my strace and the others, that may be significant. Specifically, the select() call returns with data on the socket in my version (but the recvfrom still fails!), while it times out in the others. So we may be dealing with two different problems here. Yes, exactly what you wanted to hear, isn't it... I'll try the CVS version later on tonight and let you know. ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-24 11:48 Message: Logged In: YES user_id=26209 Ok it's a flat topology: * Single switch * Single router, with 192.168.0.1 internally, 60.234.x.x address externally doing NAT * Single Linux server, 2.6.11-rc1-mm2 (at the moment), with eth0 (192.168.0.3) eth0:0 (192.168.0.4) gre0 (172 address) and a loopback. The machine has only one NIC. Clients are also on the 192.168.0.0/24 network. Simple home network ;-) dhcpd is not bound to any particular interface, but when I shut down gre0 and eth0:0 and then restarted dhcpd to avoid binding problems, same result when running check_dhcp :( Jan 24 23:08:03 tornado dhcpd: Internet Systems Consortium DHCP Server V3.0.2rc3 Jan 24 23:08:03 tornado dhcpd: Copyright 2004 Internet Systems Consortium. Jan 24 23:08:03 tornado dhcpd: All rights reserved. Jan 24 23:08:03 tornado dhcpd: For info, please visit http://www.isc.org/sw/dhcp/ Jan 24 23:08:03 tornado dhcpd: Internet Systems Consortium DHCP Server V3.0.2rc3 Jan 24 23:08:03 tornado dhcpd: Copyright 2004 Internet Systems Consortium. Jan 24 23:08:03 tornado dhcpd: All rights reserved. Jan 24 23:08:03 tornado dhcpd: For info, please visit http://www.isc.org/sw/dhcp/ Jan 24 23:08:03 tornado dhcpd: Wrote 0 deleted host decls to leases file. Jan 24 23:08:03 tornado dhcpd: Wrote 0 new dynamic host decls to leases file. Jan 24 23:08:03 tornado dhcpd: Wrote 4 leases to leases file. Jan 24 23:08:03 tornado dhcpd: Listening on LPF/eth0/00:0d:61:5e:8b:b3/192.168.0.0/24 Jan 24 23:08:03 tornado dhcpd: Sending on LPF/eth0/00:0d:61:5e:8b:b3/192.168.0.0/24 Jan 24 23:08:03 tornado dhcpd: Sending on Socket/fallback/fallback-net Jan 24 23:13:03 tornado dhcpd: DHCPDISCOVER from 00:0d:61:5e:8b:b3 via eth0 Jan 24 23:13:04 tornado dhcpd: DHCPOFFER on 192.168.0.11 to 00:0d:61:5e:8b:b3 via eth0 ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2005-01-24 11:31 Message: Logged In: YES user_id=395628 Thanks very much for your comment Reuben. Please would you consider letting me know 1 whether eth0:0 is a 'virtual' interface ? Does the host running check dhcp have two (2) NICs ? 2 try and sketch the topology for me Is it | |--------- check_dhcp/dhcpd --------| | etho eth1 | | some other /x |------------ router 192.168.0.0/24 ? Which interface is dhcpd bound to ? You are welcome to write me direct (SHopcroft at IPAustralia.Gov.AU) if that's more convenient. Thank you. ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-24 11:09 Message: Logged In: YES user_id=26209 I've just down'ed eth0:0 and restarted dhcpd, still same result....... :( Router is connected to 192.168.0.0/24 and external (routable) IP address only. ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2005-01-24 11:04 Message: Logged In: YES user_id=395628 Firstly, a very heart felt thank you to zytak and reuben for their willingness to test, listen to my silly remarks and retest. This release owes a lot to both gentlemen. (your initiative also saved you hearing more silly remarks such as did you regen configure ? ...) All ones (ie 255.255.255.255) broadcasts has some 'minor gotchas' that appear to be evident here. (See Unix Network Programming vol 1 p 471-2) I think what is happening is that 1 check_dhcp broadcasts are only being sent from the primary (eth0) interface and are being transformed from 'all-ones' to 'subnet-directed' broadcast (the broadcast ip address of eth0). 2 your dhcp server is replying with a broadcast on _that_ prefix network which your secondary interface - check_dhcp - is not connected to. Presumably, your router is connected to both LANs and will reply on _all_ interfaces - since some OS's replicate broadcasts on _all_ their interfaces. Thanks very much for your comments. Will update the usage information ... ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-24 10:12 Message: Logged In: YES user_id=26209 Ok, some progress. If I serve up DHCP from my cisco router with dhcpd off on my server, check_dhcp works just fine: [root at tornado ~]# /usr/lib/nagios/plugins/check_dhcp DHCP ok: Received 1 DHCPOFFER(s), max lease time = 86400 sec. If I then turn dhcp off on the router and re-enable dhcpd on my server, it fails again. So it appears that running check_dhcp from the same host as the dhcp server is a no-go, at least in my case......... ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-24 10:02 Message: Logged In: YES user_id=26209 I still experience the problem even with my iptables rules off: [root at tornado nagiosplug]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination [root at tornado nagiosplug]# iptables -t nat -L Chain PREROUTING (policy ACCEPT) target prot opt source destination DNAT tcp -- network.reub.net/16 !network.reub.net/16 tcp dpt:http to:192.168.0.3:3128 Chain POSTROUTING (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination [root at tornado nagiosplug]# Other possible ideas: * I have two IP addresses, a main and a secondary IP address on eth0(:0) * My server which does the monitoring also does DHCP If I can come up with anything I'll post here. ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-24 09:59 Message: Logged In: YES user_id=26209 Firstly, can I confirm that sourceforge CVS has the most current version? Latest CVS has: $Id: check_dhcp.c,v 1.6 2004/12/30 00:41:39 opensides Exp $ I don't think your latest changes have made it into the publically visible repo :( Here's an strace: [root at tornado nagiosplug]# strace /usr/lib/nagios/plugins/check_dhcp execve("/usr/lib/nagios/plugins/check_dhcp", ["/usr/lib/nagios/plugins/check_dhcp"], [/* 22 vars */]) = 0 uname({sys="Linux", node="tornado", ...}) = 0 brk(0) = 0x804e000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=39607, ...}) = 0 old_mmap(NULL, 39607, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ff6000 close(3) = 0 open("/lib/libnsl.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320D\7"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=97608, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ff5000 old_mmap(0x4b071000, 88064, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4b071000 old_mmap(0x4b083000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11000) = 0x4b083000 old_mmap(0x4b085000, 6144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4b085000 close(3) = 0 open("/lib/libresolv.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\343"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=81252, ...}) = 0 old_mmap(0x4b02c000, 75944, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4b02c000 old_mmap(0x4b03b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf000) = 0x4b03b000 old_mmap(0x4b03d000, 6312, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4b03d000 close(3) = 0 open("/lib/tls/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \277\353"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1521596, ...}) = 0 old_mmap(0x4aea7000, 1215644, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4aea7000 old_mmap(0x4afca000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x123000) = 0x4afca000 old_mmap(0x4afce000, 7324, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4afce000 close(3) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ff4000 mprotect(0x4afca000, 8192, PROT_READ) = 0 mprotect(0x4b03b000, 4096, PROT_READ) = 0 mprotect(0x4b083000, 4096, PROT_READ) = 0 mprotect(0x4aea3000, 4096, PROT_READ) = 0 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7ff46c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 munmap(0xb7ff6000, 39607) = 0 open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=39591472, ...}) = 0 mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7df4000 mmap2(NULL, 204800, PROT_READ, MAP_PRIVATE, 3, 0x1029) = 0xb7dc2000 brk(0) = 0x804e000 brk(0x806f000) = 0x806f000 mmap2(NULL, 4096, PROT_READ, MAP_PRIVATE, 3, 0x1072) = 0xb7dc1000 close(3) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 setsockopt(3, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0 setsockopt(3, SOL_SOCKET, SO_BINDTODEVICE, "eth0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\264\356\377\277\370"..., 32) = 0 bind(3, {sa_family=AF_INET, sin_port=htons(68), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 ioctl(3, SIOCGIFHWADDR, 0xbfffedd0) = 0 time(NULL) = 1106556165 sendto(3, "\1\1\6\0\34|\211\212\377\0\200\0\0\0\0\0\0\0\0\0\0\0\0"..., 548, 0, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("255.255.255.255")}, 16) = 548 time([1106556165]) = 1106556165 time([1106556165]) = 1106556165 select(4, [3], NULL, NULL, {2, 0}) = 0 (Timeout) time([1106556167]) = 1106556167 close(3) = 0 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7dc0000 open("/usr/share/locale/locale.alias", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=2528, ...}) = 0 mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7da0000 read(3, "# Locale name alias data base.\n#"..., 131072) = 2528 read(3, "", 131072) = 0 close(3) = 0 munmap(0xb7da0000, 131072) = 0 open("/usr/share/nagios/locale/en_US/LC_MESSAGES/nagios-plugins.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/nagios/locale/en/LC_MESSAGES/nagios-plugins.mo", O_RDONLY) = -1 ENOENT (No such file or directory) write(1, "DHCP problem: No DHCPOFFERs were"..., 43DHCP problem: No DHCPOFFERs were received. ) = 43 munmap(0xb7dc0000, 4096) = 0 exit_group(2) = ? [root at tornado nagiosplug]# Also: [root at tornado nagiosplug]# /usr/lib/nagios/plugins/check_dhcp -v DHCP socket: 3 Hardware address: 000d615e8bb3 DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 842612958 (0x323940DE) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 0.0.0.0 send_dhcp_packet result: 548 No (more) data received Result=ERROR Total responses seen on the wire: 0 Valid responses for this machine: 0 DHCP problem: No DHCPOFFERs were received. [root at tornado nagiosplug]# ---------------------------------------------------------------------- Comment By: zyta2k (zyta2k) Date: 2005-01-24 09:48 Message: Logged In: YES user_id=544197 Wooooops :/ Shame on me =) flushed all iptables rules and now it works... The "strange thing" is: dhcp is fully functional if I use the same rulebase !! Here are the rules ---- schnippi ---- Chain INPUT (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere anywhere Chain FORWARD (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain RH-Firewall-1-INPUT (2 references) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT icmp -- anywhere anywhere icmp any ACCEPT ipv6-crypt-- anywhere anywhere ACCEPT ipv6-auth-- anywhere anywhere ACCEPT udp -- anywhere 224.0.0.251 udp dpt:5353 ACCEPT udp -- anywhere anywhere udp dpt:ipp ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ftp ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh REJECT all -- anywhere anywhere reject-with icmp-host-prohibited ---- schnappi ---- ?m... no idea which rule stops the check_dhcp plug... :/ ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2005-01-24 03:57 Message: Logged In: YES user_id=395628 Dear Folks, I am perplexed about this problem. 1 the open socket won't ignore a broadcast reply with the dhcp client port unless the reply is filtered by some kernel packet filter (iptable on Linux ?), or there is a firewall or router between the client and server. Given the PRs this doesn't seem likely. 2 the failure is however consistent with L.C's (Laurentiu C. Badea) PR showing EINVAL from the recvfrom call. Please would either L.C., Rueben Farrelly or zyta2k do an strace or equivalent (truss/ktrace ?) to show if recvfrom is still returning -1/EINVAL from a CVS copy (not many changes from L.C's report of the prob with the 1.3 plugins but its nice to be sure) EINVAL seems to suggest an argument problem but I can't imagine what this may be - the parms seem fine. Thank you. ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2005-01-21 10:35 Message: Logged In: YES user_id=395628 Thank you for a superb PR. Unfortunately, this is unlikely to help you much but would you please try the latest CVS (not tar ball) and post your command invocation (changes have been made to get it to build properly on Linux and FreeBSD - you seem to have done this yourself). On FreeBSD 4.10 and ISC dhcpd (V3.0.1rc14), it works Ok. The reply to the discover should be a broadcast (methinks) since the client has no ip. Thanks for your help. ---------------------------------------------------------------------- Comment By: zyta2k (zyta2k) Date: 2005-01-04 11:41 Message: Logged In: YES user_id=544197 I can confirm the problem... === Verbose Output From Plugin === DHCP socket: 3 Hardware address: 00110a32c75e DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 1269450911 (0x4BAA489F) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 0.0.0.0 send_dhcp_packet result: 548 No (more) data received Result=ERROR Total responses seen on the wire: 0 Valid responses for this machine: 0 DHCP problem: No DHCPOFFERs were received. ============= TCPDUMP ============ # tcpdump -vv dst port 68 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 11:25:54.418410 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto 17, length: 341) dhcp01.foobar.com > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 313, xid:0x4baa489f, secs:65280, flags: [Broadcast] (0x8000) Your IP: 10.29.20.121 Server IP: dhcp01.foobar.com Gateway IP: 10.29.20.2 Client Ethernet Address: 00:11:0a:32:c7:5e [|bootp] 11:25:54.418675 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto 17, length: 341) dhcp01.foobar.com.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 313, xid:0x4baa489f, secs:65280, flags: [Broadcast] (0x8000) Your IP: 10.29.20.121 Server IP: dhcp01.foobar.com Gateway IP: 10.29.20.3 Client Ethernet Address: 00:11:0a:32:c7:5e [|bootp] 11:25:54.418975 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto 17, length: 341) dhcp02.foobar.com.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 313, xid:0x4baa489f, secs:65280, flags: [Broadcast] (0x8000) Your IP: 10.29.20.143 Server IP: dhcp02.foobar.com Gateway IP: 10.29.20.2 Client Ethernet Address: 00:11:0a:32:c7:5e [|bootp] 11:25:54.421156 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto 17, length: 341) dhcp02.foobar.com.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 313, xid:0x4baa489f, secs:65280, flags: [Broadcast] (0x8000) Your IP: 10.29.20.143 Server IP: dhcp02.foobar.com Gateway IP: 10.29.20.3 Client Ethernet Address: 00:11:0a:32:c7:5e [|bootp] 4 packets captured 4 packets received by filter 0 packets dropped by kernel ========== MY SYSTEM ============= Distribution: Fedora Core 3 Kernel: 2.6.9 Glibc: 2.3.4 Plugin Version: CVS v 1.6 2004/12/30 00:41:39 hth zyta2k ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-02 21:48 Message: Logged In: YES user_id=26209 Still no go here either using bleeding edge CVS (on FC3): sendto(3, "\1\1\6\0\6\372\275\241\377\0\200\0\0\0\0\0\0\0\0\0\0\0"..., 548, 0, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("255.255.255.255")}, 16) = 548 time([1104698558]) = 1104698558 time([1104698558]) = 1104698558 select(4, [3], NULL, NULL, {2, 0}) = 0 (Timeout) time([1104698560]) = 1104698560 close(3) = 0 Returns with "DHCP problem: No DHCPOFFERs were received." Meanwhile the DHCP server has seen the DHCPDISCOVER come in and DHCPOFFER'ed an address to 255.255.255.255.bootpc ---------------------------------------------------------------------- Comment By: Benoit Mortier (opensides) Date: 2005-01-02 19:42 Message: Logged In: YES user_id=388184 Hi, could you test with the lastest cvs, and report your findings Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1090549&group_id=29880 From noreply at sourceforge.net Thu Jun 5 13:56:17 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jun 2008 04:56:17 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1985338 ] perl plugins failure when run by embedded perl interpreter Message-ID: Bugs item #1985338, was opened at 2008-06-05 13:11 Message generated for change (Comment added) made by cyco_dd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985338&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: Embedded Perl failure Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: perl plugins failure when run by embedded perl interpreter Initial Comment: The following Bugreport we got against our debian package: When perl plugin scripts are run with the embedded perl interpreter in nagios3, the "shift" perl command doesn't shift @ARGV, but @_ (which happens to contain the same thing as @ARGV at the time the script was started). So, if we take the example of: /usr/lib/nagios/plugins/check_disk_smb we have: Getopt::Long::Configure('bundling'); GetOptions ("v" => \$verbose, "verbose" => \$verbose, [...] ($opt_H) || ($opt_H = shift) || usage("Host name not specified\n"); my $host = $1 if ($opt_H =~ /^([-_.A-Za-z0-9 ]+\$?)$/); The "GetOptions" will process the option part of @ARGV (not @_) and shift the processed arguments from there but will leave @_ untouched, so the "shift" above will return the first option, not the first argument after the options. with a /etc/nagios3/conf.d/local.cfg file containing: define service{ use generic-service ; Name of service template to use host_name localhost service_description SMB check_command check_disk_smb_user!host!share!me!mypasswd } You end up getting the status result of the check being: Invalid warning threshold: -H This is because the perl script is called with: -H host -s share -u me -p mypasswd The -w option is not provided, so: ($opt_w) || ($opt_w = shift) || ($opt_w = 85); my $warn = $1 if ($opt_w =~ /^([0-9]{1,2}\%?|100\%?|[0-9]+[kMG])$/); ($warn) || usage("Invalid warning threshold: $opt_w\n"); sets $opt_w to the first item in @_ (instead of @ARGV), that is "-H" instead of "85" (as @ARGV is empty at that point). A fix is to replace all the instances of "shift" with "shift @ARGV". Other perl plugins are affected by that. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478906 Thanks and kind regards, Jan. ---------------------------------------------------------------------- >Comment By: Jan Wagner (cyco_dd) Date: 2008-06-05 13:56 Message: Logged In: YES user_id=1345239 Originator: YES the attached fix should solve the issue (just) in this plugin File Added: fix_emb_check_disk_smb.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985338&group_id=29880 From noreply at sourceforge.net Thu Jun 5 16:12:36 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jun 2008 07:12:36 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1985489 ] check_ldap doesn't allow empty bases Message-ID: Bugs item #1985489, was opened at 2008-06-05 16:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985489&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: check_ldap doesn't allow empty bases Initial Comment: The following Bugreport we got against our debian package: Hiya, $ /usr/lib/nagios/plugins/check_ldap -H localhost -b '' check_ldap: Please specify the LDAP base doesn't work. For me, a check with an empty base seems like the most obvious thing to do. So I don't understand why it is explicitely disallowed in the code (note that the error message is also confusing) A simple fix: --- plugins/check_ldap.c-before-base-fix 2008-05-07 11:32:13.000000000 +0100 +++ plugins/check_ldap.c 2008-05-07 11:34:50.000000000 +0100 @@ -374,7 +374,7 @@ validate_arguments () if (ld_host==NULL || strlen(ld_host)==0) usage4 (_("Please specify the host name\n")); - if (ld_base==NULL || strlen(ld_base)==0) + if (ld_base == NULL) usage4 (_("Please specify the LDAP base\n")); return OK; The similar check for strlen(ld_host) could be removed as well, because if ld_host is "", it's because the user specified -H '', so did specify the hostname, so that the error message is misleading. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479984 Thanks and kind regards, Jan. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985489&group_id=29880 From noreply at sourceforge.net Thu Jun 5 16:14:48 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jun 2008 07:14:48 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1985492 ] check_disk wrongly treats devices as being NFS shares Message-ID: Bugs item #1985492, was opened at 2008-06-05 16:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985492&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk wrongly treats devices as being NFS shares Initial Comment: The following Bugreport we got against our debian package: Hiya, check_disk -l or -L is meant to check only the local file systems, so it excludes the NFS mounted ones. But to do so, it checks whether the "mount device" contains a ":" instead of checking the filesystem type. For instance, that means that it won't check filesystems on local devices that have ":" in their path. Example: /dev/mapper/vol-snaphost-2008-04-30-08:00:00 You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479045 Thanks and kind regards, Jan. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985492&group_id=29880 From noreply at sourceforge.net Fri Jun 6 12:02:20 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 Jun 2008 03:02:20 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1985338 ] perl plugins failure when run by embedded perl interpreter Message-ID: Bugs item #1985338, was opened at 2008-06-05 13:11 Message generated for change (Comment added) made by cyco_dd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985338&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: Embedded Perl failure Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: perl plugins failure when run by embedded perl interpreter Initial Comment: The following Bugreport we got against our debian package: When perl plugin scripts are run with the embedded perl interpreter in nagios3, the "shift" perl command doesn't shift @ARGV, but @_ (which happens to contain the same thing as @ARGV at the time the script was started). So, if we take the example of: /usr/lib/nagios/plugins/check_disk_smb we have: Getopt::Long::Configure('bundling'); GetOptions ("v" => \$verbose, "verbose" => \$verbose, [...] ($opt_H) || ($opt_H = shift) || usage("Host name not specified\n"); my $host = $1 if ($opt_H =~ /^([-_.A-Za-z0-9 ]+\$?)$/); The "GetOptions" will process the option part of @ARGV (not @_) and shift the processed arguments from there but will leave @_ untouched, so the "shift" above will return the first option, not the first argument after the options. with a /etc/nagios3/conf.d/local.cfg file containing: define service{ use generic-service ; Name of service template to use host_name localhost service_description SMB check_command check_disk_smb_user!host!share!me!mypasswd } You end up getting the status result of the check being: Invalid warning threshold: -H This is because the perl script is called with: -H host -s share -u me -p mypasswd The -w option is not provided, so: ($opt_w) || ($opt_w = shift) || ($opt_w = 85); my $warn = $1 if ($opt_w =~ /^([0-9]{1,2}\%?|100\%?|[0-9]+[kMG])$/); ($warn) || usage("Invalid warning threshold: $opt_w\n"); sets $opt_w to the first item in @_ (instead of @ARGV), that is "-H" instead of "85" (as @ARGV is empty at that point). A fix is to replace all the instances of "shift" with "shift @ARGV". Other perl plugins are affected by that. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478906 Thanks and kind regards, Jan. ---------------------------------------------------------------------- >Comment By: Jan Wagner (cyco_dd) Date: 2008-06-06 12:02 Message: Logged In: YES user_id=1345239 Originator: YES File Added: 33_fix_emb_check_disk_smb.dpatch ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2008-06-05 13:56 Message: Logged In: YES user_id=1345239 Originator: YES the attached fix should solve the issue (just) in this plugin File Added: fix_emb_check_disk_smb.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985338&group_id=29880 From noreply at sourceforge.net Fri Jun 6 12:39:39 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 Jun 2008 03:39:39 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1986260 ] check_disk_smb and no-user or no-passwd or share with spaces Message-ID: Bugs item #1986260, was opened at 2008-06-06 12:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1986260&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: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk_smb and no-user or no-passwd or share with spaces Initial Comment: The following Bugreport we got against our debian package: [...] What that means is that if any of the ARGS contain any character special to the shell (space, tab, nl, "$^&*()[;'#~<>?...) or if they are empty, that will break. [...] Next, the check_disk_smb perl script itself has a similar problem when running the smbclient command. It runs: $res = qx/$smbclient "\/\/$host\/$share" $pass -W $workgroup -U $user $smbclientoptions -I $address -c ls/; qx/.../ (same as `...`) runs a shell in a same way. The documentation says that if the password is not passed, it defaults to "". That is not true above, as $pass expands to nothing which leaves no argument at all (instead of an empty argument) so is different from providing with an empty password or with the -N option. Also, if the password starts with "-", you're in trouble, that's why -U $user%$pass may be prefered. Also, the doc says that if $user is not provided, then it defaults to "guest" but the problem is that if it is provided but empty, it is changed to "guest" as well, which prevents us from querying hosts that don't do user authentication. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478942 Thanks and kind regards, Jan. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1986260&group_id=29880 From noreply at sourceforge.net Fri Jun 6 13:23:34 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 Jun 2008 04:23:34 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1986306 ] check_dig: no check for mandatory parameter -l Message-ID: Bugs item #1986306, was opened at 2008-06-06 13:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1986306&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: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: check_dig: no check for mandatory parameter -l Initial Comment: The following Bugreport we got against our debian package: Hiya, $ ./check_dig -h check_dig v1590 (nagios-plugins 1.4.11) [...] Usage:check_dig -H host -l lookup [-p ] [-T ] [-w ] [-c ] [-t ] [-a ] [-v] "-l lookup" is meant to be a mandatory option. But, /usr/lib/nagios/plugins$ ./check_dig -H localhost -v /usr/bin/dig @localhost -p 53 (null) -t A Looking for: '(null)' DNS UNKNOWN - 0.767 seconds response time (No ANSWER SECTION found)|time=0.767500s;;;0.000000 asnprintf is called with a NULL parameter. That would cause a SEGV if GNU libc's asnprintf wasn't nice enough to replace the NULL with "(null)". fix would be to report an error if "-l" is not provided. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479013 Thanks and kind regards, Jan. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1986306&group_id=29880 From nick.akl at pnmac.com Wed Jun 4 03:03:31 2008 From: nick.akl at pnmac.com (Nick Akl) Date: Tue, 3 Jun 2008 18:03:31 -0700 Subject: [Nagiosplug-devel] Generic Canon Copier plugin Message-ID: <17d9981b0806031803v637a0d37y8fa47439b3e318d3@mail.gmail.com> Hi, I'm trying to find out if there is an generic Canon Copier plugin for Nagios? Can anyone guide me in the right direction? Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Fri Jun 6 14:36:28 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 Jun 2008 05:36:28 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1975646 ] check_radius wrongly handles NAS-IP-Address Message-ID: Patches item #1975646, was opened at 2008-05-28 01:17 Message generated for change (Comment added) made by shallot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1975646&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: Bugfix Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Josip Rodin (shallot) Assigned to: Nobody/Anonymous (nobody) Summary: check_radius wrongly handles NAS-IP-Address Initial Comment: Hi, The check_radius plugin is wrongly hardcoding the value of the NAS-IP-Address attribute in the packets it sends. It gets the address from the rc_own_ipaddress() library call, and that in turn translates into calling gethostbyname() on the result of uname(). This call can easily fail, and its result can easily be unsuitable - for example when the Nagios instance uses its own virtual host, and you don't want the original system hostname leaked to the RADIUS servers you monitor with this. Furthermore, this behaviour is inconsistent with RFC 2865, which defines the two attributes as analogous and never suggests hardcoding the value of either of them in client software. I'm attaching a patch which adds a new option (-N) which allows the user to provide the NAS-IP-Address attribute contents, just like they can for the other attribute (with -n). While adding this, I also noticed that the error handling there is also broken - it does "return (ERROR_PC)", which is meaningless in the context of check_radius.c. That actually seems to be copy&waste from radiusclient-0.3.2/src/radexample.c. :) so I fixed that as well. While debugging, I also took the opportunity to decouple the nas-identifier rc_avpair_add() instance from the initial three, because this is just bad practice to lump a fourth optional attribute into the same block with the required attributes, the error handling for which is throwing the same daft message "Out of Memory?"... Another tidbit - the -n option, to include NAS-Identifier, requires that the radiusclient attribute dictionary includes that attribute - which it doesn't in the old library. radiusclient-ng has this fixed. I'm mentioning this just because of the recent change to the REQUIREMENTS file - just another confirmation that the change is correct, I guess :) Please include the patch. Thanks. (I've also filed this at http://bugs.debian.org/482947 FWIW) ---------------------------------------------------------------------- >Comment By: Josip Rodin (shallot) Date: 2008-06-06 14:36 Message: Logged In: YES user_id=119756 Originator: YES > Furthermore, this behaviour is inconsistent with RFC 2865, which defines > the two attributes as analogous and never suggests hardcoding the value of > either of them in client software. I just realized that I forgot to mention the other attribute's name before that paragraph - I'm talking about NAS-Identifier. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1975646&group_id=29880 From noreply at sourceforge.net Fri Jun 6 17:55:05 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 Jun 2008 08:55:05 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1975646 ] check_radius wrongly handles NAS-IP-Address Message-ID: Patches item #1975646, was opened at 2008-05-28 01:17 Message generated for change (Comment added) made by cyco_dd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1975646&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: Bugfix Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Josip Rodin (shallot) Assigned to: Nobody/Anonymous (nobody) Summary: check_radius wrongly handles NAS-IP-Address Initial Comment: Hi, The check_radius plugin is wrongly hardcoding the value of the NAS-IP-Address attribute in the packets it sends. It gets the address from the rc_own_ipaddress() library call, and that in turn translates into calling gethostbyname() on the result of uname(). This call can easily fail, and its result can easily be unsuitable - for example when the Nagios instance uses its own virtual host, and you don't want the original system hostname leaked to the RADIUS servers you monitor with this. Furthermore, this behaviour is inconsistent with RFC 2865, which defines the two attributes as analogous and never suggests hardcoding the value of either of them in client software. I'm attaching a patch which adds a new option (-N) which allows the user to provide the NAS-IP-Address attribute contents, just like they can for the other attribute (with -n). While adding this, I also noticed that the error handling there is also broken - it does "return (ERROR_PC)", which is meaningless in the context of check_radius.c. That actually seems to be copy&waste from radiusclient-0.3.2/src/radexample.c. :) so I fixed that as well. While debugging, I also took the opportunity to decouple the nas-identifier rc_avpair_add() instance from the initial three, because this is just bad practice to lump a fourth optional attribute into the same block with the required attributes, the error handling for which is throwing the same daft message "Out of Memory?"... Another tidbit - the -n option, to include NAS-Identifier, requires that the radiusclient attribute dictionary includes that attribute - which it doesn't in the old library. radiusclient-ng has this fixed. I'm mentioning this just because of the recent change to the REQUIREMENTS file - just another confirmation that the change is correct, I guess :) Please include the patch. Thanks. (I've also filed this at http://bugs.debian.org/482947 FWIW) ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2008-06-06 17:55 Message: Logged In: YES user_id=1345239 Originator: NO patch against 1.4.12 is available at http://svn.debian.org/wsvn/pkg-nagios/nagios-plugins/trunk/debian/patches/37_check_radius_nas-ip-address.dpatch?op=file&rev=0&sc=0 ---------------------------------------------------------------------- Comment By: Josip Rodin (shallot) Date: 2008-06-06 14:36 Message: Logged In: YES user_id=119756 Originator: YES > Furthermore, this behaviour is inconsistent with RFC 2865, which defines > the two attributes as analogous and never suggests hardcoding the value of > either of them in client software. I just realized that I forgot to mention the other attribute's name before that paragraph - I'm talking about NAS-Identifier. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1975646&group_id=29880 From noreply at sourceforge.net Sat Jun 7 14:09:01 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Jun 2008 05:09:01 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1975646 ] check_radius wrongly handles NAS-IP-Address Message-ID: Patches item #1975646, was opened at 2008-05-28 01:17 Message generated for change (Comment added) made by shallot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1975646&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: Bugfix Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Josip Rodin (shallot) Assigned to: Nobody/Anonymous (nobody) Summary: check_radius wrongly handles NAS-IP-Address Initial Comment: Hi, The check_radius plugin is wrongly hardcoding the value of the NAS-IP-Address attribute in the packets it sends. It gets the address from the rc_own_ipaddress() library call, and that in turn translates into calling gethostbyname() on the result of uname(). This call can easily fail, and its result can easily be unsuitable - for example when the Nagios instance uses its own virtual host, and you don't want the original system hostname leaked to the RADIUS servers you monitor with this. Furthermore, this behaviour is inconsistent with RFC 2865, which defines the two attributes as analogous and never suggests hardcoding the value of either of them in client software. I'm attaching a patch which adds a new option (-N) which allows the user to provide the NAS-IP-Address attribute contents, just like they can for the other attribute (with -n). While adding this, I also noticed that the error handling there is also broken - it does "return (ERROR_PC)", which is meaningless in the context of check_radius.c. That actually seems to be copy&waste from radiusclient-0.3.2/src/radexample.c. :) so I fixed that as well. While debugging, I also took the opportunity to decouple the nas-identifier rc_avpair_add() instance from the initial three, because this is just bad practice to lump a fourth optional attribute into the same block with the required attributes, the error handling for which is throwing the same daft message "Out of Memory?"... Another tidbit - the -n option, to include NAS-Identifier, requires that the radiusclient attribute dictionary includes that attribute - which it doesn't in the old library. radiusclient-ng has this fixed. I'm mentioning this just because of the recent change to the REQUIREMENTS file - just another confirmation that the change is correct, I guess :) Please include the patch. Thanks. (I've also filed this at http://bugs.debian.org/482947 FWIW) ---------------------------------------------------------------------- >Comment By: Josip Rodin (shallot) Date: 2008-06-07 14:09 Message: Logged In: YES user_id=119756 Originator: YES Jan Wagner told me that my original patch doesn't apply to 1.4.12; here's an updated patch for that version. The only real change should be the use of my_rc_own_ipaddress(), it seems. File Added: check_radius.c.diff ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2008-06-06 17:55 Message: Logged In: YES user_id=1345239 Originator: NO patch against 1.4.12 is available at http://svn.debian.org/wsvn/pkg-nagios/nagios-plugins/trunk/debian/patches/37_check_radius_nas-ip-address.dpatch?op=file&rev=0&sc=0 ---------------------------------------------------------------------- Comment By: Josip Rodin (shallot) Date: 2008-06-06 14:36 Message: Logged In: YES user_id=119756 Originator: YES > Furthermore, this behaviour is inconsistent with RFC 2865, which defines > the two attributes as analogous and never suggests hardcoding the value of > either of them in client software. I just realized that I forgot to mention the other attribute's name before that paragraph - I'm talking about NAS-Identifier. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1975646&group_id=29880 From noreply at sourceforge.net Sat Jun 7 16:11:41 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Jun 2008 07:11:41 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1985492 ] check_disk wrongly treats devices as being NFS shares Message-ID: Bugs item #1985492, was opened at 2008-06-05 16:14 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985492&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk wrongly treats devices as being NFS shares Initial Comment: The following Bugreport we got against our debian package: Hiya, check_disk -l or -L is meant to check only the local file systems, so it excludes the NFS mounted ones. But to do so, it checks whether the "mount device" contains a ":" instead of checking the filesystem type. For instance, that means that it won't check filesystems on local devices that have ":" in their path. Example: /dev/mapper/vol-snaphost-2008-04-30-08:00:00 You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479045 Thanks and kind regards, Jan. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2008-06-07 16:11 Message: Logged In: YES user_id=1694341 Originator: NO This is actually a gnulib problem. from gl/mountlist.c: /* A file system is `remote' if its Fs_name contains a `:' or if (it is of type (smbfs or cifs) and its Fs_name starts with `//'). */ Thus gnu df -l should have the same problem also. But checking the filesystem type would OTOH require knowing all the remote filesystem types. This might be leading to more such problems than the current solution. I'm totally fine with syncing the gnulib code if someone can get a solution committed there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985492&group_id=29880 From noreply at sourceforge.net Sat Jun 7 16:24:19 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Jun 2008 07:24:19 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1985276 ] check_disk --local does not exclude cifs mounts Message-ID: Bugs item #1985276, was opened at 2008-06-05 11:52 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985276&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk --local does not exclude cifs mounts Initial Comment: The following Bugreport we got against our debian package: $ /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -l DISK WARNING - free space: / 142 MB (77% inode=85%); /dev/shm 92 MB (100% inode=99%); /mnt/usr 840 MB (73% inode=86%); /mnt/home 1055 MB (92% inode=99%); /mnt/var 1971 MB (58% inode=99%); /mnt/amanda 2487 MB (30% inode=99%); /tmp 92 MB (99% inode=99%); /media/linux-backup 56546 MB (13% inode=-);| /=41MB;154;173;0;193 /dev/shm=0MB;73;82;0;92 /mnt/usr=296MB;73;82;0;1196 /mnt/home=80MB;73;82;0;1196 /mnt/var=1406MB;73;82;0;3559 /mnt/amanda=5614MB;73;82;0;8535 /tmp=0MB;73;82;0;92 /media/linux-backup=355477MB;73;82;0;412023 The only filesystem that is below the warning threshold is /media/linux-back, which is not a local file system: $ grep linux-backup /proc/mounts //windows-server.domain.example/linux_backup$ /media/linux-backup cifs rw,mand,unc=\\windows-server.domain.example\linux_backup$,username=user,rsize=16384,wsize=57344 0 0 cifs mounts should be excluded if --local is used. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405539 Thanks and kind regards, Jan. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2008-06-07 16:24 Message: Logged In: YES user_id=1694341 Originator: NO works for me.. at least with the current version. This detection is also part of gnulib code and I cannot find any changes in mountlist.c that would have fixed the remote/local detection. I'm disposed to file this as "Works for me" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985276&group_id=29880 From noreply at sourceforge.net Mon Jun 9 21:48:41 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jun 2008 12:48:41 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1986306 ] check_dig: no check for mandatory parameter -l Message-ID: Bugs item #1986306, was opened at 2008-06-06 13:23 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1986306&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Argument proccessing Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) >Assigned to: Matthias Eble (psychotrahe) Summary: check_dig: no check for mandatory parameter -l Initial Comment: The following Bugreport we got against our debian package: Hiya, $ ./check_dig -h check_dig v1590 (nagios-plugins 1.4.11) [...] Usage:check_dig -H host -l lookup [-p ] [-T ] [-w ] [-c ] [-t ] [-a ] [-v] "-l lookup" is meant to be a mandatory option. But, /usr/lib/nagios/plugins$ ./check_dig -H localhost -v /usr/bin/dig @localhost -p 53 (null) -t A Looking for: '(null)' DNS UNKNOWN - 0.767 seconds response time (No ANSWER SECTION found)|time=0.767500s;;;0.000000 asnprintf is called with a NULL parameter. That would cause a SEGV if GNU libc's asnprintf wasn't nice enough to replace the NULL with "(null)". fix would be to report an error if "-l" is not provided. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479013 Thanks and kind regards, Jan. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-06-09 21:48 Message: Logged In: YES user_id=1694341 Originator: NO this problem is now fixed in svn. thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1986306&group_id=29880 From noreply at sourceforge.net Mon Jun 9 21:57:08 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jun 2008 12:57:08 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1878971 ] several typos Message-ID: Bugs item #1878971, was opened at 2008-01-24 16:44 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1878971&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 (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: several typos Initial Comment: the attached patch fixes several typos and was commited to Debian Nagios Maintainer Group. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2008-06-09 21:57 Message: Logged In: YES user_id=1694341 Originator: NO I haven't committed this since I think it'll break many translation strings. Personally, I like the patch. But maybe the team has to reconsider how to handle translations. This has been neglected for some time, now. ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2008-06-03 14:01 Message: Logged In: YES user_id=1345239 Originator: YES Is there anything blocking the commit ot the patch? Is there anythin what i can do to make it more easy? ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2008-06-03 13:58 Message: Logged In: YES user_id=1345239 Originator: YES File Added: 50_misc_typos.dpatch ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2008-02-05 22:56 Message: Logged In: YES user_id=1345239 Originator: YES see also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=435525 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453012 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1878971&group_id=29880 From peter.spatz at xchanging.com Fri Jun 6 14:31:56 2008 From: peter.spatz at xchanging.com (Peter Spatz) Date: Fri, 6 Jun 2008 14:31:56 +0200 Subject: [Nagiosplug-devel] Return internal Variables Message-ID: <699B941ACF3F324F90C4ABAA8D8D90E50837839A@SRV50005.ad.xglobal.com> Hello, e.g. end of a check: if [ $STATUS == "OK" ] then echo "All Ressourcegroups in regular state !" else echo "Ressourcegroup $RESS not in regular state !" exit 2 fi And $RESS is a variable which was used inside a loop filled with all cluster resources. Running the check direct on the server returns what I want: root at svm103f1:/opt/nagios/libexec# /opt/nagios/libexec/check_veritas_cluster Ressourcegroup XPR-TRS-E2E not in regular state ! Nagios returns Ressourcegroup not in regular state ! Best Regards Peter Spatz Xchanging Transaction Bank GmbH - HRB 58 951 - Sitz Frankfurt - Amtsgericht Frankfurt am Main Vorsitzender des Aufsichtsrats: David Andrews - Geschaeftsfuehrer: Joerg Brand, Mike Margetts, Andreas Povel, Thomas Runge ----------------------------------------------------------------------------------------------- "Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden." ----------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at CIS.FU-Berlin.DE Tue Jun 10 13:53:27 2008 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Tue, 10 Jun 2008 13:53:27 +0200 Subject: [Nagiosplug-devel] Return internal Variables In-Reply-To: <699B941ACF3F324F90C4ABAA8D8D90E50837839A@SRV50005.ad.xglobal.com> References: <699B941ACF3F324F90C4ABAA8D8D90E50837839A@SRV50005.ad.xglobal.com> Message-ID: <20080610115327.GI68051193@CIS.FU-Berlin.DE> * Peter Spatz [2008-06-06 14:31]: > if [ $STATUS == "OK" ] > then > echo "All Ressourcegroups in regular state !" > else > echo "Ressourcegroup $RESS not in regular state !" > exit 2 > fi > > And $RESS is a variable which was used inside a loop filled with all > cluster resources. Is $RESS filled correctly if you manually execute the plugin as the user which runs Nagios (never test as root!)? If so, is it also filled correctly if you execute it via "env -i"? > Nagios returns > > Ressourcegroup not in regular state ! I'd guess $RESS is not filled because that either requires permissions the Nagios user doesn't have and/or because it depends on other environment variables which aren't set if executed via Nagios. Holger From noreply at sourceforge.net Wed Jun 11 04:20:40 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jun 2008 19:20:40 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1852198 ] Check_by_ssh exit code always 0 Message-ID: Bugs item #1852198, was opened at 2007-12-17 01:56 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1852198&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: ADW (alain_dewit) Assigned to: Nobody/Anonymous (nobody) Summary: Check_by_ssh exit code always 0 Initial Comment: The "check_by_ssh" plugin report always an exit status/code of 0 when it should return a value of "2". Should be the same for the other exit code values. Plugin compiled from nagios-plugins-1.4.7.tar.gz on a RedHat Fedora Core Intel system. Best regards ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2008-06-10 19:20 Message: Logged In: YES user_id=1312539 Originator: NO 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: Ton Voon (tonvoon) Date: 2008-05-27 14:31 Message: Logged In: YES user_id=664364 Originator: NO Hi! I agree with Matthias - this works as designed. I've added a comment to the -f option to state that the return code has to be 0. A possibility is to remove the -f option, but that can be left for another discussion. I've marked the call to pending so it will auto-close after 7 days if there are no updates. Ton ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-01-04 15:38 Message: Logged In: YES user_id=1694341 Originator: NO Hello alain, I've looked into this issue and can reproduce the described behaviour.. But: check_by_ssh's -f argument simply adds -f to the ssh call. With -f, ssh immediately returns, even if the remote command is still running. Actually there is no exit code at this point. However, check_by_ssh waits for the command output, IMO because it reads from the output file descriptor which is left open until the remote command execution is done. But this is a side effect. Note that /usr/bin/ssh -f 127.0.0.1 'exit 2' ;echo $? also returns 0. I'd thus say check_by_ssh -f works as desi(gn|r)ed I cannot imagine what -f should be good for though. But we should at least place a note in --help. Any other comments? Matthias ---------------------------------------------------------------------- Comment By: ADW (alain_dewit) Date: 2007-12-17 03:11 Message: Logged In: YES user_id=1961631 Originator: YES I forgot to say that the problem only occur when using the "-f" (fork) option. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1852198&group_id=29880 From noreply at sourceforge.net Wed Jun 11 04:20:41 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jun 2008 19:20:41 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1864225 ] check_procs under SunOS 5.10 broken Message-ID: Bugs item #1864225, was opened at 2008-01-04 13:37 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1864225&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Ton Voon (tonvoon) Summary: check_procs under SunOS 5.10 broken Initial Comment: Hi, i just compiled the 4.11 plugins on a $ uname -a SunOS spnb51 5.10 Generic_118833-24 sun4v sparc SUNW,Sun-Fire-T200 and found that check_procs does not work correctly. $ ps -ef | grep cron root 15100 1 0 Nov 08 ? 1:06 /usr/sbin/cron $ /usr/ucb/ps -alxwwn | grep cron 0 0 15100 1 0 59 20 2784 1048 60015774482 S ? 1:06 /usr/sbin/cron Cron is running, but.... check_procs -w :10 -c 1: -C cron PROCS CRITICAL: 0 processes with command name '/usr/sbin/cron' Running check-procs with -vvv shows, that it uses /usr/ucb/ps -alxwwn and actually parses the right line proc#=0 uid=0 vsz=2784 rss=1048 pid=15100 ppid=1 pcpu=0.00 stat=S etime= prog= args=/usr/sbin/cron but as you see, prog is empty and what should be prog is recognized as argument. Please change the configure.in (the buggy lines in configure are 24967 ff) so that it reads: ac_cv_ps_varlist="&procuid,&procpid,&procppid,&procpcpu,&procvsz,&procrs s,procstat,procprog,&pos" ac_cv_ps_command="/usr/ucb/ps -alxwwn" ac_cv_ps_format="%*s %d %d %d %d %*d %*d %d %d%*[ 0123456789abcdef]%[OSR ZT]%*s %*s %s %n" ac_cv_ps_cols=9 (add procprog to the varlist, add a %s at the end of format and increase cols) Then it looks good: $ check_procs -w :10 -c 1: -C cron PROCS OK: 1 process with command name 'cron' Greetings from Munich, Gerhard ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2008-06-10 19:20 Message: Logged In: YES user_id=1312539 Originator: NO 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: Ton Voon (tonvoon) Date: 2008-05-27 14:32 Message: Logged In: YES user_id=664364 Originator: NO Hi! I believe this problem is resolved in the current snapshot. Please try and confirm if this is still an issue. Snapshot at http://nagiosplug.sf.net/snapshot. I've marked this call as pending so it will auto close in 7 days. Ton ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2008-02-29 02:40 Message: Logged In: YES user_id=664364 Originator: NO Gerhard and valloo99, Can you try the snapshot? I've made a change so that we revert back to the pst3 command, which means we can have a tailored output for check_procs to parse. The reason for pst3 is that the /usr/bin/ps command only shows you the first 80 chars of the args field, and /usr/ucb/ps only shows you the full args for your own processes (plus other un-parseable problems). See http://rt.cpan.org/Public/Bug/Display.html?id=23792 for some more details. Ton ---------------------------------------------------------------------- Comment By: Vincent Alloo (valloo99) Date: 2008-01-10 00:42 Message: Logged In: YES user_id=1977333 Originator: NO Fro info, this config is working for both Solaris8 and Soalris 10: ./configure --with-ps-command="/usr/bin/ps -eo 's uid pid ppid vsz rss pcpu etime comm args'" \ --with-ps-format='%s %d %d %d %d %d %f %s %s %n' \ --with-ps-cols=10 \ --with-ps-varlist='procstat,&procuid,&procpid,&procppid,&procvsz,&procrss,&procpcpu,procetime,procprog,&pos' Hope it helps. ---------------------------------------------------------------------- Comment By: Vincent Alloo (valloo99) Date: 2008-01-09 08:57 Message: Logged In: YES user_id=1977333 Originator: NO Fro info, this config is working for both Solaris8 and Soalris 10: ./configure --with-ps-command="/usr/bin/ps -eo 's uid pid ppid vsz rss pcpu etime comm args'" \ --with-ps-format='%s %d %d %d %d %d %f %s %s %n' \ --with-ps-cols=10 \ --with-ps-varlist='procstat,&procuid,&procpid,&procppid,&procvsz,&procrss,&procpcpu,procetime,procprog,&pos' Hope it helps. ---------------------------------------------------------------------- Comment By: gerhard lausser (lausser) Date: 2008-01-09 07:47 Message: Logged In: YES user_id=613416 Originator: YES You are right, when SZ and/or RSS grow too large, ther is no space left between NI and SZ or between SZ and RS: Not parseable: 0 0 16901 1 0 59 205028812184 30004e2e1a6 S ? 278:36 /opt/VRTSsmf/bin/vxsmf.bin -p RootSMF -B I replaced ac_cv_ps_format="%*s %d %d %d %d %*d %*d %d %d%*[...... with ac_cv_ps_format="%*s %d %d %d %d %*d %*2d %5d %d%*[.... and it successfully scanned these lines. (nice can have a maximum of 2 digits, and size can have a maximum of 5 digits. at least when the values still fit into the columns. maybe there are situations, where even the columns don't fit any more, then i think we have no chance) But then i found another one: Not parseable: 0 0 16101 351 0 54 20 3104 2664 ? S ? 0:00 /usr/openv/netbackup/bin/bpcd Here we have a WCHAN value of "?". Adding a ? to the conversion shoud should solve this. So i propose to change line 521 of configure.in to: ac_cv_ps_format="%*s %d %d %d %d %*d %*2d %5d %d%*[ 0123456789abcdef?]%[OSRZT]%*s %*s %s %n" Gerhard ---------------------------------------------------------------------- Comment By: Vincent Alloo (valloo99) Date: 2008-01-09 06:22 Message: Logged In: YES user_id=1977333 Originator: NO Becarefull, the "/usr/ucb/ps -alxwwn" can be non-parseable on some system: 0 18046 20095 20093 0 59 20 3056 1996 fffffe8d3efb8776 S pts/9 0:00 -tcsh 0 0 911 3293 0 59 20837008 1188 ffffffff85c0af42 S ? 0:00 /usr/local/bin/rsync -aWz -v --stats --progress --rsync-path=/apps/free/rsync/2 I still don't have a working check_procs for sol10/x86. ---------------------------------------------------------------------- Comment By: gerhard lausser (lausser) Date: 2008-01-04 17:01 Message: Logged In: YES user_id=613416 Originator: YES Hi Matthias, the last release i compiled on this machine was 1.4.2 and at that time configure decided to use /usr/bin/ps. I can try a 1.4.10 tomorrow but i am sure, it is also broken. I currently look at configure.in line 519. Particularly noticeable is the missing procprog variable in the ac_cv_ps_format. As one can see in the egrep line above, there _is_ a COMMAND field in the output, but the sscanf will not catch it. Gerhard p.s. this ps_format is not used for SunOS in general, only for SunOS whose /usr/ucb/ps -alxwwn shows the expected output format. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-01-04 16:13 Message: Logged In: YES user_id=1694341 Originator: NO Hi Gerhard, Are you sure this is valid for all operating systems where uname -s returns SunOS? I guess this (mis-)behaviour is not new in 1.4.11, right? Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1864225&group_id=29880 From noreply at sourceforge.net Wed Jun 11 04:20:42 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jun 2008 19:20:42 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1890260 ] 1.4.11 release does not build using SunC (patch incl) Message-ID: Bugs item #1890260, was opened at 2008-02-09 11:24 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1890260&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: Release (specify) >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Rob Windsor (wrwindsor) Assigned to: Nobody/Anonymous (nobody) Summary: 1.4.11 release does not build using SunC (patch incl) Initial Comment: SunStudio predefined macro missed in plugins-root/check_dhcp.c, patch is attached. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2008-06-10 19:20 Message: Logged In: YES user_id=1312539 Originator: NO 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: Ton Voon (tonvoon) Date: 2008-05-27 14:53 Message: Logged In: YES user_id=664364 Originator: NO Rob, Thanks for the patch. I've taken a slightly different approach because it looks like the configure script didn't pick up the fact the build system is a solaris server properly. Can you please try the snapshot at http://nagiosplug.sf.net/snapshot and confirm this is working okay now. Also, you might like to add a tinderbox build box for us to continually test against SunStudio: http://nagiosplugins.org/tinderbox I've marked this call into pending so will auto-close after 7 days if no response. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1890260&group_id=29880 From noreply at sourceforge.net Wed Jun 11 04:20:37 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jun 2008 19:20:37 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1480574 ] check_disk is missing -lm on Solaris (rel. 1.4.3) Message-ID: Bugs item #1480574, was opened at 2006-05-02 11:03 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1480574&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: Release (specify) >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Ralph R??ner (ralph_roessner) Assigned to: Ton Voon (tonvoon) Summary: check_disk is missing -lm on Solaris (rel. 1.4.3) Initial Comment: The common.h include defines, on Solaris only, a replacement definition for floorf(), which Solaris (up to and including version 8) does not have. Thus, on Solaris only, all plugins including common.h need a definition of floor() (on Linux that would be necessary only for those plugins that actually use floorf()), i.e. they need to link libm.so . The Makefile.in does not respect that need, and consequently compiling check_disk on Solaris fails. I would expect all other plugins that include common.h to have the same problem, but strangely that appears not to be the case. For my needs it was sufficient to add MATHLIBS to the dependency line for check_disk in the plugins/Makefile.in, and I include a patch that does exactly that. However, this should probably be resolved more generally. Regards, Ralph R??ner ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2008-06-10 19:20 Message: Logged In: YES user_id=1312539 Originator: NO 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: Ton Voon (tonvoon) Date: 2008-05-27 14:21 Message: Logged In: YES user_id=664364 Originator: NO Hi! I believe this has been recently resolved by the inclusion of floorf from the gnulib project. Please can you confirm with a snapshot at http://nagiosplug.sf.net/snapshot. This call will auto close in 7 days if there have been no updates. Ton ---------------------------------------------------------------------- Comment By: Ade Rixon (aderixon) Date: 2006-10-31 08:30 Message: Logged In: YES user_id=145082 This occurs with 1.4.4 if built with the Sun Studio 11 compiler (SunPro C), but not GCC. It happens for all the binary plugins, including check_disk; the quickest workaround is to manually edit the Makefiles and add -lm to the LIBS. ---------------------------------------------------------------------- Comment By: Ralph R??ner (ralph_roessner) Date: 2006-10-23 08:11 Message: Logged In: YES user_id=1515003 Hi, tried the 200610222352 snapshot. The error persists but has jumped to another plugin. This time, compilation fails for the first plugin to make, check_apt.c, same link error: definition of floor is missing. See, common.h defines (on the Solaris platform) a function floorf(), which is included into all the plugins. Most of the plugins do not use this function. For some, the compiler recognizes this and leaves out the definition. For others (and don't ask me why they are treated differently) the defintion of floorf() remains and triggers the linker to look for floor(). Conclusion: As long as the definition of floor() remains in common.h (line 216), you will need to include a -lm in the link line. I am not a configure master, so i will not provide a patch that does this. I hope someone else will know how to. Regards, Ralph R??ner ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-10-19 12:47 Message: Logged In: YES user_id=664364 Ralph, Can you please try the snapshot at http://nagiosplug.sf.net/snapshot. The check_disk code has been re-written without the use of floorf anymore. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1480574&group_id=29880 From noreply at sourceforge.net Wed Jun 11 22:47:44 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jun 2008 13:47:44 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1985276 ] check_disk --local does not exclude cifs mounts Message-ID: Bugs item #1985276, was opened at 2008-06-05 11:52 Message generated for change (Settings changed) made by cyco_dd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985276&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk --local does not exclude cifs mounts Initial Comment: The following Bugreport we got against our debian package: $ /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -l DISK WARNING - free space: / 142 MB (77% inode=85%); /dev/shm 92 MB (100% inode=99%); /mnt/usr 840 MB (73% inode=86%); /mnt/home 1055 MB (92% inode=99%); /mnt/var 1971 MB (58% inode=99%); /mnt/amanda 2487 MB (30% inode=99%); /tmp 92 MB (99% inode=99%); /media/linux-backup 56546 MB (13% inode=-);| /=41MB;154;173;0;193 /dev/shm=0MB;73;82;0;92 /mnt/usr=296MB;73;82;0;1196 /mnt/home=80MB;73;82;0;1196 /mnt/var=1406MB;73;82;0;3559 /mnt/amanda=5614MB;73;82;0;8535 /tmp=0MB;73;82;0;92 /media/linux-backup=355477MB;73;82;0;412023 The only filesystem that is below the warning threshold is /media/linux-back, which is not a local file system: $ grep linux-backup /proc/mounts //windows-server.domain.example/linux_backup$ /media/linux-backup cifs rw,mand,unc=\\windows-server.domain.example\linux_backup$,username=user,rsize=16384,wsize=57344 0 0 cifs mounts should be excluded if --local is used. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405539 Thanks and kind regards, Jan. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-06-07 16:24 Message: Logged In: YES user_id=1694341 Originator: NO works for me.. at least with the current version. This detection is also part of gnulib code and I cannot find any changes in mountlist.c that would have fixed the remote/local detection. I'm disposed to file this as "Works for me" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985276&group_id=29880 From noreply at sourceforge.net Wed Jun 11 22:57:12 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jun 2008 13:57:12 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1991275 ] check_ping warning.. "time of day goes back" Message-ID: Patches item #1991275, was opened at 2008-06-11 16:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1991275&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: Bugfix Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Geoff Oakham (oakhamg) Assigned to: Nobody/Anonymous (nobody) Summary: check_ping warning.. "time of day goes back" Initial Comment: Patch of check_ping that allows it to gracefully handle when ping outputs to stderr "Warning: time of day goes back (-XXXXus), taking countermeasures." (This is a common problem on virtual machines.) Please credit goakham at oanda.com. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1991275&group_id=29880 From dmartin at sccd.ctc.edu Fri Jun 13 17:43:58 2008 From: dmartin at sccd.ctc.edu (Dylan Martin) Date: Fri, 13 Jun 2008 08:43:58 -0700 Subject: [Nagiosplug-devel] Boolean Plugins Message-ID: Hi I'm wondering if there is a way to have the status of a host or service depend on multiple checks? For example, I have two ways of checking if a server is up and they're both prone to false-negatives (negative == down in this case). I'd like to have the host status be UP if either of these tests returns OK. I was thinking of how to do that, and I realised what I want is really a form of logical OR, and there are definitely applications for a logical AND, and finally there's already a NOT (negate). So, I'm thinking of making check_and and check_or. I've found check_multi, but I'm in nagios 2. Has someone already done this? Is there a mechanism that does this already? Does this sound like a good idea? Thanks! -Dylan From thomas at zango.com Fri Jun 13 18:09:32 2008 From: thomas at zango.com (Thomas Guyot-Sionnest) Date: Fri, 13 Jun 2008 12:09:32 -0400 Subject: [Nagiosplug-devel] Boolean Plugins In-Reply-To: References: Message-ID: <48529BBC.9070501@zango.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dylan Martin wrote: | Hi | | I'm wondering if there is a way to have the status of a host or | service depend on multiple checks? For example, I have two ways of | checking if a server is up and they're both prone to false-negatives | (negative == down in this case). I'd like to have the host status be | UP if either of these tests returns OK. | | I was thinking of how to do that, and I realised what I want is really | a form of logical OR, and there are definitely applications for a | logical AND, and finally there's already a NOT (negate). So, I'm | thinking of making check_and and check_or. | | I've found check_multi, but I'm in nagios 2. | | Has someone already done this? Is there a mechanism that does this | already? Does this sound like a good idea? I don't know of any plugin that does it (there may be one out there - did you look on nagiosexchange.org?) but you can use check_cluster (in recent Nagios-plugins distributions) to make multiple Nagios hosts/services "redundant". You will have to define every service in nagios (you can use "notification_period none" to silently disable notifications for them) and add a service using check_cluster and on-demand macros to check the status of all those services as a whole. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIUpu86dZ+Kt5BchYRAsA6AJ4kyAPf9Ij2nz4HDL4Na+Th/P8nOACeLbG7 Lf50jLggZGN2zY642vxoQJs= =/7QZ -----END PGP SIGNATURE----- From Matthias.Flacke at gmx.de Fri Jun 13 19:43:07 2008 From: Matthias.Flacke at gmx.de (Matthias Flacke) Date: Fri, 13 Jun 2008 19:43:07 +0200 Subject: [Nagiosplug-devel] Boolean Plugins In-Reply-To: References: Message-ID: <4852B1AB.6050807@gmx.de> Dylan Martin wrote: > I'm wondering if there is a way to have the status of a host or > service depend on multiple checks? For example, I have two ways of > checking if a server is up and they're both prone to false-negatives > (negative == down in this case). I'd like to have the host status be > UP if either of these tests returns OK. > > I was thinking of how to do that, and I realised what I want is really > a form of logical OR, and there are definitely applications for a > logical AND, and finally there's already a NOT (negate). So, I'm > thinking of making check_and and check_or. > > I've found check_multi, but I'm in nagios 2. > > Has someone already done this? Is there a mechanism that does this > already? Does this sound like a good idea? check_multi with the report option (-r 512) also works fine under Nagios 2, the output then is compressed to one line. But I assume that you mainly need the status logic and this is not depending on the Nagios version ;-). You can build complex boolean expressions in Perl syntax like state[CRITICAL]=((check_a == OK) || (check_b > check_c)) && !check_d Pattern regex against plugin outputs is also available: state[CRITICAL]=$check_a$ !~ /error|failed/ HTH - Matthias From dmartin at sccd.ctc.edu Fri Jun 13 22:19:06 2008 From: dmartin at sccd.ctc.edu (Dylan Martin) Date: Fri, 13 Jun 2008 13:19:06 -0700 Subject: [Nagiosplug-devel] Boolean Plugins In-Reply-To: <4852B1AB.6050807@gmx.de> References: <4852B1AB.6050807@gmx.de> Message-ID: I've actually started working on a check_or plugin and it's very interesting. Because I want it to act like most local operators, I've added short-cut execution. So, in check_or, if the first check succeeds, the 2nd check never happens, which has interesting implications. > You can build complex boolean expressions in Perl syntax like > > state[CRITICAL]=((check_a == OK) || (check_b > check_c)) && !check_d > > Pattern regex against plugin outputs is also available: > > state[CRITICAL]=$check_a$ !~ /error|failed/ Where is that? Is that in a nagios configuration file or in the code of a plugin, or somwhere else? Thanks -Dylan From noreply at sourceforge.net Fri Jun 13 22:58:41 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jun 2008 13:58:41 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1993363 ] check_procs times out on Solaris 10 Message-ID: Bugs item #1993363, was opened at 2008-06-13 16:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1993363&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: maemigh (maemigh) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs times out on Solaris 10 Initial Comment: I'm having problems with the latest snapshot of check_procs timing out. The version is v1991 (nagios-plugins 1.4.12). This is using pst3 included with the plugins. ./check_procs CRITICAL - Plugin timed out after 10 seconds ./check_procs -w 2:2 -c 2:2 -C nagios CRITICAL - Plugin timed out after 10 seconds I've tried sparc and x86 builds, both timeout: Solaris 5.10 Generic_118833-36 sparc Solaris Generic_127112-11 i386 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1993363&group_id=29880 From Matthias.Flacke at gmx.de Fri Jun 13 23:17:34 2008 From: Matthias.Flacke at gmx.de (Matthias Flacke) Date: Fri, 13 Jun 2008 23:17:34 +0200 Subject: [Nagiosplug-devel] Boolean Plugins In-Reply-To: References: <4852B1AB.6050807@gmx.de> Message-ID: <4852E3EE.4070204@gmx.de> Dylan Martin wrote: >> You can build complex boolean expressions in Perl syntax like >> >> state[CRITICAL]=((check_a == OK) || (check_b > check_c)) && !check_d >> >> Pattern regex against plugin outputs is also available: >> >> state[CRITICAL]=$check_a$ !~ /error|failed/ > > Where is that? Is that in a nagios configuration file or in the code > of a plugin, or somwhere else? The statements above are part of a check_multi config file (NRPE stylish). check_multi started as a wrapper plugin to call multiple child checks. But with the state evaluation described in http://www.my-plugin.de/wiki/projects/check_multi/configuration/file#state_definition it can be used for sophisticated setups, business views etc. Examples can be found in http://www.my-plugin.de/wiki/projects/check_multi/process_views and http://www.my-plugin.de/wiki/projects/check_multi/eval -Matthias -- http://my-plugin.de/check_multi From dmartin at sccd.ctc.edu Sat Jun 14 00:07:02 2008 From: dmartin at sccd.ctc.edu (Dylan Martin) Date: Fri, 13 Jun 2008 15:07:02 -0700 Subject: [Nagiosplug-devel] Boolean Plugins In-Reply-To: <4852E3EE.4070204@gmx.de> References: <4852B1AB.6050807@gmx.de> <4852E3EE.4070204@gmx.de> Message-ID: Thanks! I'll definitely check that out. On Fri, Jun 13, 2008 at 2:17 PM, Matthias Flacke wrote: > > > Dylan Martin wrote: >>> You can build complex boolean expressions in Perl syntax like >>> >>> state[CRITICAL]=((check_a == OK) || (check_b > check_c)) && !check_d >>> >>> Pattern regex against plugin outputs is also available: >>> >>> state[CRITICAL]=$check_a$ !~ /error|failed/ >> >> Where is that? Is that in a nagios configuration file or in the code >> of a plugin, or somwhere else? > > The statements above are part of a check_multi config file (NRPE stylish). > > check_multi started as a wrapper plugin to call multiple child checks. But > with the state evaluation described in > http://www.my-plugin.de/wiki/projects/check_multi/configuration/file#state_definition > it can be used for sophisticated setups, business views etc. > Examples can be found in > http://www.my-plugin.de/wiki/projects/check_multi/process_views and > http://www.my-plugin.de/wiki/projects/check_multi/eval > > -Matthias > > > > -- > http://my-plugin.de/check_multi > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________________ > 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 > From noreply at sourceforge.net Mon Jun 16 22:32:40 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Jun 2008 13:32:40 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1993363 ] check_procs times out on Solaris 10 Message-ID: Bugs item #1993363, was opened at 2008-06-13 16:58 Message generated for change (Comment added) made by maemigh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1993363&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: maemigh (maemigh) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs times out on Solaris 10 Initial Comment: I'm having problems with the latest snapshot of check_procs timing out. The version is v1991 (nagios-plugins 1.4.12). This is using pst3 included with the plugins. ./check_procs CRITICAL - Plugin timed out after 10 seconds ./check_procs -w 2:2 -c 2:2 -C nagios CRITICAL - Plugin timed out after 10 seconds I've tried sparc and x86 builds, both timeout: Solaris 5.10 Generic_118833-36 sparc Solaris Generic_127112-11 i386 ---------------------------------------------------------------------- >Comment By: maemigh (maemigh) Date: 2008-06-16 16:32 Message: Logged In: YES user_id=1520524 Originator: YES Had time to do a little more digging. This happens if the file pointed to by PS_COMMAND does not exist. There do not appear to be any checks within spopen to handle a return code from execve in the event of an error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1993363&group_id=29880 From noreply at sourceforge.net Tue Jun 17 11:22:06 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Jun 2008 02:22:06 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1993363 ] check_procs times out on Solaris 10 Message-ID: Bugs item #1993363, was opened at 2008-06-13 21:58 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1993363&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: maemigh (maemigh) >Assigned to: Ton Voon (tonvoon) Summary: check_procs times out on Solaris 10 Initial Comment: I'm having problems with the latest snapshot of check_procs timing out. The version is v1991 (nagios-plugins 1.4.12). This is using pst3 included with the plugins. ./check_procs CRITICAL - Plugin timed out after 10 seconds ./check_procs -w 2:2 -c 2:2 -C nagios CRITICAL - Plugin timed out after 10 seconds I've tried sparc and x86 builds, both timeout: Solaris 5.10 Generic_118833-36 sparc Solaris Generic_127112-11 i386 ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2008-06-17 10:22 Message: Logged In: YES user_id=664364 Originator: NO Hi maemigh, The issue is that pst3 times out as it is taking too long to query. We've found this on a master host with multiple zones. Please try the snapshot at http://nagiosplug.sf.net/snapshot as pst3 has been optimised to make less kvm calls. It would be useful if you could give us timings before and after the snapshot. Beware, we've recently found an issue where it can coredump if a process disappears as it is trying to access it - a fix is due soon. Ton ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2008-06-16 21:32 Message: Logged In: YES user_id=1520524 Originator: YES Had time to do a little more digging. This happens if the file pointed to by PS_COMMAND does not exist. There do not appear to be any checks within spopen to handle a return code from execve in the event of an error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1993363&group_id=29880 From noreply at sourceforge.net Tue Jun 17 11:23:21 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Jun 2008 02:23:21 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1993363 ] check_procs times out on Solaris 10 Message-ID: Bugs item #1993363, was opened at 2008-06-13 21:58 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1993363&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: maemigh (maemigh) Assigned to: Ton Voon (tonvoon) Summary: check_procs times out on Solaris 10 Initial Comment: I'm having problems with the latest snapshot of check_procs timing out. The version is v1991 (nagios-plugins 1.4.12). This is using pst3 included with the plugins. ./check_procs CRITICAL - Plugin timed out after 10 seconds ./check_procs -w 2:2 -c 2:2 -C nagios CRITICAL - Plugin timed out after 10 seconds I've tried sparc and x86 builds, both timeout: Solaris 5.10 Generic_118833-36 sparc Solaris Generic_127112-11 i386 ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2008-06-17 10:23 Message: Logged In: YES user_id=664364 Originator: NO Sorry, misread your report. So are you saying that PS_COMMAND is not set? ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2008-06-17 10:22 Message: Logged In: YES user_id=664364 Originator: NO Hi maemigh, The issue is that pst3 times out as it is taking too long to query. We've found this on a master host with multiple zones. Please try the snapshot at http://nagiosplug.sf.net/snapshot as pst3 has been optimised to make less kvm calls. It would be useful if you could give us timings before and after the snapshot. Beware, we've recently found an issue where it can coredump if a process disappears as it is trying to access it - a fix is due soon. Ton ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2008-06-16 21:32 Message: Logged In: YES user_id=1520524 Originator: YES Had time to do a little more digging. This happens if the file pointed to by PS_COMMAND does not exist. There do not appear to be any checks within spopen to handle a return code from execve in the event of an error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1993363&group_id=29880 From noreply at sourceforge.net Thu Jun 19 20:31:57 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Jun 2008 18:31:57 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1993363 ] check_procs times out on Solaris 10 Message-ID: Bugs item #1993363, was opened at 2008-06-13 16:58 Message generated for change (Comment added) made by maemigh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1993363&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: maemigh (maemigh) Assigned to: Ton Voon (tonvoon) Summary: check_procs times out on Solaris 10 Initial Comment: I'm having problems with the latest snapshot of check_procs timing out. The version is v1991 (nagios-plugins 1.4.12). This is using pst3 included with the plugins. ./check_procs CRITICAL - Plugin timed out after 10 seconds ./check_procs -w 2:2 -c 2:2 -C nagios CRITICAL - Plugin timed out after 10 seconds I've tried sparc and x86 builds, both timeout: Solaris 5.10 Generic_118833-36 sparc Solaris Generic_127112-11 i386 ---------------------------------------------------------------------- >Comment By: maemigh (maemigh) Date: 2008-06-19 14:31 Message: Logged In: YES user_id=1520524 Originator: YES PS_COMMAND was set, but it was set to a location that didn't exist. I was running the check_procs command without first doing a make install. I'm thinking that the plugin should probably report that /usr/local/nagios/libexec/pst3 doesn't exist rather than timing out after 10 seconds. I ran into another problem with pst3 in that it will not run inside a Solaris zone (as /dev/kmem does not exist) -- are there plans to make changes to allow for use in zones? ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2008-06-17 05:23 Message: Logged In: YES user_id=664364 Originator: NO Sorry, misread your report. So are you saying that PS_COMMAND is not set? ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2008-06-17 05:22 Message: Logged In: YES user_id=664364 Originator: NO Hi maemigh, The issue is that pst3 times out as it is taking too long to query. We've found this on a master host with multiple zones. Please try the snapshot at http://nagiosplug.sf.net/snapshot as pst3 has been optimised to make less kvm calls. It would be useful if you could give us timings before and after the snapshot. Beware, we've recently found an issue where it can coredump if a process disappears as it is trying to access it - a fix is due soon. Ton ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2008-06-16 16:32 Message: Logged In: YES user_id=1520524 Originator: YES Had time to do a little more digging. This happens if the file pointed to by PS_COMMAND does not exist. There do not appear to be any checks within spopen to handle a return code from execve in the event of an error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1993363&group_id=29880 From noreply at sourceforge.net Thu Jun 19 23:31:27 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Jun 2008 21:31:27 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1998257 ] only "Invalid HTTP response received from host" Message-ID: Bugs item #1998257, was opened at 2008-06-19 23:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1998257&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: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: only "Invalid HTTP response received from host" Initial Comment: The following Bugreport we got against our debian package: Rather than stating what it got, the script just barfs generically. The code says: if (!strstr (status_line, server_expect)) { if (server_port == HTTP_PORT) asprintf (&msg, _("Invalid HTTP response received from host\n")); else asprintf (&msg, _("Invalid HTTP response received from host on port %d\n"), server_port); die (STATE_CRITICAL, "HTTP CRITICAL - %s", msg); } It should add the contents of the status_line (as %s) into the output (msg). Oddly enough, the script actually does this pretty consistently in the lines below, only in these two cases does it fail to mention the actual status line. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486932 Thanks and kind regards, Jan. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1998257&group_id=29880 From bigedd at gmail.com Fri Jun 20 08:39:07 2008 From: bigedd at gmail.com (Eddie F) Date: Fri, 20 Jun 2008 16:39:07 +1000 Subject: [Nagiosplug-devel] How do we report a possible bug (in check_ping)? Message-ID: <12b44e560806192339j4e9af4cem3ed67d6ec908c3a5@mail.gmail.com> Hi all, How/where do I report bugs for a Nagios plugin (check_ping)? And just as importantly, how/where do I check to see if it is something that has already been reported? I think I might have found a bug in check_ping when a a domain name is entered for host_address rather than the IP address. I've found that using the domain name seems to work fine with some other check commands (FTP, HTTP and SSH). Also: System pings work fine too... # /bin/ping -n -U -w 10 -c 5 nagios.org PING nagios.org (66.118.156.22) 56(84) bytes of data. 64 bytes from 66.118.156.22: icmp_seq=1 ttl=45 time=431 ms 64 bytes from 66.118.156.22: icmp_seq=2 ttl=45 time=461 ms 64 bytes from 66.118.156.22: icmp_seq=3 ttl=45 time=451 ms 64 bytes from 66.118.156.22: icmp_seq=4 ttl=45 time=441 ms 64 bytes from 66.118.156.22: icmp_seq=5 ttl=45 time=452 ms --- nagios.org ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 3999ms rtt min/avg/max/mdev = 431.271/447.571/461.284/10.243 ms See the two examples below, running check_ping on our system. Firstly using the domain name, then using IP address... # /usr/local/nagios/libexec/check_ping -H nagios.org -w 300,10% -c 1000,50% -p 5 CRITICAL - Plugin timed out after 10 seconds # /usr/local/nagios/libexec/check_ping -H 66.118.156.22 -w 300,10% -c 1000,50% -p 5 PING WARNING - Packet loss = 0%, RTA = 709.87 ms|rta=709.869019ms;300.000000;1000.000000;0.000000 pl=0%;10;50;0 I've tried this with many hosts (one on the same sub-net), and the result have always been the same Thanks, Eddie -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at CIS.FU-Berlin.DE Fri Jun 20 14:04:21 2008 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Fri, 20 Jun 2008 14:04:21 +0200 Subject: [Nagiosplug-devel] How do we report a possible bug (in check_ping)? In-Reply-To: <12b44e560806192339j4e9af4cem3ed67d6ec908c3a5@mail.gmail.com> References: <12b44e560806192339j4e9af4cem3ed67d6ec908c3a5@mail.gmail.com> Message-ID: <20080620120420.GF71490193@CIS.FU-Berlin.DE> * Eddie F [2008-06-20 16:39]: > How/where do I report bugs for a Nagios plugin (check_ping)? http://sourceforge.net/tracker/?group_id=29880 > And just as importantly, how/where do I check to see if it is something that > has already been reported? http://sourceforge.net/search/?group_id=29880 > # /usr/local/nagios/libexec/check_ping -H nagios.org -w 300,10% -c 1000,50% -p 5 > CRITICAL - Plugin timed out after 10 seconds Works fine for me: | $ check_ping -vvv -H nagios.org -w 300,10% -c 1000,50% -p | CMD: /bin/ping -n -U -w 10 -c 5 nagios.org | Output: PING nagios.org (66.118.156.22) 56(84) bytes of data. | Output: 64 bytes from 66.118.156.22: icmp_seq=1 ttl=54 time=143 ms | Output: 64 bytes from 66.118.156.22: icmp_seq=2 ttl=54 time=143 ms | Output: 64 bytes from 66.118.156.22: icmp_seq=3 ttl=54 time=142 ms | Output: 64 bytes from 66.118.156.22: icmp_seq=4 ttl=54 time=143 ms | Output: 64 bytes from 66.118.156.22: icmp_seq=5 ttl=54 time=143 ms | Output: | Output: --- nagios.org ping statistics --- | Output: 5 packets transmitted, 5 received, 0% packet loss, time 4002ms | Output: rtt min/avg/max/mdev = 142.896/143.149/143.259/0.272 ms | PING OK - Packet loss = 0%, RTA = 143.15 ms|rta=143.149002ms;300.000000;1000.000000;0.000000 pl=0%;10;50;0 | 300.000000:10% 1000.000000:50% Which release of the Nagios Plugins are you using? Could you show us the output you get if you use "-vvv" as I did in this example? Holger From bigedd at gmail.com Fri Jun 20 14:53:31 2008 From: bigedd at gmail.com (Eddie F) Date: Fri, 20 Jun 2008 22:53:31 +1000 Subject: [Nagiosplug-devel] How do we report a possible bug (in check_ping)? In-Reply-To: <20080620120420.GF71490193@CIS.FU-Berlin.DE> References: <12b44e560806192339j4e9af4cem3ed67d6ec908c3a5@mail.gmail.com> <20080620120420.GF71490193@CIS.FU-Berlin.DE> Message-ID: <12b44e560806200553u291cb68boef9170bef32cb193@mail.gmail.com> Here it is with "-vvv" ... # /usr/local/nagios/libexec/check_ping -vvv -H nagios.org -w 300,10% -c 1000,50% -p 5 CMD: /bin/ping -n -U -w 10 -c 5 nagios.org Output: PING nagios.org (66.118.156.22) 56(84) bytes of data. Output: 64 bytes from 66.118.156.22: icmp_seq=1 ttl=45 time=368 ms CRITICAL - Plugin timed out after 10 seconds Version... # /usr/local/nagios/libexec/check_ping -V check_ping v1991 (nagios-plugins 1.4.12) On Fri, Jun 20, 2008 at 10:04 PM, Holger Weiss wrote: > * Eddie F [2008-06-20 16:39]: > > How/where do I report bugs for a Nagios plugin (check_ping)? > > http://sourceforge.net/tracker/?group_id=29880 > > > And just as importantly, how/where do I check to see if it is something > that > > has already been reported? > > http://sourceforge.net/search/?group_id=29880 > > > # /usr/local/nagios/libexec/check_ping -H nagios.org -w 300,10% -c > 1000,50% -p 5 > > CRITICAL - Plugin timed out after 10 seconds > > Works fine for me: > > | $ check_ping -vvv -H nagios.org -w 300,10% -c 1000,50% -p > | CMD: /bin/ping -n -U -w 10 -c 5 nagios.org > | Output: PING nagios.org (66.118.156.22) 56(84) bytes of data. > | Output: 64 bytes from 66.118.156.22: icmp_seq=1 ttl=54 time=143 ms > | Output: 64 bytes from 66.118.156.22: icmp_seq=2 ttl=54 time=143 ms > | Output: 64 bytes from 66.118.156.22: icmp_seq=3 ttl=54 time=142 ms > | Output: 64 bytes from 66.118.156.22: icmp_seq=4 ttl=54 time=143 ms > | Output: 64 bytes from 66.118.156.22: icmp_seq=5 ttl=54 time=143 ms > | Output: > | Output: --- nagios.org ping statistics --- > | Output: 5 packets transmitted, 5 received, 0% packet loss, time 4002ms > | Output: rtt min/avg/max/mdev = 142.896/143.149/143.259/0.272 ms > | PING OK - Packet loss = 0%, RTA = 143.15 > ms|rta=143.149002ms;300.000000;1000.000000;0.000000 pl=0%;10;50;0 > | 300.000000:10% 1000.000000:50% > > Which release of the Nagios Plugins are you using? Could you show us > the output you get if you use "-vvv" as I did in this example? > > Holger > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________________ > 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 holger at CIS.FU-Berlin.DE Fri Jun 20 15:00:31 2008 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Fri, 20 Jun 2008 15:00:31 +0200 Subject: [Nagiosplug-devel] How do we report a possible bug (in check_ping)? In-Reply-To: <12b44e560806200553u291cb68boef9170bef32cb193@mail.gmail.com> References: <12b44e560806192339j4e9af4cem3ed67d6ec908c3a5@mail.gmail.com> <20080620120420.GF71490193@CIS.FU-Berlin.DE> <12b44e560806200553u291cb68boef9170bef32cb193@mail.gmail.com> Message-ID: <20080620130031.GG71490193@CIS.FU-Berlin.DE> * Eddie F [2008-06-20 22:53]: > Here it is with "-vvv" ... > > # /usr/local/nagios/libexec/check_ping -vvv -H nagios.org -w 300,10% -c 1000,50% -p 5 > CMD: /bin/ping -n -U -w 10 -c 5 nagios.org > Output: PING nagios.org (66.118.156.22) 56(84) bytes of data. > Output: 64 bytes from 66.118.156.22: icmp_seq=1 ttl=45 time=368 ms > CRITICAL - Plugin timed out after 10 seconds So it seems to work, apart from the fact that it runs into the timeout. Maybe ping(1)'s DNS resolution is very slow on your system for some reason? Does it work if you increase the plugin timeout by using e.g. "check_ping -t 60 ..."? Holger From bigedd at gmail.com Fri Jun 20 15:20:38 2008 From: bigedd at gmail.com (Eddie F) Date: Fri, 20 Jun 2008 23:20:38 +1000 Subject: [Nagiosplug-devel] How do we report a possible bug (in check_ping)? In-Reply-To: <20080620130031.GG71490193@CIS.FU-Berlin.DE> References: <12b44e560806192339j4e9af4cem3ed67d6ec908c3a5@mail.gmail.com> <20080620120420.GF71490193@CIS.FU-Berlin.DE> <12b44e560806200553u291cb68boef9170bef32cb193@mail.gmail.com> <20080620130031.GG71490193@CIS.FU-Berlin.DE> Message-ID: <12b44e560806200620k1ae7a5d6od567a1e390b5df14@mail.gmail.com> # /usr/local/nagios/libexec/check_ping -vvv -H nagios.org -w 300,10% -c 1000,50% -p 5 -t 60 CMD: /bin/ping -n -U -w 60 -c 5 nagios.org Output: PING nagios.org (66.118.156.22) 56(84) bytes of data. Output: 64 bytes from 66.118.156.22: icmp_seq=1 ttl=45 time=435 ms Output: 64 bytes from 66.118.156.22: icmp_seq=2 ttl=45 time=395 ms Output: 64 bytes from 66.118.156.22: icmp_seq=3 ttl=45 time=345 ms Output: 64 bytes from 66.118.156.22: icmp_seq=4 ttl=45 time=435 ms Output: 64 bytes from 66.118.156.22: icmp_seq=5 ttl=45 time=435 ms Output: Output: --- nagios.org ping statistics --- Output: 5 packets transmitted, 5 received, 0% packet loss, time 4000ms Output: rtt min/avg/max/mdev = 345.846/409.540/435.725/35.383 ms PING WARNING - Packet loss = 0%, RTA = 409.54 ms|rta=409.540009ms;300.000000;1000.000000;0.000000 pl=0%;10;50;0 300.000000:10% 1000.000000:50% Yes... That's better, but why is it that I don't have the problem with a system ping to a domain name? dig nagios.org returns -> Query time: 3 msec On Fri, Jun 20, 2008 at 11:00 PM, Holger Weiss wrote: > * Eddie F [2008-06-20 22:53]: > > Here it is with "-vvv" ... > > > > # /usr/local/nagios/libexec/check_ping -vvv -H nagios.org -w 300,10% -c > 1000,50% -p 5 > > CMD: /bin/ping -n -U -w 10 -c 5 nagios.org > > Output: PING nagios.org (66.118.156.22) 56(84) bytes of data. > > Output: 64 bytes from 66.118.156.22: icmp_seq=1 ttl=45 time=368 ms > > CRITICAL - Plugin timed out after 10 seconds > > So it seems to work, apart from the fact that it runs into the timeout. > Maybe ping(1)'s DNS resolution is very slow on your system for some > reason? Does it work if you increase the plugin timeout by using e.g. > "check_ping -t 60 ..."? > > Holger > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________________ > 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 holger at CIS.FU-Berlin.DE Fri Jun 20 15:36:13 2008 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Fri, 20 Jun 2008 15:36:13 +0200 Subject: [Nagiosplug-devel] How do we report a possible bug (in check_ping)? In-Reply-To: <12b44e560806200620k1ae7a5d6od567a1e390b5df14@mail.gmail.com> References: <12b44e560806192339j4e9af4cem3ed67d6ec908c3a5@mail.gmail.com> <20080620120420.GF71490193@CIS.FU-Berlin.DE> <12b44e560806200553u291cb68boef9170bef32cb193@mail.gmail.com> <20080620130031.GG71490193@CIS.FU-Berlin.DE> <12b44e560806200620k1ae7a5d6od567a1e390b5df14@mail.gmail.com> Message-ID: <20080620133613.GI71490193@CIS.FU-Berlin.DE> * Eddie F [2008-06-20 23:20]: > # /usr/local/nagios/libexec/check_ping -vvv -H nagios.org -w 300,10% -c > 1000,50% -p 5 -t 60 > CMD: /bin/ping -n -U -w 60 -c 5 nagios.org > Output: PING nagios.org (66.118.156.22) 56(84) bytes of data. > Output: 64 bytes from 66.118.156.22: icmp_seq=1 ttl=45 time=435 ms > Output: 64 bytes from 66.118.156.22: icmp_seq=2 ttl=45 time=395 ms > Output: 64 bytes from 66.118.156.22: icmp_seq=3 ttl=45 time=345 ms > Output: 64 bytes from 66.118.156.22: icmp_seq=4 ttl=45 time=435 ms > Output: 64 bytes from 66.118.156.22: icmp_seq=5 ttl=45 time=435 ms > Output: > Output: --- nagios.org ping statistics --- > Output: 5 packets transmitted, 5 received, 0% packet loss, time 4000ms > Output: rtt min/avg/max/mdev = 345.846/409.540/435.725/35.383 ms > PING WARNING - Packet loss = 0%, RTA = 409.54 > ms|rta=409.540009ms;300.000000;1000.000000;0.000000 pl=0%;10;50;0 > 300.000000:10% 1000.000000:50% > > > Yes... That's better, but why is it that I don't have the problem with a > system ping to a domain name? Is there some identifiable point during the execution of the above plugin command where the plugin or ping(1) seems to be really slow? Is running the command $ /bin/ping -n -U -w 60 -c 5 nagios.org manually significantly faster? > dig nagios.org returns -> Query time: 3 msec dig(1) queries a name server directly while your system's resolver might use stuff like nscd(8) or whatever. Holger From bigedd at gmail.com Fri Jun 20 15:47:00 2008 From: bigedd at gmail.com (Eddie F) Date: Fri, 20 Jun 2008 23:47:00 +1000 Subject: [Nagiosplug-devel] How do we report a possible bug (in check_ping)? In-Reply-To: <20080620133613.GI71490193@CIS.FU-Berlin.DE> References: <12b44e560806192339j4e9af4cem3ed67d6ec908c3a5@mail.gmail.com> <20080620120420.GF71490193@CIS.FU-Berlin.DE> <12b44e560806200553u291cb68boef9170bef32cb193@mail.gmail.com> <20080620130031.GG71490193@CIS.FU-Berlin.DE> <12b44e560806200620k1ae7a5d6od567a1e390b5df14@mail.gmail.com> <20080620133613.GI71490193@CIS.FU-Berlin.DE> Message-ID: <12b44e560806200647p750d08c2le3c8dce2e6071d37@mail.gmail.com> This starts pinging almost instantly... # /bin/ping -n -U -w 60 -c 5 nagios.org check_ping takes several seconds to start pinging. On Fri, Jun 20, 2008 at 11:36 PM, Holger Weiss wrote: > > > Is there some identifiable point during the execution of the above > plugin command where the plugin or ping(1) seems to be really slow? Is > running the command > > $ /bin/ping -n -U -w 60 -c 5 nagios.org > > manually significantly faster? > > > dig nagios.org returns -> Query time: 3 msec > > dig(1) queries a name server directly while your system's resolver might > use stuff like nscd(8) or whatever. > > Holger > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bigedd at gmail.com Fri Jun 20 16:02:59 2008 From: bigedd at gmail.com (Eddie F) Date: Sat, 21 Jun 2008 00:02:59 +1000 Subject: [Nagiosplug-devel] How do we report a possible bug (in check_ping)? In-Reply-To: <12b44e560806200647p750d08c2le3c8dce2e6071d37@mail.gmail.com> References: <12b44e560806192339j4e9af4cem3ed67d6ec908c3a5@mail.gmail.com> <20080620120420.GF71490193@CIS.FU-Berlin.DE> <12b44e560806200553u291cb68boef9170bef32cb193@mail.gmail.com> <20080620130031.GG71490193@CIS.FU-Berlin.DE> <12b44e560806200620k1ae7a5d6od567a1e390b5df14@mail.gmail.com> <20080620133613.GI71490193@CIS.FU-Berlin.DE> <12b44e560806200647p750d08c2le3c8dce2e6071d37@mail.gmail.com> Message-ID: <12b44e560806200702m4fd5342ckaea35394e85fe50b@mail.gmail.com> Even check_ping to "localhost" takes a while to start. On Fri, Jun 20, 2008 at 11:47 PM, Eddie F wrote: > This starts pinging almost instantly... > # /bin/ping -n -U -w 60 -c 5 nagios.org > > check_ping takes several seconds to start pinging. > > > > On Fri, Jun 20, 2008 at 11:36 PM, Holger Weiss > wrote: > >> >> >> Is there some identifiable point during the execution of the above >> plugin command where the plugin or ping(1) seems to be really slow? Is >> running the command >> >> $ /bin/ping -n -U -w 60 -c 5 nagios.org >> >> manually significantly faster? >> >> > dig nagios.org returns -> Query time: 3 msec >> >> dig(1) queries a name server directly while your system's resolver might >> use stuff like nscd(8) or whatever. >> >> Holger >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ton.voon at altinity.com Fri Jun 20 16:24:25 2008 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 20 Jun 2008 15:24:25 +0100 Subject: [Nagiosplug-devel] How do we report a possible bug (in check_ping)? In-Reply-To: <12b44e560806200702m4fd5342ckaea35394e85fe50b@mail.gmail.com> References: <12b44e560806192339j4e9af4cem3ed67d6ec908c3a5@mail.gmail.com> <20080620120420.GF71490193@CIS.FU-Berlin.DE> <12b44e560806200553u291cb68boef9170bef32cb193@mail.gmail.com> <20080620130031.GG71490193@CIS.FU-Berlin.DE> <12b44e560806200620k1ae7a5d6od567a1e390b5df14@mail.gmail.com> <20080620133613.GI71490193@CIS.FU-Berlin.DE> <12b44e560806200647p750d08c2le3c8dce2e6071d37@mail.gmail.com> <12b44e560806200702m4fd5342ckaea35394e85fe50b@mail.gmail.com> Message-ID: On 20 Jun 2008, at 15:02, Eddie F wrote: > Even check_ping to "localhost" takes a while to start. I think this is the long standing "I'm going to see if I can resolve this hostname before I call the external executable" issue. There's a bit in check_procs which does a is_host (or something similar). Can you remove that and see if it speeds it up? I think it is, by default, making ipv6 record calls to the resolver. Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From noreply at sourceforge.net Fri Jun 20 16:40:25 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jun 2008 14:40:25 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1993363 ] check_procs times out on Solaris 10 Message-ID: Bugs item #1993363, was opened at 2008-06-13 16:58 Message generated for change (Comment added) made by maemigh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1993363&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: maemigh (maemigh) Assigned to: Ton Voon (tonvoon) Summary: check_procs times out on Solaris 10 Initial Comment: I'm having problems with the latest snapshot of check_procs timing out. The version is v1991 (nagios-plugins 1.4.12). This is using pst3 included with the plugins. ./check_procs CRITICAL - Plugin timed out after 10 seconds ./check_procs -w 2:2 -c 2:2 -C nagios CRITICAL - Plugin timed out after 10 seconds I've tried sparc and x86 builds, both timeout: Solaris 5.10 Generic_118833-36 sparc Solaris Generic_127112-11 i386 ---------------------------------------------------------------------- >Comment By: maemigh (maemigh) Date: 2008-06-20 10:40 Message: Logged In: YES user_id=1520524 Originator: YES SVN from 6-19 is causing a segfault on one of our Solaris 9 servers: Here is some output from truss: stat("/usr/platform/SUNW,Sun-Fire-V240/lib/sparcv9/libkvm_psr.so.1", 0xFFFFFFFF7FFFE8D0) Err#2 ENOENT brk(0x100102520) = 0 brk(0x100106520) = 0 stat("/dev/kmem", 0xFFFFFFFF7FFFF2D0) = 0 stat("/dev/mem", 0xFFFFFFFF7FFFF250) = 0 stat("/dev/kmem", 0xFFFFFFFF7FFFF1D0) = 0 stat("/dev/allkmem", 0xFFFFFFFF7FFFF150) = 0 open("/dev/kmem", O_RDONLY) = 3 open("/dev/mem", O_RDONLY) = 4 open("/dev/ksyms", O_RDONLY) = 5 read(5, "7F E L F020201\0\0\0\0\0".., 16) = 16 lseek(5, 0, SEEK_SET) = 0 lseek(5, 0, SEEK_END) = 895494 mmap(0x00000000, 895494, PROT_READ, MAP_PRIVATE, 5, 0) = 0xFFFFFFFF7E300000 munmap(0xFFFFFFFF7E300000, 895494) = 0 close(5) = 0 pread(3, "\0\0030E92 " u p", 8, 0x0142C300) = 8 pread(3, "\0\0030E92 " u p", 8, 0x0142C300) = 8 ioctl(1, TCGETA, 0xFFFFFFFF7FFFE14C) = 0 fstat(1, 0xFFFFFFFF7FFFE0E0) = 0 S UID PID PPID VSZ RSS %CPU COMMAND ARGS write(1, " S U I D P I".., 52) = 52 pread(3, "\0\003\005F7 5 0\0\003\0".., 2584, 0x30E92227570) = 2584 pread(3, "\0\0 Z ?", 4, 0x30003070C4C) = 4 pread(3, "\0\0\0 R\0\0 Z ?\0\0\0\0".., 32, 0x30003070C48) = 32 open("/proc/23103/as", O_RDONLY) = 5 pread(5, "FFFFFFFF7FFFFD\0\0\0\0\0".., 1240, 0xFFFFFFFF7FFFFB28) = 1240 close(5) = 0 open("/proc/23103/psinfo", O_RDONLY) = 5 read(5, "\b\0C4 H\0\0\001\0\0 Z ?".., 416) = 416 close(5) = 0 O 0 23103 23102 2096 1160 0.1 pst3 ./pst3 write(1, " O 0 2 3 1 0".., 52) = 52 pread(3, "\0\003\01CE6D6 8\0\003\0".., 2584, 0x3000513A120) = 2584 pread(3, "\0\0 Z >", 4, 0x3000316EA84) = 4 pread(3, "\0\0\0 u\0\0 Z >\0\0\0\0".., 32, 0x3000316EA80) = 32 open("/proc/23102/as", O_RDONLY) = 5 pread(5, "FFFFFFFF7FFFFCE8FFFFFFFF".., 1272, 0xFFFFFFFF7FFFFB08) = 1272 close(5) = 0 open("/proc/23102/psinfo", O_RDONLY) = 5 read(5, "\b02 @\b\0\0\002\0\0 Z >".., 416) = 416 close(5) = 0 S 0 23102 22954 2800 1784 0.1 truss truss ./pst3 write(1, " S 0 2 3 1 0".., 59) = 59 pread(3, "\0\003\001 -A8 p\0\003\0".., 2584, 0x3000253B450) = 2584 pread(3, "\0\0 YAA", 4, 0x30002D0DF6C) = 4 pread(3, "\0\0\019\0\0 YAA\0\0030E".., 32, 0x30002D0DF68) = 32 open("/proc/22954/as", O_RDONLY) = 5 pread(5, "FFBFFF p\0\0\0\0FFBFFF t".., 188, 0xFFBFFF44) = 188 close(5) = 0 brk(0x100106520) = 0 brk(0x10091E520) = 0 Incurred fault #6, FLTBOUNDS %pc = 0xFFFFFFFF7F400648 siginfo: SIGSEGV SEGV_MAPERR addr=0x101131598 Received signal #11, SIGSEGV [default] siginfo: SIGSEGV SEGV_MAPERR addr=0x101131598 ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2008-06-19 14:31 Message: Logged In: YES user_id=1520524 Originator: YES PS_COMMAND was set, but it was set to a location that didn't exist. I was running the check_procs command without first doing a make install. I'm thinking that the plugin should probably report that /usr/local/nagios/libexec/pst3 doesn't exist rather than timing out after 10 seconds. I ran into another problem with pst3 in that it will not run inside a Solaris zone (as /dev/kmem does not exist) -- are there plans to make changes to allow for use in zones? ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2008-06-17 05:23 Message: Logged In: YES user_id=664364 Originator: NO Sorry, misread your report. So are you saying that PS_COMMAND is not set? ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2008-06-17 05:22 Message: Logged In: YES user_id=664364 Originator: NO Hi maemigh, The issue is that pst3 times out as it is taking too long to query. We've found this on a master host with multiple zones. Please try the snapshot at http://nagiosplug.sf.net/snapshot as pst3 has been optimised to make less kvm calls. It would be useful if you could give us timings before and after the snapshot. Beware, we've recently found an issue where it can coredump if a process disappears as it is trying to access it - a fix is due soon. Ton ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2008-06-16 16:32 Message: Logged In: YES user_id=1520524 Originator: YES Had time to do a little more digging. This happens if the file pointed to by PS_COMMAND does not exist. There do not appear to be any checks within spopen to handle a return code from execve in the event of an error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1993363&group_id=29880 From bigedd at gmail.com Sat Jun 21 06:33:53 2008 From: bigedd at gmail.com (Eddie F) Date: Sat, 21 Jun 2008 14:33:53 +1000 Subject: [Nagiosplug-devel] How do we report a possible bug (in check_ping)? In-Reply-To: References: <12b44e560806192339j4e9af4cem3ed67d6ec908c3a5@mail.gmail.com> <20080620120420.GF71490193@CIS.FU-Berlin.DE> <12b44e560806200553u291cb68boef9170bef32cb193@mail.gmail.com> <20080620130031.GG71490193@CIS.FU-Berlin.DE> <12b44e560806200620k1ae7a5d6od567a1e390b5df14@mail.gmail.com> <20080620133613.GI71490193@CIS.FU-Berlin.DE> <12b44e560806200647p750d08c2le3c8dce2e6071d37@mail.gmail.com> <12b44e560806200702m4fd5342ckaea35394e85fe50b@mail.gmail.com> Message-ID: <12b44e560806202133x7f2dfa38i773ce382f2134580@mail.gmail.com> Sorry, but you've lost me. How and where do I do that? On Sat, Jun 21, 2008 at 12:24 AM, Ton Voon wrote: > > On 20 Jun 2008, at 15:02, Eddie F wrote: > > > Even check_ping to "localhost" takes a while to start. > > > I think this is the long standing "I'm going to see if I can resolve > this hostname before I call the external executable" issue. There's a > bit in check_procs which does a is_host (or something similar). Can > you remove that and see if it speeds it up? > > I think it is, by default, making ipv6 record calls to the resolver. > > Ton > > http://www.altinity.com > UK: +44 (0)870 787 9243 > US: +1 866 879 9184 > Fax: +44 (0)845 280 1725 > Skype: tonvoon > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________________ > 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 noreply at sourceforge.net Sat Jun 21 08:04:34 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 21 Jun 2008 06:04:34 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1999319 ] check_ntp_peer buffer overflow Message-ID: Bugs item #1999319, was opened at 2008-06-21 08:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1999319&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: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heim (g_phreak) Assigned to: Nobody/Anonymous (nobody) Summary: check_ntp_peer buffer overflow Initial Comment: check_ntp_peer v1991 (nagios-plugins 1.4.12) commandline: /usr/lib/nagios/plugins/check_ntp_peer -H ptbtime1.ptb.de -w 120 -c 240 OS: SLES10 SP2 (i586) GCC: gcc-4.1.2_20070115-0.21 GLIBC: glibc-2.4-31.54 gdb backtrace: (gdb) file /usr/lib/nagios/plugins/check_ntp_peer Reading symbols from /usr/lib/nagios/plugins/check_ntp_peer...Reading symbols from /usr/lib/debug/usr/lib/nagios/plugins/check_ntp_peer.debug...done. Using host libthread_db library "/lib/libthread_db.so.1". done. (gdb) set args -H ptbtime1.ptb.de -w 120 -c 240 (gdb) run Starting program: /usr/lib/nagios/plugins/check_ntp_peer -H ptbtime1.ptb.de -w 120 -c 240 *** buffer overflow detected ***: /usr/lib/nagios/plugins/check_ntp_peer terminated ======= Backtrace: ========= /lib/libc.so.6(__chk_fail+0x41)[0xb7e89071] /lib/libc.so.6(__read_chk+0x50)[0xb7e89510] /usr/lib/nagios/plugins/check_ntp_peer[0x8049e9b] /usr/lib/nagios/plugins/check_ntp_peer[0x804a95e] /lib/libc.so.6(__libc_start_main+0xdc)[0xb7dcc8ac] /usr/lib/nagios/plugins/check_ntp_peer[0x8048e71] ======= Memory map: ======== 08048000-0804f000 r-xp 00000000 08:02 346900 /usr/lib/nagios/plugins/check_ntp_peer 0804f000-08050000 rw-p 00006000 08:02 346900 /usr/lib/nagios/plugins/check_ntp_peer 08050000-08071000 rw-p 08050000 00:00 0 [heap] b7d76000-b7d80000 r-xp 00000000 08:02 180638 /lib/libgcc_s.so.1 b7d80000-b7d81000 rw-p 00009000 08:02 180638 /lib/libgcc_s.so.1 b7d81000-b7db6000 r--s 00000000 08:02 383495 /var/run/nscd/dbMurBjs (deleted) b7db6000-b7db7000 rw-p b7db6000 00:00 0 b7db7000-b7edc000 r-xp 00000000 08:02 180596 /lib/libc-2.4.so b7edc000-b7ede000 r--p 00124000 08:02 180596 /lib/libc-2.4.so b7ede000-b7ee0000 rw-p 00126000 08:02 180596 /lib/libc-2.4.so b7ee0000-b7ee4000 rw-p b7ee0000 00:00 0 b7ee4000-b7ee6000 r-xp 00000000 08:02 180602 /lib/libdl-2.4.so b7ee6000-b7ee8000 rw-p 00001000 08:02 180602 /lib/libdl-2.4.so b7ee8000-b7f0b000 r-xp 00000000 08:02 180604 /lib/libm-2.4.so b7f0b000-b7f0d000 rw-p 00022000 08:02 180604 /lib/libm-2.4.so b7f0d000-b7f1c000 r-xp 00000000 08:02 180624 /lib/libresolv-2.4.so b7f1c000-b7f1e000 rw-p 0000e000 08:02 180624 /lib/libresolv-2.4.so b7f1e000-b7f20000 rw-p b7f1e000 00:00 0 b7f20000-b7f31000 r-xp 00000000 08:02 180607 /lib/libnsl-2.4.so b7f31000-b7f33000 rw-p 00010000 08:02 180607 /lib/libnsl-2.4.so b7f33000-b7f35000 rw-p b7f33000 00:00 0 b7f3e000-b7f3f000 rw-p b7f3e000 00:00 0 b7f3f000-b7f59000 r-xp 00000000 08:02 180589 /lib/ld-2.4.so b7f59000-b7f5b000 rw-p 0001a000 08:02 180589 /lib/ld-2.4.so bf962000-bf978000 rw-p bf962000 00:00 0 [stack] ffffe000-fffff000 ---p 00000000 00:00 0 [vdso] Program received signal SIGABRT, Aborted. 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7ddf8d0 in raise () from /lib/libc.so.6 #2 0xb7de0ff3 in abort () from /lib/libc.so.6 #3 0xb7e14f9b in __libc_message () from /lib/libc.so.6 #4 0xb7e89071 in __chk_fail () from /lib/libc.so.6 #5 0xb7e89510 in __read_chk () from /lib/libc.so.6 #6 0x08049e9b in ntp_request (host=0x8050130 "ptbtime1.ptb.de", offset=0xbf9745a0, offset_result=0xbf9745b4, jitter=0xbf974598, stratum=0xbf9745b0) at /usr/include/bits/unistd.h:34 #7 0x0804a95e in main (argc=7, argv=0xbf974664) at check_ntp_peer.c:572 #8 0xb7dcc8ac in __libc_start_main () from /lib/libc.so.6 #9 0x08048e71 in _start () Thanks a lot. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1999319&group_id=29880 From bigedd at gmail.com Mon Jun 23 04:56:39 2008 From: bigedd at gmail.com (Eddie) Date: Mon, 23 Jun 2008 12:56:39 +1000 Subject: [Nagiosplug-devel] How do we report a possible bug (in check_ping)? In-Reply-To: <12b44e560806200702m4fd5342ckaea35394e85fe50b@mail.gmail.com> References: <12b44e560806192339j4e9af4cem3ed67d6ec908c3a5@mail.gmail.com> <20080620120420.GF71490193@CIS.FU-Berlin.DE> <12b44e560806200553u291cb68boef9170bef32cb193@mail.gmail.com> <20080620130031.GG71490193@CIS.FU-Berlin.DE> <12b44e560806200620k1ae7a5d6od567a1e390b5df14@mail.gmail.com> <20080620133613.GI71490193@CIS.FU-Berlin.DE> <12b44e560806200647p750d08c2le3c8dce2e6071d37@mail.gmail.com> <12b44e560806200702m4fd5342ckaea35394e85fe50b@mail.gmail.com> Message-ID: <12b44e560806221956j2b3f3be0md69cce92d906970e@mail.gmail.com> Well it seems that check_icmp works fine, so I'll just use that instead of check_ping. Thanks anyway. On Sat, Jun 21, 2008 at 12:02 AM, Eddie F wrote: > Even check_ping to "localhost" takes a while to start. > > > > On Fri, Jun 20, 2008 at 11:47 PM, Eddie F wrote: > >> This starts pinging almost instantly... >> # /bin/ping -n -U -w 60 -c 5 nagios.org >> >> check_ping takes several seconds to start pinging. >> >> >> >> On Fri, Jun 20, 2008 at 11:36 PM, Holger Weiss >> wrote: >> >>> >>> >>> Is there some identifiable point during the execution of the above >>> plugin command where the plugin or ping(1) seems to be really slow? Is >>> running the command >>> >>> $ /bin/ping -n -U -w 60 -c 5 nagios.org >>> >>> manually significantly faster? >>> >>> > dig nagios.org returns -> Query time: 3 msec >>> >>> dig(1) queries a name server directly while your system's resolver might >>> use stuff like nscd(8) or whatever. >>> >>> Holger >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pemca at tdc.dk Mon Jun 23 10:54:28 2008 From: pemca at tdc.dk (Peter Michael Calum) Date: Mon, 23 Jun 2008 10:54:28 +0200 Subject: [Nagiosplug-devel] Problem with check_sun_hardware plugin Message-ID: Hi I'm using the sun_hardware plugin and it works fine on V240 / Solaris 9, but i found a couple of problems i want to report, and hopefully gets corrected :) I'ts concerning the cpu check, where i found 2 errors - On solaris 10 CPU state is returnes as "on-line" instead of online (see my correction below) - On V245 servers with solaris 10 the subroutine check_cpu is called 5 times, i dont know why and i havent been able to correct it. Please mail me if you want printouts from the server. sub check_cpu { my (%cpu) = %{(shift)}; my $res = $ERRORS{'OK'}; if (!(($cpu{'State'} eq 'online') || ($cpu{'State'} eq 'on-line'))) { $res_str .= "CPU $cpu{'cpuid'}: $cpu{'State'}; ";^M $res = $ERRORS{'CRITICAL'};^M } $res_str .= "CPU $cpu{'cpuid'}: OK; " if(($res == $ERRORS{'OK'}) && !defined($opt_errors_only)); return $res; } V245 test (solaris 10) # ./check_sun_hardware -c cpu -d SUNW,UltraSPARC-IIIi (cpu, 9700000108) :_fru_parent (9700000890H) :StateBegin Tue Feb 26 14:43:50 2008 :FPUType sparcv9 :ProcessorType sparcv9 :State on-line :ID 0 :UnitAddress 0,0 :ecache-size 0x100000 :reg 00 00 04 00 00 00 00 00 00 00 00 00 00 01 00 00 :portid 0 :cpuid 0 :device_type cpu :icache-size 0x8000 :icache-line-size 0x20 :icache-associativity 0x4 :#itlb-entries 0x10 :dcache-size 0x10000 :dcache-line-size 0x20 :dcache-associativity 0x4 :#dtlb-entries 0x10 :sparc-version 0x9 :ecache-line-size 0x40 :ecache-associativity 0x4 :mask# 0x34 :implementation# 0x16 :manufacturer# 0x3e :clock-frequency 0x59a53800 :clock-divisors 00 00 00 01 00 00 00 02 00 00 00 20 :pm-components (9700000111TBL) | NAME=CPU Speed | | 1=1/32 of Normal | | 2=1/2 of Normal | | 3=Normal | :devfs-path /SUNW,UltraSPARC-IIIi at 0,0 :driver-name us :binding-name SUNW,UltraSPARC-IIIi :bus-addr 0,0 :instance 0 :_class cpu :name SUNW,UltraSPARC-IIIi Use of uninitialized value in string eq at ./check_sun_hardware line 156, line 41. Use of uninitialized value in string eq at ./check_sun_hardware line 156, line 41. Use of uninitialized value in concatenation (.) or string at ./check_sun_hardware line 157, line 41. Use of uninitialized value in concatenation (.) or string at ./check_sun_hardware line 157, line 41. Use of uninitialized value in string eq at ./check_sun_hardware line 156, line 41. Use of uninitialized value in string eq at ./check_sun_hardware line 156, line 41. Use of uninitialized value in concatenation (.) or string at ./check_sun_hardware line 157, line 41. Use of uninitialized value in concatenation (.) or string at ./check_sun_hardware line 157, line 41. Use of uninitialized value in string eq at ./check_sun_hardware line 156, line 41. Use of uninitialized value in string eq at ./check_sun_hardware line 156, line 41. Use of uninitialized value in concatenation (.) or string at ./check_sun_hardware line 157, line 41. Use of uninitialized value in concatenation (.) or string at ./check_sun_hardware line 157, line 41. Use of uninitialized value in string eq at ./check_sun_hardware line 156, line 41. Use of uninitialized value in string eq at ./check_sun_hardware line 156, line 41. Use of uninitialized value in concatenation (.) or string at ./check_sun_hardware line 157, line 41. Use of uninitialized value in concatenation (.) or string at ./check_sun_hardware line 157, line 41. Result string: CPU 0: OK; CPU : ; CPU : ; CPU : ; CPU : ; Performance data: CRITICAL: CPU 0: OK; CPU : ; CPU : ; CPU : ; CPU : ; # Thanks, Kind regards Peter Calum -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Tue Jun 24 16:59:17 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jun 2008 14:59:17 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2001832 ] check_icmp with TOS set-option Message-ID: Patches item #2001832, was opened at 2008-06-24 14:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2001832&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: Enhancement Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: oni303 (oni303) Assigned to: Nobody/Anonymous (nobody) Summary: check_icmp with TOS set-option Initial Comment: I have implemented an option to set the TOS bits in the check_icmp.c. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2001832&group_id=29880 From noreply at sourceforge.net Tue Jun 24 20:18:02 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jun 2008 18:18:02 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2001832 ] check_icmp with TOS set-option Message-ID: Patches item #2001832, was opened at 2008-06-24 14:59 Message generated for change (Comment added) made by oni303 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2001832&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: Enhancement Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: oni303 (oni303) Assigned to: Nobody/Anonymous (nobody) Summary: check_icmp with TOS set-option Initial Comment: I have implemented an option to set the TOS bits in the check_icmp.c. ---------------------------------------------------------------------- >Comment By: oni303 (oni303) Date: 2008-06-24 18:18 Message: Logged In: YES user_id=1291087 Originator: YES File Added: check_icmp.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2001832&group_id=29880 From pemca at tdc.dk Tue Jun 24 20:33:54 2008 From: pemca at tdc.dk (Peter Michael Calum) Date: Tue, 24 Jun 2008 20:33:54 +0200 Subject: [Nagiosplug-devel] Problem with check_sun_hardware plugin Message-ID: Hi I'm using the check_sun_hardware plugin and it works fine on V240 / Solaris 9, but i found a couple of problems on Solaris 10 / V245 i want to report, and hopefully gets corrected :) I'ts concerning the check_sun_hardware > cpu check option, where i found 2 errors - On solaris 10 CPU state is returned as "on-line" instead of online (see my correction below) - On V245 servers with solaris 10 the subroutine check_cpu is called 5 times, i dont know why and i havent been able to correct it. Please mail me if you want printouts from the server. sub check_cpu { my (%cpu) = %{(shift)}; my $res = $ERRORS{'OK'}; if (!(($cpu{'State'} eq 'online') || ($cpu{'State'} eq 'on-line'))) { $res_str .= "CPU $cpu{'cpuid'}: $cpu{'State'}; ";^M $res = $ERRORS{'CRITICAL'};^M } $res_str .= "CPU $cpu{'cpuid'}: OK; " if(($res == $ERRORS{'OK'}) && !defined($opt_errors_only)); return $res; } V245 test (solaris 10) # ./check_sun_hardware -c cpu -d SUNW,UltraSPARC-IIIi (cpu, 9700000108) :_fru_parent (9700000890H) :StateBegin Tue Feb 26 14:43:50 2008 :FPUType sparcv9 :ProcessorType sparcv9 :State on-line :ID 0 :UnitAddress 0,0 :ecache-size 0x100000 :reg 00 00 04 00 00 00 00 00 00 00 00 00 00 01 00 00 :portid 0 :cpuid 0 :device_type cpu :icache-size 0x8000 :icache-line-size 0x20 :icache-associativity 0x4 :#itlb-entries 0x10 :dcache-size 0x10000 :dcache-line-size 0x20 :dcache-associativity 0x4 :#dtlb-entries 0x10 :sparc-version 0x9 :ecache-line-size 0x40 :ecache-associativity 0x4 :mask# 0x34 :implementation# 0x16 :manufacturer# 0x3e :clock-frequency 0x59a53800 :clock-divisors 00 00 00 01 00 00 00 02 00 00 00 20 :pm-components (9700000111TBL) | NAME=CPU Speed | | 1=1/32 of Normal | | 2=1/2 of Normal | | 3=Normal | :devfs-path /SUNW,UltraSPARC-IIIi at 0,0 :driver-name us :binding-name SUNW,UltraSPARC-IIIi :bus-addr 0,0 :instance 0 :_class cpu :name SUNW,UltraSPARC-IIIi Use of uninitialized value in string eq at ./check_sun_hardware line 156, line 41. Use of uninitialized value in string eq at ./check_sun_hardware line 156, line 41. Use of uninitialized value in concatenation (.) or string at ./check_sun_hardware line 157, line 41. Use of uninitialized value in concatenation (.) or string at ./check_sun_hardware line 157, line 41. Use of uninitialized value in string eq at ./check_sun_hardware line 156, line 41. Use of uninitialized value in string eq at ./check_sun_hardware line 156, line 41. Use of uninitialized value in concatenation (.) or string at ./check_sun_hardware line 157, line 41. Use of uninitialized value in concatenation (.) or string at ./check_sun_hardware line 157, line 41. Use of uninitialized value in string eq at ./check_sun_hardware line 156, line 41. Use of uninitialized value in string eq at ./check_sun_hardware line 156, line 41. Use of uninitialized value in concatenation (.) or string at ./check_sun_hardware line 157, line 41. Use of uninitialized value in concatenation (.) or string at ./check_sun_hardware line 157, line 41. Use of uninitialized value in string eq at ./check_sun_hardware line 156, line 41. Use of uninitialized value in string eq at ./check_sun_hardware line 156, line 41. Use of uninitialized value in concatenation (.) or string at ./check_sun_hardware line 157, line 41. Use of uninitialized value in concatenation (.) or string at ./check_sun_hardware line 157, line 41. Result string: CPU 0: OK; CPU : ; CPU : ; CPU : ; CPU : ; Performance data: CRITICAL: CPU 0: OK; CPU : ; CPU : ; CPU : ; CPU : ; # Thanks, Kind regards Peter Calum -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Thu Jun 26 19:28:40 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 Jun 2008 17:28:40 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2003302 ] check_disk doesn't handle large zfs filesystems Message-ID: Bugs item #2003302, was opened at 2008-06-26 13:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2003302&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: maemigh (maemigh) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk doesn't handle large zfs filesystems Initial Comment: Check disk seems to work fine for zfs for up to at least 560G filesystems, but doesn't work when tested on 1.3TB filesystems: check_disk -w 5% -c 2% -p /zbackups DISK CRITICAL - free space: /zbackups 0 MB (0% inode=99%);| /zbackups=0MB;1252397;1291946;0;1318313 df -h /zbackups Filesystem size used avail capacity Mounted on zbackups 1.3T 49K 1.3T 1% /zbackups check_disk --version check_disk v1848 (nagios-plugins 1.4.11) This test was performed on Solaris 5.10 Generic_127128-11 i86pc i386 i86pc ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2003302&group_id=29880 From ton.voon at altinity.com Fri Jun 27 00:01:35 2008 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 26 Jun 2008 23:01:35 +0100 Subject: [Nagiosplug-devel] Libtap included in distribution Message-ID: <9506EB0F-1ACA-4882-A5FE-F04BA10801F1@altinity.com> Hi! Based on a comment made by Thomas, I've added the libtap distribution into the nagios plugins project. This enables us to run C tests without a dependency on external code. It includes two changes to the libtap project from http://jc.ngo.org.uk/trac-bin/trac.cgi/wiki/LibTap including disabling LIBPTHREAD and asprintf from gnulib (http://jc.ngo.org.uk/trac-bin/trac.cgi/ticket/32 ). libtap will only get included if ./configure --enable-libtap is set. However, compiling will only take effect if a "make test" is run. I'll see how the tinderbox builds cope tomorrow, but if all goes well, I'll make this version of libtap available on our site. Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From mna.news.anti-spam at libertysurf.fr Fri Jun 27 22:33:53 2008 From: mna.news.anti-spam at libertysurf.fr (mna.news) Date: Fri, 27 Jun 2008 22:33:53 +0200 Subject: [Nagiosplug-devel] check_http / suggest improvment Message-ID: <200806272233.54006.mna.news.anti-spam@libertysurf.fr> morning all, do you think it is possible to add 2 more options to this plugin (check_http) : -> 1 option to save the response of the server in one file for example check_http -o myfile.html -> 1 option to print out the string wich is not found (actually if you do a check_http -s "string_a" -s "string_b" the output of the plugin is set to critical if one of test string is not found but it's says "string 's not found" may be with and specifique sub option of -s (-sv ?) the plugin can output "string_b" was not found ) hope thoses idear will enthousiams. (i beg your pardon for my poor english spoken) thanks to the developpers. mna. From elliott at commscope.com Fri Jun 27 23:01:46 2008 From: elliott at commscope.com (elliott at commscope.com) Date: Fri, 27 Jun 2008 16:01:46 -0500 Subject: [Nagiosplug-devel] Keith Elliott is out of the office. Message-ID: I will be out of the office starting 06/26/2008 and will not return until 07/07/2008. I will respond to your message when I return. From elliott at commscope.com Fri Jun 27 23:01:50 2008 From: elliott at commscope.com (elliott at commscope.com) Date: Fri, 27 Jun 2008 16:01:50 -0500 Subject: [Nagiosplug-devel] Keith Elliott is out of the office. Message-ID: I will be out of the office starting 06/26/2008 and will not return until 07/07/2008. I will respond to your message when I return. From dermoth at aei.ca Mon Jun 30 00:53:54 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Sun, 29 Jun 2008 18:53:54 -0400 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: <9506EB0F-1ACA-4882-A5FE-F04BA10801F1@altinity.com> References: <9506EB0F-1ACA-4882-A5FE-F04BA10801F1@altinity.com> Message-ID: <48681282.6080001@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26/06/08 06:01 PM, Ton Voon wrote: > Hi! > > Based on a comment made by Thomas, I've added the libtap distribution > into the nagios plugins project. This enables us to run C tests > without a dependency on external code. > > It includes two changes to the libtap project from http://jc.ngo.org.uk/trac-bin/trac.cgi/wiki/LibTap > including disabling LIBPTHREAD and asprintf from gnulib (http://jc.ngo.org.uk/trac-bin/trac.cgi/ticket/32 > ). > > libtap will only get included if ./configure --enable-libtap is set. > However, compiling will only take effect if a "make test" is run. > > I'll see how the tinderbox builds cope tomorrow, but if all goes well, > I'll make this version of libtap available on our site. Cool, Ton! If I can find some free time I'll test it on my tinderbox and workstation. We should also encourage tinderbox owners without libtap to use this config option. On a side note, looking at a recent bug report adding -D_FORTIFY_SOURCE to CFLAGS adds a lot of checking and can help uncover bugs (check_ntp_peer fails with this for instance - didn't have time to debug yet). I'm not sure if it's the correct way to enable these extra checks; if it is we should add it to the devmode script (and more importantly remove - -pedantic and some other annoying options). Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIaBKC6dZ+Kt5BchYRAny8AKC4OHz1W4HnKg8ZsfoR/VcQZbrGbwCdGB9h gMzi2vgUXQOIv39sFDbOUCg= =FqIu -----END PGP SIGNATURE----- From holger at CIS.FU-Berlin.DE Mon Jun 30 01:11:31 2008 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Mon, 30 Jun 2008 01:11:31 +0200 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: <48681282.6080001@aei.ca> References: <9506EB0F-1ACA-4882-A5FE-F04BA10801F1@altinity.com> <48681282.6080001@aei.ca> Message-ID: <20080629231131.GF78982989@CIS.FU-Berlin.DE> * Thomas Guyot-Sionnest [2008-06-29 18:53]: > (and more importantly remove -pedantic and some other annoying options). Why is "-pedantic" annoying? This flag tells GCC to warn about the usage of features not supported by the C standard (C89 or C99, depending on other GCC flags; IIRC our goal was to stick with C89 for the moment, but in either case "-pedantic" makes sense IMO). Do we want to use non-standard features? Holger From dermoth at aei.ca Mon Jun 30 01:41:40 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Sun, 29 Jun 2008 19:41:40 -0400 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: <20080629231131.GF78982989@CIS.FU-Berlin.DE> References: <9506EB0F-1ACA-4882-A5FE-F04BA10801F1@altinity.com> <48681282.6080001@aei.ca> <20080629231131.GF78982989@CIS.FU-Berlin.DE> Message-ID: <48681DB4.4020800@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29/06/08 07:11 PM, Holger Weiss wrote: > * Thomas Guyot-Sionnest [2008-06-29 18:53]: >> (and more importantly remove -pedantic and some other annoying options). > > Why is "-pedantic" annoying? This flag tells GCC to warn about the > usage of features not supported by the C standard (C89 or C99, depending > on other GCC flags; IIRC our goal was to stick with C89 for the moment, > but in either case "-pedantic" makes sense IMO). Do we want to use > non-standard features? Ok, maybe I'm talking about the wrong flag. IIRC there were some flags in there that were pretty much useless. Last time I tried devmode it was giving way too many useless warnings... I'll give another shot when I can... Any insight on the - -D_FORTIFY_SOURCE (is there a better way to enable these checks?) Thanks Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIaB206dZ+Kt5BchYRAsqLAJ9DbI7BR+iQjgbgdgAtK5Co2YLH9QCff/Qe AFcCfVbj9RyYaMx1bSPClDM= =83lQ -----END PGP SIGNATURE-----