From noreply at sourceforge.net Sat Dec 2 11:29:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Dec 2006 02:29:59 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1494629 ] 1.4.3 - check_icmp fails after a time on FreeBSD Message-ID: Bugs item #1494629, was opened at 2006-05-25 06:41 Message generated for change (Comment added) made by mfavas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1494629&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: Mark Favas (mfavas) Assigned to: Nobody/Anonymous (nobody) Summary: 1.4.3 - check_icmp fails after a time on FreeBSD Initial Comment: Current release (1.4.3) check_icmp on FreeBSD 6.1 works fine for some hours, then reports 100% packet loss. This is due to the plugin not allowing for the fact that PIDs can be greater than 65535 (i.e. more than 16 bits) on systems such as FreeBSD. Further details are given in http://article.gmane.org/gmane.network.nagios.plugins/1945 . A version of check_icmp available from Andreas fixes this issue. This version has an earlier date associated with it than the version distributed in nagios-plugins, but a higher revsion number. Quote: """ If the fix isn't available in a recent package from the official nagiosplug package you should be able to use the one found at http://oss.op5.se/nagios/check_icmp-2005-06-01.tar.gz You can notice if the fix is available from the nagiosplug project by doing $ grep -q 'pid & 0xffff' check_icmp.c && echo "Fix available" """ ---------------------------------------------------------------------- >Comment By: Mark Favas (mfavas) Date: 2006-12-02 18:29 Message: Logged In: YES user_id=44979 Originator: YES This bug still exists in version 1.4.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1494629&group_id=29880 From noreply at sourceforge.net Sat Dec 2 11:32:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Dec 2006 02:32:09 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1494629 ] 1.4.3 & 1.4.5 - check_icmp fails after a time on FreeBSD Message-ID: Bugs item #1494629, was opened at 2006-05-25 06:41 Message generated for change (Settings changed) made by mfavas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1494629&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: Mark Favas (mfavas) Assigned to: Nobody/Anonymous (nobody) >Summary: 1.4.3 & 1.4.5 - check_icmp fails after a time on FreeBSD Initial Comment: Current release (1.4.3) check_icmp on FreeBSD 6.1 works fine for some hours, then reports 100% packet loss. This is due to the plugin not allowing for the fact that PIDs can be greater than 65535 (i.e. more than 16 bits) on systems such as FreeBSD. Further details are given in http://article.gmane.org/gmane.network.nagios.plugins/1945 . A version of check_icmp available from Andreas fixes this issue. This version has an earlier date associated with it than the version distributed in nagios-plugins, but a higher revsion number. Quote: """ If the fix isn't available in a recent package from the official nagiosplug package you should be able to use the one found at http://oss.op5.se/nagios/check_icmp-2005-06-01.tar.gz You can notice if the fix is available from the nagiosplug project by doing $ grep -q 'pid & 0xffff' check_icmp.c && echo "Fix available" """ ---------------------------------------------------------------------- Comment By: Mark Favas (mfavas) Date: 2006-12-02 18:29 Message: Logged In: YES user_id=44979 Originator: YES This bug still exists in version 1.4.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1494629&group_id=29880 From cmies at gne.de Tue Dec 5 12:29:57 2006 From: cmies at gne.de (Christian Mies) Date: Tue, 05 Dec 2006 12:29:57 +0100 Subject: [Nagiosplug-devel] diff for check_procs - adding performance data Message-ID: <45756636.387F.00C6.3@gne.de> Hi Devel List, I have needed perfdata for the check_procs Command and changed the C - Code. Here it is, and I want to know how do you think about Perfdata for check_procs. The major Problem is the WARN and CRIT Range. I have only added the actual Processcount, no warning and critical values. I'll be glad for suggestions of adding ranges or the Warn and critical Values. Another Idea could be to add the wmin and cmax Values as Warn / Crit Values? regards Christian Mies -------------- next part -------------- A non-text attachment was scrubbed... Name: check_procs.diff Type: application/octet-stream Size: 432 bytes Desc: not available URL: From gavin at openfusion.com.au Thu Dec 7 06:22:18 2006 From: gavin at openfusion.com.au (Gavin Carr) Date: Thu, 7 Dec 2006 16:22:18 +1100 Subject: [Nagiosplug-devel] setuid plugin handling Message-ID: <20061207052218.GA9813@openfusion.com.au> I just noticed that check_dhcp and check_icmp are missing from the rpmforge nagios-plugins package. Turns out this is because of this change in 1.4.3: Setuid plugins (check_dhcp, check_icmp) separated into plugins-root/. Run make install as root to install Since packagers don't like to run things as root, these two (at least) were omitted. Can we change this behaviour to make setuid plugins always install, and then make them setuid if we're installing as root? Making the binaries setuid at make install time is definitely optional - it can be done by the packaging system, or they could even be installed non-setuid and called by sudo, for instance. Thoughts? Cheers, Gavin From seanius at seanius.net Thu Dec 7 07:54:17 2006 From: seanius at seanius.net (sean finney) Date: Thu, 07 Dec 2006 07:54:17 +0100 Subject: [Nagiosplug-devel] setuid plugin handling In-Reply-To: <20061207052218.GA9813@openfusion.com.au> References: <20061207052218.GA9813@openfusion.com.au> Message-ID: <1165474457.1002.1.camel@localhost> hi gavin, On Thu, 2006-12-07 at 16:22 +1100, Gavin Carr wrote: > I just noticed that check_dhcp and check_icmp are missing from the rpmforge > nagios-plugins package. Turns out this is because of this change in 1.4.3: > > Setuid plugins (check_dhcp, check_icmp) separated into plugins-root/. > Run make install as root to install > > Since packagers don't like to run things as root, these two (at least) were > omitted. in debian we use fakeroot for building packages, so even though we're not building as root many of the build scripts think so and as a result we have the plugins in question as part of the default install (though we don't ship them with the setuid bits and document this with rationale and what to do) > Can we change this behaviour to make setuid plugins always install, and then > make them setuid if we're installing as root? Making the binaries setuid at > make install time is definitely optional - it can be done by the packaging > system, or they could even be installed non-setuid and called by sudo, for > instance. i don't have any objection to this, anyway. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From ton.voon at altinity.com Thu Dec 7 12:41:36 2006 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 7 Dec 2006 11:41:36 +0000 Subject: [Nagiosplug-devel] setuid plugin handling In-Reply-To: <20061207052218.GA9813@openfusion.com.au> References: <20061207052218.GA9813@openfusion.com.au> Message-ID: Hi Gavin, On 7 Dec 2006, at 05:22, Gavin Carr wrote: > I just noticed that check_dhcp and check_icmp are missing from the > rpmforge > nagios-plugins package. Turns out this is because of this change in > 1.4.3: > > Setuid plugins (check_dhcp, check_icmp) separated into plugins- > root/. > Run make install as root to install > > Since packagers don't like to run things as root, these two (at > least) were > omitted. > > Can we change this behaviour to make setuid plugins always install, > and then > make them setuid if we're installing as root? Making the binaries > setuid at > make install time is definitely optional - it can be done by the > packaging > system, or they could even be installed non-setuid and called by > sudo, for > instance. When I made this change, I was copying coreutils' behaviour with su (I get a lot of inspiration from their project!). They put a warning up if make install is run without root. A make install-root will install and setuid. If make install-root is run without root, then the chmod u+s will fail, but the executable will still be available and the makefile considers it a success. Then via post-processing or some permissions specified in a spec file, you can add the correct permissions on a package install. So I would recommend for packaging that you use fakeroot or run make install, followed by make install-root. However, you are the second person to ask about this, so it is not obvious. If there is a clamour to change it, we can amend the behaviour. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Thu Dec 7 17:09:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Dec 2006 08:09:59 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1588031 ] check_swap coredump fix for solaris Message-ID: Patches item #1588031, was opened at 2006-10-31 16:57 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1588031&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: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Duncan Ferguson (duncan_ferguson) >Assigned to: Ton Voon (tonvoon) Summary: check_swap coredump fix for solaris Initial Comment: check_swap in plugins 1.4.4 coredumps on solaris (and other SVR4 hosts) when swapctl returns an unexpected value. This patch provides a tidier exit and also checks for some malloc errors in allocating memory for the vars used. I have not amended the BSD section for the same problems since I have no way of testing if the changes I make are sane. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-12-07 16:09 Message: Logged In: YES user_id=664364 Originator: NO Duncan, Thanks for the patch. Turns out part of the problem is the _FILE_OFFSET_BITS definition causes problems in various places. Including sys/stat.h at the beginning of check_swap works, but was better to remove the definition in common.h. Please try the snapshot and let us know if this fixes. Have only tested on a 64bit Solaris 9 server. Ton ---------------------------------------------------------------------- Comment By: Andy Harrison (nachoz) Date: 2006-11-09 19:07 Message: Logged In: YES user_id=27741 I ran into the issue of check_swap dumping core on Solaris 9 (sparc). Using this patch fixed the problem perfectly. Thanx! -- Andy ---------------------------------------------------------------------- Comment By: Duncan Ferguson (duncan_ferguson) Date: 2006-11-01 14:31 Message: Logged In: YES user_id=865292 Updated patch to fix the "Bad Address" problem for solaris. Includes previous patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1588031&group_id=29880 From noreply at sourceforge.net Thu Dec 7 17:11:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Dec 2006 08:11:44 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1573638 ] check_swap SEGV's on Solaris Message-ID: Bugs item #1573638, was opened at 2006-10-09 11:21 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1573638&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Duncan Ferguson (duncan_ferguson) >Assigned to: Ton Voon (tonvoon) Summary: check_swap SEGV's on Solaris Initial Comment: $ ./check_swap -w 20% -c 10% swapctl failed: : Bad address Segmentation Fault(coredump) $ uname -a SunOS xxxx 5.10 Generic_118833-18 sun4u sparc SUNW,Sun-Fire-V440 This is from "nagios-plugins-HEAD-200610082352.tar.gz" It seems to compile ok: === if gcc -DLOCALEDIR=\"/home/loki/fergusod/cvsroot/nagios2/shared/egg-nagios2cl/package/usr/local/nagios2cl/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/sfw//include -I/usr/sfw//include -g -O2 -MT check_swap.o -MD -MP -MF ".deps/check_swap.Tpo" -c -o check_swap.o check_swap.c; \ then mv -f ".deps/check_swap.Tpo" ".deps/check_swap.Po"; else rm -f ".deps/check_swap.Tpo"; exit 1; fi In file included from check_swap.c:33: common.h:216: warning: static declaration of 'floorf' follows non-static declaration /bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -L/usr/sfw/lib -L. -L/usr/sfw//lib -o check_swap check_swap.o -lm utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a popen.o -lsocket -lssl -lcrypto gcc -g -O2 -o check_swap check_swap.o utils.o popen.o -L/usr/sfw/lib -L/tmp/nagios-plugins-HEAD-200610082352/plugins -L/usr/sfw//lib -lm ../lib/libnagiosplug.a ../lib/libcoreutils.a -lsocket -lssl -lcrypto === This appears to be the code at issue ( the SVR4 flag is in effect rather than the BSD one) # ifdef CHECK_SWAP_SWAPCTL_SVR4 /* get the number of active swap devices */ nswaps=swapctl(SC_GETNSWP, NULL); /* initialize swap table + entries */ tbl=(swaptbl_t*)malloc(sizeof(swaptbl_t)+(sizeof(swapent_t)*nswaps)); memset(tbl, 0, sizeof(swaptbl_t)+(sizeof(swapent_t)*nswaps)); tbl->swt_n=nswaps; for(i=0;iswt_ent[i]; ent->ste_path=(char*)malloc(sizeof(char)*MAXPATHLEN); } /* and now, tally 'em up */ swapctl_res=swapctl(SC_LIST, tbl); if(swapctl_res < 0){ perror(_("swapctl failed: ")); result = STATE_WARNING; } ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-12-07 16:11 Message: Logged In: YES user_id=664364 Originator: NO Duncan, Closing this call as this is fixed via patch 1588031. Ton ---------------------------------------------------------------------- Comment By: Duncan Ferguson (duncan_ferguson) Date: 2006-10-31 17:05 Message: Logged In: YES user_id=865292 I have submitted a patch in the tracker for check_swap to fix the coredump on all solaris versions (and other SVR4 hosts) and tidy up the error output a little. However, it still does not work correctly as I keep getting the error "swapctl failed: Bad address". As far as I can tell (with a lot of hacking of the code by commenting out everything possible) if compiled directly using gcc it works, but when using "make" it doesnt, as though something included via common.h, popen.h or utils.h is causing an issue but i have so far been unable to trace the cause. I have also compared the code to an example at http://www.idiom.com/~gford/admin/howto/perf.html#swapctl but there are no disernable differences, leading me to think the issue is outside of this source file. I'll keep hacking incase by luck i find the issue. Duncs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1573638&group_id=29880 From noreply at sourceforge.net Thu Dec 7 17:30:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Dec 2006 08:30:13 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1573700 ] check_swap on HP-UX incorrect Message-ID: Bugs item #1573700, was opened at 2006-10-09 13:34 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1573700&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: Dick van den Burg (vandenburgd) >Assigned to: Ton Voon (tonvoon) Summary: check_swap on HP-UX incorrect Initial Comment: The command that is generated by configure for checking swap on HP-UX is "swapinfo -dfM," and it should be "swapinfo -dfM" (without trailing comma). check_swap now always returns "SWAP WARNING - 100% free (0 MB out of 0 MB) |swap=0MB;0;0;0;0" because it can not interpret the error message generated by the spurious ',' The error is most likely caused by a spurious "'" at line 1754 of configure.in and is propagated to line 42278 of configure in cersion 1.43 of nagios_plugins. A quik workaround is to manually change the SWAP_COMMAND in config.h after configuration. Dick ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-12-07 16:30 Message: Logged In: YES user_id=664364 Originator: NO Dick, Thanks for the report. Unfortunately, I can't find the line you mean as there are 1754 lines in configure.in. Can you take another look? I don't have access to a HP/UX server. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1573700&group_id=29880 From noreply at sourceforge.net Thu Dec 7 17:31:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Dec 2006 08:31:42 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1526072 ] CVS fails to compile on Solaris 9 Message-ID: Bugs item #1526072, was opened at 2006-07-20 19:48 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1526072&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: Pending Resolution: None Priority: 5 Private: No Submitted By: maemigh (maemigh) >Assigned to: Ton Voon (tonvoon) Summary: CVS fails to compile on Solaris 9 Initial Comment: I retrieved the source from CVS and ran into the following error during compilation: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I../intl -I../plugins -I/include -g -O2 -c utils_base.c In file included from ../plugins/common.h:119, from utils_base.c:16: /usr/include/sys/swap.h:47: #error "Cannot use swapctl in the large files compilation environment" gmake[4]: *** [utils_base.o] Error 1 gmake[4]: Leaving directory `/tmp/nagiosplug/lib' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/tmp/nagiosplug/lib' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/tmp/nagiosplug/lib' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/tmp/nagiosplug' gmake: *** [all] Error 2 I took a quick look into it, but I wasn't able to come up with much. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-12-07 16:31 Message: Logged In: YES user_id=664364 Originator: NO maemigh, I think this is resolved now. Can you please try the next snapshot. I've marked the call into pending so it will auto close after 7 days if there is no update. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1526072&group_id=29880 From ton.voon at altinity.com Thu Dec 7 18:34:38 2006 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 7 Dec 2006 17:34:38 +0000 Subject: [Nagiosplug-devel] Solaris problems Message-ID: Hi! I've been working on some Solaris problems for the plugins and I'm stuck on two now. Any help anyone? 1. Linking to ssl libraries. On Solaris, the predominate openssl installation is via the SunFreeware version which is installed in /usr/local/ssl. When compiling applications against this library, it is not sufficient to set LDFLAG =-L/usr/local/ssl/lib, you have to also set -R/usr/local/ ssl/lib in order for the SSL plugins (check_http, check_smtp) to find the openssl directories. I had made a patch for this in configure.in, but Sean removed it, probably rightly (revision 1.191 at http:// nagiosplug.cvs.sourceforge.net/nagiosplug/nagiosplug/configure.in? view=log). However, this means that the plugins will not necessarily run after being compiled. My current workaround is to set LD_RUN_PATH=/usr/ local/ssl/lib before compiling. Is there a better way? To be fair, I've downloaded top, curl and wget and they all have the same issue. The solution could just be a README.solaris. 2. pst3 not working on 64 bit systems I have to admit ignorance here. On my Solaris 9 server, the plugins compile in 32 bit mode. However, pst3 also compiles in 32 bit and then there are errors because the /dev/ksyms holds 64 bit information. What can be done? Should configure work out if the system is 64 bit and compile just pst3 in 64 bit? Or should configure fallback onto using ps? At the moment, check_procs doesn't work from a straight compile on my Sol9 server. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Thu Dec 7 20:48:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Dec 2006 11:48:37 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1573700 ] check_swap on HP-UX incorrect Message-ID: Bugs item #1573700, was opened at 2006-10-09 14:34 Message generated for change (Comment added) made by vandenburgd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1573700&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: Dick van den Burg (vandenburgd) Assigned to: Ton Voon (tonvoon) Summary: check_swap on HP-UX incorrect Initial Comment: The command that is generated by configure for checking swap on HP-UX is "swapinfo -dfM," and it should be "swapinfo -dfM" (without trailing comma). check_swap now always returns "SWAP WARNING - 100% free (0 MB out of 0 MB) |swap=0MB;0;0;0;0" because it can not interpret the error message generated by the spurious ',' The error is most likely caused by a spurious "'" at line 1754 of configure.in and is propagated to line 42278 of configure in cersion 1.43 of nagios_plugins. A quik workaround is to manually change the SWAP_COMMAND in config.h after configuration. Dick ---------------------------------------------------------------------- >Comment By: Dick van den Burg (vandenburgd) Date: 2006-12-07 20:48 Message: Logged In: YES user_id=780242 Originator: YES The error is (in version 1.4.5) at line 1442 of configure.in ac_cv_swap_command="$PATH_TO_SWAPINFO -dfM", The error is the ',' at the end of the line ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-12-07 17:30 Message: Logged In: YES user_id=664364 Originator: NO Dick, Thanks for the report. Unfortunately, I can't find the line you mean as there are 1754 lines in configure.in. Can you take another look? I don't have access to a HP/UX server. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1573700&group_id=29880 From bobi at netshel.net Thu Dec 7 22:31:30 2006 From: bobi at netshel.net (bobi at netshel.net) Date: Thu, 7 Dec 2006 13:31:30 -0800 (PST) Subject: [Nagiosplug-devel] Solaris problems In-Reply-To: References: Message-ID: <10662.216.49.181.128.1165527090.squirrel@webmail.netshel.net> Hi Ton, I'm the trouble-maker who wrote the pst3 program for Solaris. The intent was to get around the 80 character limit on ps output imposed by the built-in ps program and the Solaris library. We have Java processes that we have to monitor that are not differentiable within the first 80 bytes of the command-line displayed by the stock Solaris ps program. In answer to question #1: Try "man crle". This is the Solaris equivalent of Linux's "ldconfig". It allows you to modify the system dynamic link library path, just like ldconfig does under Linux. Therefore, no need to mess around with environment vars, hoping they'll exist when you need them. Of course, the downside is you have to be root (I think,) to run crle. So that's a possibility for #1. As for problem #2. Ouch. I have have Solaris 8 and 9 running in our organization, I guess I really should revisit pst3.c and make sure it runs under both 32-bit and 64-bit mode under Solaris 9. I wrote it when we only had access to Solaris 8 but I did test it under both 32 and 64 bit builds (or so I thought.) Would you like me to try testing it against Solaris 9? (That's the latest we are running.) Hope this helps. Bob > Hi! > > I've been working on some Solaris problems for the plugins and I'm > stuck on two now. Any help anyone? > > 1. Linking to ssl libraries. > > On Solaris, the predominate openssl installation is via the > SunFreeware version which is installed in /usr/local/ssl. When > compiling applications against this library, it is not sufficient to > set LDFLAG =-L/usr/local/ssl/lib, you have to also set -R/usr/local/ > ssl/lib in order for the SSL plugins (check_http, check_smtp) to find > the openssl directories. I had made a patch for this in configure.in, > but Sean removed it, probably rightly (revision 1.191 at http:// > nagiosplug.cvs.sourceforge.net/nagiosplug/nagiosplug/configure.in? > view=log). > > However, this means that the plugins will not necessarily run after > being compiled. My current workaround is to set LD_RUN_PATH=/usr/ > local/ssl/lib before compiling. Is there a better way? > > To be fair, I've downloaded top, curl and wget and they all have the > same issue. The solution could just be a README.solaris. > > 2. pst3 not working on 64 bit systems > > I have to admit ignorance here. On my Solaris 9 server, the plugins > compile in 32 bit mode. However, pst3 also compiles in 32 bit and > then there are errors because the /dev/ksyms holds 64 bit > information. What can be done? Should configure work out if the > system is 64 bit and compile just pst3 in 64 bit? Or should configure > fallback onto using ps? > > At the moment, check_procs doesn't work from a straight compile on my > Sol9 server. > > Ton > > http://www.altinity.com > T: +44 (0)870 787 9243 > F: +44 (0)845 280 1725 > Skype: tonvoon > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________________ > 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 Thu Dec 7 23:39:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Dec 2006 14:39:37 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1573700 ] check_swap on HP-UX incorrect Message-ID: Bugs item #1573700, was opened at 2006-10-09 13:34 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1573700&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Dick van den Burg (vandenburgd) Assigned to: Ton Voon (tonvoon) Summary: check_swap on HP-UX incorrect Initial Comment: The command that is generated by configure for checking swap on HP-UX is "swapinfo -dfM," and it should be "swapinfo -dfM" (without trailing comma). check_swap now always returns "SWAP WARNING - 100% free (0 MB out of 0 MB) |swap=0MB;0;0;0;0" because it can not interpret the error message generated by the spurious ',' The error is most likely caused by a spurious "'" at line 1754 of configure.in and is propagated to line 42278 of configure in cersion 1.43 of nagios_plugins. A quik workaround is to manually change the SWAP_COMMAND in config.h after configuration. Dick ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-12-07 22:39 Message: Logged In: YES user_id=664364 Originator: NO Dick, Thanks for your help. Applied to CVS (though looks like the commit emails have not been sent...) Ton ---------------------------------------------------------------------- Comment By: Dick van den Burg (vandenburgd) Date: 2006-12-07 19:48 Message: Logged In: YES user_id=780242 Originator: YES The error is (in version 1.4.5) at line 1442 of configure.in ac_cv_swap_command="$PATH_TO_SWAPINFO -dfM", The error is the ',' at the end of the line ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-12-07 16:30 Message: Logged In: YES user_id=664364 Originator: NO Dick, Thanks for the report. Unfortunately, I can't find the line you mean as there are 1754 lines in configure.in. Can you take another look? I don't have access to a HP/UX server. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1573700&group_id=29880 From seanius at seanius.net Thu Dec 7 23:47:48 2006 From: seanius at seanius.net (sean finney) Date: Thu, 07 Dec 2006 23:47:48 +0100 Subject: [Nagiosplug-devel] Solaris problems In-Reply-To: References: Message-ID: <1165531668.1093.20.camel@localhost> hey ton, On Thu, 2006-12-07 at 17:34 +0000, Ton Voon wrote: > 1. Linking to ssl libraries. > On Solaris, the predominate openssl installation is via the > SunFreeware version which is installed in /usr/local/ssl. When > compiling applications against this library, it is not sufficient to > set LDFLAG =-L/usr/local/ssl/lib, you have to also set > -R/usr/local/ssl/lib in order for the SSL plugins (check_http, > check_smtp) to find the openssl directories. I had made a patch for > this in configure.in, but Sean removed it, probably rightly (revision > 1.191 at > http://nagiosplug.cvs.sourceforge.net/nagiosplug/nagiosplug/configure.in?view=log). do you still have problems even if you pass --enable-rpath to ./configure? this problem manifests itself whenever an executable is linked against libraries that exist outside of the default search path, which to the OS is the same as the libraries not existing at all. when you compile with -Rfoo, you're explicitly adding directories to be searched when executing a program (stored in the private section of the ELF, try objdump -p check_foo | grep RPATH). from a linux/unix distribution point of view, setting this is generally a bad thing because it leads to inconsistant/non-standard behaviour when run-time linking an object before execution. typically the "Right Way" to handle this (for distros and admins too), is to add these directories to the default library search path so that they're generally available to all programs that might need them. there are cases where rpath is a Good Thing, or is at least justifiable, but usually those are cases where "you know what you're doing". for example, private libraries that *shouldn't* be shared or would otherwise conflict with standard ones (different versions of libraries with unversioned symbols, is one case) > However, this means that the plugins will not necessarily run after > being compiled. My current workaround is to set > LD_RUN_PATH=/usr/local/ssl/lib before compiling. Is there a better > way? if --enable-rpath isn't doing it, something's wrong with our ./configure script. > To be fair, I've downloaded top, curl and wget and they all have the > same issue. The solution could just be a README.solaris. bob mentioned crle, which is probably what you want to mess around with as an analog to ld.so.conf. i haven't had to do this in a while, so i'd defer to the fine manual for the specifics. > 2. pst3 not working on 64 bit systems > I have to admit ignorance here. On my Solaris 9 server, the plugins > compile in 32 bit mode. However, pst3 also compiles in 32 bit and then > there are errors because the /dev/ksyms holds 64 bit information. What > can be done? Should configure work out if the system is 64 bit and > compile just pst3 in 64 bit? Or should configure fallback onto using > ps? okay, again it's been a while, but iirc even "32-bit" solaris still runs a 64-bit kernel (just 32-bit userland, right?). if that's the case we need to differentiate between building a 32/64 bit program from building a program that reads 32/64-bit data objects from kernel memory. even if that's not the case, we still have to do that, only it's a bit harder because we'll have to determine at run time the kernel type. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From gavin at openfusion.com.au Thu Dec 7 23:51:22 2006 From: gavin at openfusion.com.au (Gavin Carr) Date: Fri, 8 Dec 2006 09:51:22 +1100 Subject: [Nagiosplug-devel] setuid plugin handling In-Reply-To: References: <20061207052218.GA9813@openfusion.com.au> Message-ID: <20061207225122.GC12364@openfusion.com.au> Hi Ton, On Thu, Dec 07, 2006 at 11:41:36AM +0000, Ton Voon wrote: > >Can we change this behaviour to make setuid plugins always install, > >and then > >make them setuid if we're installing as root? Making the binaries > >setuid at > >make install time is definitely optional - it can be done by the > >packaging > >system, or they could even be installed non-setuid and called by > >sudo, for > >instance. > > When I made this change, I was copying coreutils' behaviour with su > (I get a lot of inspiration from their project!). They put a warning > up if make install is run without root. A make install-root will > install and setuid. > > If make install-root is run without root, then the chmod u+s will > fail, but the executable will still be available and the makefile > considers it a success. Then via post-processing or some permissions > specified in a spec file, you can add the correct permissions on a > package install. > > So I would recommend for packaging that you use fakeroot or run make > install, followed by make install-root. Okay thanks, that at least makes it straightforward to fix the packages. > However, you are the second person to ask about this, so it is not > obvious. If there is a clamour to change it, we can amend the behaviour. It sounds like 'make install-root' is doing the right thing then - I'd just like it included in 'make install' rather than separate. But I'm not sure I constitute a 'clamour'. :-) Cheers, Gavin From ton.voon at altinity.com Fri Dec 8 01:34:11 2006 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 8 Dec 2006 00:34:11 +0000 Subject: [Nagiosplug-devel] Solaris problems In-Reply-To: <1165531668.1093.20.camel@localhost> References: <1165531668.1093.20.camel@localhost> Message-ID: <25A86D6E-75C7-4500-B773-80BF6ACAE904@altinity.com> Hi Sean, On 7 Dec 2006, at 22:47, sean finney wrote: > > On Thu, 2006-12-07 at 17:34 +0000, Ton Voon wrote: >> 1. Linking to ssl libraries. > >> On Solaris, the predominate openssl installation is via the >> SunFreeware version which is installed in /usr/local/ssl. When >> compiling applications against this library, it is not sufficient to >> set LDFLAG =-L/usr/local/ssl/lib, you have to also set >> -R/usr/local/ssl/lib in order for the SSL plugins (check_http, >> check_smtp) to find the openssl directories. I had made a patch for >> this in configure.in, but Sean removed it, probably rightly (revision >> 1.191 at >> http://nagiosplug.cvs.sourceforge.net/nagiosplug/nagiosplug/ >> configure.in?view=log). > > do you still have problems even if you pass --enable-rpath > to ./configure? > > this problem manifests itself whenever an executable is linked > against libraries that exist outside of the default search path, which > to the OS is the same as the libraries not existing at all. when you > compile with -Rfoo, you're explicitly adding directories to be > searched > when executing a program (stored in the private section of the ELF, > try objdump -p check_foo | grep RPATH). > > from a linux/unix distribution point of view, setting this is > generally > a bad thing because it leads to inconsistant/non-standard behaviour > when run-time linking an object before execution. typically the > "Right > Way" to handle this (for distros and admins too), is to add these > directories to the default library search path so that they're > generally > available to all programs that might need them. Thanks for the explanation. Maybe we should raise a bug with SunFreeware that openssl should be installed and then added to the default library search path system-wide? > there are cases where rpath is a Good Thing, or is at least > justifiable, > but usually those are cases where "you know what you're doing". for > example, private libraries that *shouldn't* be shared or would > otherwise > conflict with standard ones (different versions of libraries with > unversioned symbols, is one case) > > >> However, this means that the plugins will not necessarily run after >> being compiled. My current workaround is to set >> LD_RUN_PATH=/usr/local/ssl/lib before compiling. Is there a better >> way? > > if --enable-rpath isn't doing it, something's wrong with our ./ > configure > script. --enable-rpath doesn't help. I think this is on by default. But... I've been looking at wget's configure.in script and they use a macro called AC_LIB_HAVE_LINKFLAGS. This is defined in the lib-link.m4 macro which we distribute (originally from gettext). Running ./ configure on my Sol9 server, it doesn't detect openssl (because of the default search paths). However, if I define --with-libssl-prefix=/ usr/local/ssl, then it does see the openssl and also comes up with this lovely line: checking how to link with libssl... /usr/local/ssl/lib/libssl.so /usr/ local/ssl/lib/libcrypto.so -R/usr/local/ssl/lib So it manages to know that -R is required. When run with --disable- rpath as well, the -R is removed. (There's some interesting comments in this thread where the opencdk project was adding pkg-config support, but was moving to AC_LIB_HAVE_LINKFLAGS instead: http://thread.gmane.org/ gmane.comp.encryption.gpg.gnutls.devel/1610/focus=1610) wget also has support for gnutls as well (which you'll be pleased about!). AND they don't use libtool - so we could take all the libtool code out (there is a dependency on config.rpath, but that's a single file rather than libtool's huge list). So, should we switch to using that? Downside is that the configure options will have to change. wget have it defined as: (no SSL flags) - autodetect SSL lib, OK if none found --with-ssl - autodetect SSL lib, abort if none found --with-ssl=openssl - use OpenSSL, abort if not found --with-ssl=gnutls - use GnuTLS, abort if not found (from http://www.mail-archive.com/wget at sunsite.dk/msg08130.html) You define the directory using --with-libssl-prefix=/usr/local/ssl. We would lose our autodetection of SSL directories, but I guess that is a good way to go for package maintainers (define exactly which ssl implementations to use)? I'm happy to do the work (we lose lots of libtool files & lots of code gets removed from configure.in - whoopie!) if there's a consensus on this. >> 2. pst3 not working on 64 bit systems > >> I have to admit ignorance here. On my Solaris 9 server, the plugins >> compile in 32 bit mode. However, pst3 also compiles in 32 bit and >> then >> there are errors because the /dev/ksyms holds 64 bit information. >> What >> can be done? Should configure work out if the system is 64 bit and >> compile just pst3 in 64 bit? Or should configure fallback onto using >> ps? > > okay, again it's been a while, but iirc even "32-bit" solaris still > runs > a 64-bit kernel (just 32-bit userland, right?). if that's the case we > need to differentiate between building a 32/64 bit program from > building > a program that reads 32/64-bit data objects from kernel memory. > even if > that's not the case, we still have to do that, only it's a bit harder > because we'll have to determine at run time the kernel type. Here's the ignorance bit - I don't know what you're talking about at all. I'll probably need to see some example code to understand what this work entails. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From seanius at seanius.net Fri Dec 8 12:18:02 2006 From: seanius at seanius.net (sean finney) Date: Fri, 08 Dec 2006 12:18:02 +0100 Subject: [Nagiosplug-devel] Solaris problems In-Reply-To: <25A86D6E-75C7-4500-B773-80BF6ACAE904@altinity.com> References: <1165531668.1093.20.camel@localhost> <25A86D6E-75C7-4500-B773-80BF6ACAE904@altinity.com> Message-ID: <1165576682.9062.74.camel@localhost> On Fri, 2006-12-08 at 00:34 +0000, Ton Voon wrote: > --with-libssl-prefix=/usr/local/ssl, then it does see the openssl and > also comes up with this lovely line: > > > checking how to link with > libssl... /usr/local/ssl/lib/libssl.so /usr/local/ssl/lib/libcrypto.so > -R/usr/local/ssl/lib > > > So it manages to know that -R is required. When run with > --disable-rpath as well, the -R is removed. okay, sounds reasonable. > So, should we switch to using that? Downside is that the configure > options will have to change. wget have it defined as: > > > (no SSL flags) - autodetect SSL lib, OK if none found > --with-ssl - autodetect SSL lib, abort if none found > --with-ssl=openssl - use OpenSSL, abort if not found > --with-ssl=gnutls - use GnuTLS, abort if not found > > > (from http://www.mail-archive.com/wget at sunsite.dk/msg08130.html) > > > You define the directory using --with-libssl-prefix=/usr/local/ssl. We > would lose our autodetection of SSL directories, but I guess that is a > good way to go for package maintainers (define exactly which ssl > implementations to use)? i'm fine with this as an alternative. i'm fairly ambivalent on the matter as long as there's a way for me to continue keeping rpath out. i guess it's the people on solaris who care a little more :) > I'm happy to do the work (we lose lots of libtool files & lots of code > gets removed from configure.in - whoopie!) if there's a consensus on > this. and i'm instantly much more in favor of it :) > > okay, again it's been a while, but iirc even "32-bit" solaris still > > runs > > a 64-bit kernel (just 32-bit userland, right?). if that's the case > > we > > need to differentiate between building a 32/64 bit program from > > building > > a program that reads 32/64-bit data objects from kernel memory. > > even if > > that's not the case, we still have to do that, only it's a bit > > harder > > because we'll have to determine at run time the kernel type. > > > Here's the ignorance bit - I don't know what you're talking about at > all. I'll probably need to see some example code to understand what > this work entails. okay. this all goes with a disclaimer that my memory on what solaris actually does is a bit hazy. but, the general problem and concepts are still the same in any event. - pst3 is reading stuff in kernel memory, so many datatypes therein will have different sizes based on whether the kernel is 32-bit or 64-bit (pointers, offsets, etc). - the userland can be 32-bit or 64-bit, so we need to be careful about the size of datatypes used to store values (use off_t/size_t not int, etc). - there *might* not be a direct correlation between the running kernel and the type of userland (64 bit kernel, 32 bit userland), and the running kernel can only be detected at runtime. in that case things are even more complicated since using off_t/size_t and the like will definitely not work. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From ton.voon at altinity.com Fri Dec 8 15:25:14 2006 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 8 Dec 2006 14:25:14 +0000 Subject: [Nagiosplug-devel] Solaris problems In-Reply-To: <10662.216.49.181.128.1165527090.squirrel@webmail.netshel.net> References: <10662.216.49.181.128.1165527090.squirrel@webmail.netshel.net> Message-ID: <82764F15-09B6-4A4C-B4C3-68DDF4B74410@altinity.com> On 7 Dec 2006, at 21:31, bobi at netshel.net wrote: > Hi Ton, > > I'm the trouble-maker who wrote the pst3 program for Solaris. :) > > The intent was to get around the 80 character limit on ps output > imposed > by the built-in ps program and the Solaris library. We have Java > processes that we have to monitor that are not differentiable > within the > first 80 bytes of the command-line displayed by the stock Solaris ps > program. No problem. I understand the reasons why we have pst3. I think we just need to polish pst3 so it works off a configure on all Solaris systems. > As for problem #2. Ouch. I have have Solaris 8 and 9 running in our > organization, I guess I really should revisit pst3.c and make sure > it runs > under both 32-bit and 64-bit mode under Solaris 9. I wrote it when we > only had access to Solaris 8 but I did test it under both 32 and 64 > bit > builds (or so I thought.) > > Would you like me to try testing it against Solaris 9? (That's the > latest > we are running.) From the conversation with Sean, I think the ideal is that pst3 works when compiled in 32bit or 64bit mode and whether the kernel is 32bit or 64bit. My main problem at the moment is that on a Sol9 server in 64bit mode, the distribution compiles pst3 as 32bit, but the kernel is 64bit, so we get a "/dev/ksyms is not a 32-bit kernel namelist" error. It would be great if you could provide a patch for this (I'm way outside my depth!). Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ton.voon at altinity.com Fri Dec 8 15:26:49 2006 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 8 Dec 2006 14:26:49 +0000 Subject: [Nagiosplug-devel] Solaris problems In-Reply-To: <1165576682.9062.74.camel@localhost> References: <1165531668.1093.20.camel@localhost> <25A86D6E-75C7-4500-B773-80BF6ACAE904@altinity.com> <1165576682.9062.74.camel@localhost> Message-ID: On 8 Dec 2006, at 11:18, sean finney wrote: >> So, should we switch to using that? Downside is that the configure >> options will have to change. wget have it defined as: >> >> >> (no SSL flags) - autodetect SSL lib, OK if none found >> --with-ssl - autodetect SSL lib, abort if none found >> --with-ssl=openssl - use OpenSSL, abort if not found >> --with-ssl=gnutls - use GnuTLS, abort if not found >> >> >> (from http://www.mail-archive.com/wget at sunsite.dk/msg08130.html) >> >> >> You define the directory using --with-libssl-prefix=/usr/local/ >> ssl. We >> would lose our autodetection of SSL directories, but I guess that >> is a >> good way to go for package maintainers (define exactly which ssl >> implementations to use)? > > i'm fine with this as an alternative. i'm fairly ambivalent on the > matter as long as there's a way for me to continue keeping rpath > out. i > guess it's the people on solaris who care a little more :) > >> I'm happy to do the work (we lose lots of libtool files & lots of >> code >> gets removed from configure.in - whoopie!) if there's a consensus on >> this. > > and i'm instantly much more in favor of it :) OK. Unless there's any major objections, I'll start doing this over the next week. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ton.voon at altinity.com Fri Dec 8 15:50:13 2006 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 8 Dec 2006 14:50:13 +0000 Subject: [Nagiosplug-devel] New developers wanted Message-ID: <978D9403-517B-45E6-8284-C56DDE5A25FC@altinity.com> Hi! This is a call for some new developers. There are lots of outstanding bugs and patches on Sourceforge which need to be looked into and we need some help! I'm looking at 2-3 people initially to work on the C based plugins, starting off with helping to fix existing problems. I'm interested in anyone with good C skills, with knowledge of the GNU build system (autoconf, automake) and is interested in automated testing. Prior history of patches would be useful. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From rouilj at cs.umb.edu Fri Dec 8 16:18:37 2006 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Fri, 08 Dec 2006 10:18:37 -0500 Subject: [Nagiosplug-devel] Solaris problems In-Reply-To: Your message of "Fri, 08 Dec 2006 14:25:14 GMT." <82764F15-09B6-4A4C-B4C3-68DDF4B74410@altinity.com> Message-ID: <200612081518.kB8FIbe8010410@mx1.cs.umb.edu> In message <82764F15-09B6-4A4C-B4C3-68DDF4B74410 at altinity.com>, Ton Voon writes: >On 7 Dec 2006, at 21:31, bobi at netshel.net wrote: >> I'm the trouble-maker who wrote the pst3 program for Solaris. >> >> The intent was to get around the 80 character limit on ps output imposed >> by the built-in ps program and the Solaris library. We have Java >> processes that we have to monitor that are not differentiable within the >> first 80 bytes of the command-line displayed by the stock Solaris ps >> program. > >No problem. I understand the reasons why we have pst3. I think we >just need to polish pst3 so it works off a configure on all Solaris >systems. What's wrong with just using "/usr/ucb/ps -uaww"? -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. From bobi at netshel.net Fri Dec 8 20:16:34 2006 From: bobi at netshel.net (bobi at netshel.net) Date: Fri, 8 Dec 2006 11:16:34 -0800 (PST) Subject: [Nagiosplug-devel] Solaris problems In-Reply-To: <200612081518.kB8FIbe8010410@mx1.cs.umb.edu> References: <200612081518.kB8FIbe8010410@mx1.cs.umb.edu> Message-ID: <57065.216.49.181.128.1165605394.squirrel@webmail.netshel.net> Apparently nothing is wrong with "/usr/ucb/ps -uaxwww" except my ignorance of it... Assuming that it exists and works the same way on Solaris 9 and upwards, I vote that pst3 get removed from the distro ASAP and the ps string in the configration for Solaris be replaced with "/usr/ucb/ps -uaxwww" Bob > > In message <82764F15-09B6-4A4C-B4C3-68DDF4B74410 at altinity.com>, > Ton Voon writes: >>On 7 Dec 2006, at 21:31, bobi at netshel.net wrote: >>> I'm the trouble-maker who wrote the pst3 program for Solaris. >>> >>> The intent was to get around the 80 character limit on ps output >>> imposed >>> by the built-in ps program and the Solaris library. We have Java >>> processes that we have to monitor that are not differentiable within >>> the >>> first 80 bytes of the command-line displayed by the stock Solaris ps >>> program. >> >>No problem. I understand the reasons why we have pst3. I think we >>just need to polish pst3 so it works off a configure on all Solaris >>systems. > > What's wrong with just using "/usr/ucb/ps -uaww"? > > -- rouilj > John Rouillard > =========================================================================== > My employers don't acknowledge my existence much less my opinions. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________________ > 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 Fri Dec 8 20:48:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Dec 2006 11:48:01 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1250967 ] broken awk script subst.in Message-ID: Bugs item #1250967, was opened at 2005-08-03 14:53 Message generated for change (Comment added) made by blackraven1977 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1250967&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: nsturm (nsturm) Assigned to: Nobody/Anonymous (nobody) Summary: broken awk script subst.in Initial Comment: The script plugins-scripts/subst.in does things in the wrong order resulting in broken pathnames. As an example look at check_rpc.pl. First "use lib utils.pm;" is substituted by the full path name to utils.pm, but then the first name component is stripped off again (at least on OpenBSD where /usr/local/libexec/nagios/utils.pm becomes just nagios/utils.pm) This is on OpenBSD-current with plugins 1.4 and 1.4.1. Diff attached. ---------------------------------------------------------------------- Comment By: Olexandr Davydenko (blackraven1977) Date: 2006-12-08 21:48 Message: Logged In: YES user_id=1526665 Originator: NO Similar problem on FreeBSD 6.2-RC1 and nagios-plugins-1.4.5 . For example: in nagios-plugins-1.4.3 string in check_mailq.pl "use lib utils.pm;" substituted with full path in installed check_mailq "use lib "/usr/local/libexec/nagios";", but in nagios-plugins-1.4.5 it substituted as "use lib "nagios";" and check_mailq plugin cannot find utils.pm . Patch patch-plugins-scripts_subst_in fix this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1250967&group_id=29880 From ric at DragonElf.NET Sat Dec 9 16:31:29 2006 From: ric at DragonElf.NET (Ric Anderson) Date: Sat, 09 Dec 2006 08:31:29 -0700 Subject: [Nagiosplug-devel] check_ups causes disconnect errors (nagios-plugins-HEAD-200612091252) Message-ID: <200612091531.kB9FVTvC014590@moose.DragonElf.NET> When check_ups (either the one from plugins 1.4.3, or the one from nagios-plugins-HEAD-200612091252) is used, NUT's upsd logs Dec 9 08:06:22 moose upsd[5136]: Host 127.0.0.1 disconnected (read failure) This is because of a protocol botch in talking to upsd, which expects to get a "LOGOUT\n" before the socket is closed. check_ups uses the normal process_tcp_request which doesn't send the "LOGOUT\n", but does close the socket. The patch below is based on nagios-plugins-HEAD-200612091252/plugins/check_ups.c and fixes this problem by having check_ups do a little more work itself. FWIW, Ric -- --- check_ups.c.orig 2006-10-19 16:53:28.000000000 -0700 +++ check_ups.c 2006-12-09 08:26:03.000000000 -0700 @@ -98,6 +98,8 @@ int get_ups_variable (const char *, char *, size_t); int process_arguments (int, char **); +int talk2nut( const char *, int , const char *, char *, int); + int validate_arguments (void); void print_help (void); void print_usage (void); @@ -405,7 +407,7 @@ sprintf (send_buffer, "GET VAR %s %s\n", ups_name, varname); /* send the command to the daemon and get a response back */ - if (process_tcp_request + if (talk2nut (server_address, server_port, send_buffer, temp_buffer, sizeof (temp_buffer)) != STATE_OK) { printf ("%s\n", _("Invalid response received from host")); @@ -653,3 +655,24 @@ printf (_("Usage:")); printf ("%s -H host -u ups [-p port] [-v variable] [-w warn_value] [-c crit_value] [-to to_sec] [-T]\n", progname); } + +int +talk2nut(const char *server_address, int server_port, + const char *send_buffer, char *recv_buffer, int recv_size) +{ char buf[32]; + int result; + int sd; + + result = np_net_connect(server_address, server_port, &sd, + IPPROTO_TCP); + if(result != STATE_OK) + return STATE_CRITICAL; + result = send_request(sd, IPPROTO_TCP, send_buffer, recv_buffer, + recv_size); + if(result == STATE_OK) { + strcpy(buf,"LOGOUT\n"); + (void) send(sd, buf, strlen(buf), 0); + } + close(sd); + return(result); +} -- Ric Anderson, Opus One Systems, 1404 E Lind Road, Tucson, AZ 85719 Phone: +1 520 324 0494 (v) +1 520 324 0495 FAX ric at Opus1.COM (RA90-ARIN) Personal Email: ric at DragonElf.NET UNIX *is* user friendly. It's just selective about who its friends are. From matthias.flittner at nethinks.com Mon Dec 11 08:42:28 2006 From: matthias.flittner at nethinks.com (matthias.flittner at nethinks.com) Date: Mon, 11 Dec 2006 08:42:28 +0100 Subject: [Nagiosplug-devel] No performance data check_procs.c In-Reply-To: Message-ID: The plugin check_procs doesn't put performance data. how can i publish my patch? Greets FliTTi -------------- next part -------------- An HTML attachment was scrubbed... URL: From seanius at seanius.net Mon Dec 11 10:08:12 2006 From: seanius at seanius.net (sean finney) Date: Mon, 11 Dec 2006 10:08:12 +0100 Subject: [Nagiosplug-devel] check_ups causes disconnect errors (nagios-plugins-HEAD-200612091252) In-Reply-To: <200612091531.kB9FVTvC014590@moose.DragonElf.NET> References: <200612091531.kB9FVTvC014590@moose.DragonElf.NET> Message-ID: <1165828092.19675.6.camel@localhost> hi ric, thanks for the info. i've been aware of this problem for a bit via the debian bts, but the original patch i was given caused more problems than it solved. this patch looks much better, i'll check it out. thanks, sean On Sat, 2006-12-09 at 08:31 -0700, Ric Anderson wrote: > When check_ups (either the one from plugins 1.4.3, or the one from > nagios-plugins-HEAD-200612091252) is used, NUT's upsd logs > Dec 9 08:06:22 moose upsd[5136]: Host 127.0.0.1 disconnected (read failure) > This is because of a protocol botch in talking to upsd, which expects > to get a "LOGOUT\n" before the socket is closed. check_ups uses the > normal process_tcp_request which doesn't send the "LOGOUT\n", but > does close the socket. > > The patch below is based on > nagios-plugins-HEAD-200612091252/plugins/check_ups.c > and fixes this problem by having check_ups do a little more work itself. > > FWIW, > Ric > -- > --- check_ups.c.orig 2006-10-19 16:53:28.000000000 -0700 > +++ check_ups.c 2006-12-09 08:26:03.000000000 -0700 > @@ -98,6 +98,8 @@ > int get_ups_variable (const char *, char *, size_t); > > int process_arguments (int, char **); > +int talk2nut( const char *, int , const char *, char *, int); > + > int validate_arguments (void); > void print_help (void); > void print_usage (void); > @@ -405,7 +407,7 @@ > sprintf (send_buffer, "GET VAR %s %s\n", ups_name, varname); > > /* send the command to the daemon and get a response back */ > - if (process_tcp_request > + if (talk2nut > (server_address, server_port, send_buffer, temp_buffer, > sizeof (temp_buffer)) != STATE_OK) { > printf ("%s\n", _("Invalid response received from host")); > @@ -653,3 +655,24 @@ > printf (_("Usage:")); > printf ("%s -H host -u ups [-p port] [-v variable] [-w warn_value] [-c crit_value] [-to to_sec] [-T]\n", progname); > } > + > +int > +talk2nut(const char *server_address, int server_port, > + const char *send_buffer, char *recv_buffer, int recv_size) > +{ char buf[32]; > + int result; > + int sd; > + > + result = np_net_connect(server_address, server_port, &sd, > + IPPROTO_TCP); > + if(result != STATE_OK) > + return STATE_CRITICAL; > + result = send_request(sd, IPPROTO_TCP, send_buffer, recv_buffer, > + recv_size); > + if(result == STATE_OK) { > + strcpy(buf,"LOGOUT\n"); > + (void) send(sd, buf, strlen(buf), 0); > + } > + close(sd); > + return(result); > +} > -- > Ric Anderson, Opus One Systems, 1404 E Lind Road, Tucson, AZ 85719 > Phone: +1 520 324 0494 (v) +1 520 324 0495 FAX > ric at Opus1.COM (RA90-ARIN) Personal Email: ric at DragonElf.NET > UNIX *is* user friendly. It's just selective about who its friends are. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From matthias.flittner at nethinks.com Tue Dec 12 08:58:13 2006 From: matthias.flittner at nethinks.com (matthias.flittner at nethinks.com) Date: Tue, 12 Dec 2006 08:58:13 +0100 Subject: [Nagiosplug-devel] No performance data check_procs.c Message-ID: With this patch you get performance data. Could this patch please put into the next nagios-plugins version? Here is my patch: Index: check_procs.c =================================================================== --- check_procs.c (revision 1) +++ check_procs.c (working copy) @@ -303,7 +303,8 @@ printf (_("%d crit, %d warn out of "), crit, warn); } } - printf (ngettext ("%d process", "%d processes", (unsigned long) procs), procs); + + printf (ngettext ("%d process|processes=%d;;;0", "%d processes|processes=%d;;;0", (unsigned long) procs), procs, procs, procs); if (strcmp(fmt,"") != 0) { printf (_(" with %s"), fmt); @@ -437,8 +438,8 @@ break; else prog = optarg; - asprintf (&fmt, _("%s%scommand name '%s'"), (fmt ? fmt : ""), (options ? ", " : ""), - prog); + asprintf (&fmt, _("%s%s"), (fmt ? fmt : ""), (options ? ", " : ""), + prog); options |= PROG; break; case 'a': /* args (full path name with args) */ @@ -447,7 +448,6 @@ break; else args = optarg; - asprintf (&fmt, "%s%sargs '%s'", (fmt ? fmt : ""), (options ? ", " : ""), args); options |= ARGS; break; case 'r': /* RSS */ Greets FliTTi -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.flittner at nethinks.com Tue Dec 12 09:43:07 2006 From: matthias.flittner at nethinks.com (matthias.flittner at nethinks.com) Date: Tue, 12 Dec 2006 09:43:07 +0100 Subject: [Nagiosplug-devel] Wrong perfdata check_swap.c Message-ID: These plugin puts wrong perfdata. I have patched it: The maths auf warning and critical are wrong. Index: plugins/check_swap.c =================================================================== --- plugins/check_swap.c (revision 2) +++ plugins/check_swap.c (working copy) @@ -334,10 +334,10 @@ state_text (result), (100 - percent_used), (int) free_swap_mb, (int) total_swap_mb, status); - puts (perfdata ("swap", (long) free_swap_mb, "MB", - TRUE, (long) max (warn_size_bytes/(1024 * 1024), warn_percent/100.0*total_swap_mb), - TRUE, (long) max (crit_size_bytes/(1024 * 1024), crit_percent/100.0*total_swap_mb), - TRUE, 0, + puts (perfdata ("swap", (long) total_swap_mb-free_swap_mb, "MB", + TRUE, total_swap_mb-((long) max (warn_size_bytes/(1024 * 1024),(warn_percent/100.0*total_swap_mb))), + TRUE, total_swap_mb-((long) max (crit_size_bytes/(1024 * 1024),(crit_percent/100.0*total_swap_mb))), + TRUE, 0, TRUE, (long) total_swap_mb)); return result; Now the perfdata is clean. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ton.voon at altinity.com Tue Dec 12 09:56:39 2006 From: ton.voon at altinity.com (Ton Voon) Date: Tue, 12 Dec 2006 08:56:39 +0000 Subject: [Nagiosplug-devel] bug in is_hostname() In-Reply-To: <20060602003232.GA11230@math.ohio-state.edu> References: <20060602003232.GA11230@math.ohio-state.edu> Message-ID: <63282A50-326A-4B7E-AA42-978AB354DB6E@altinity.com> On 2 Jun 2006, at 01:32, Dave Alden wrote: > The is_hostname() function makes the assumption that no part of > the fqdn > could be only one letter. This is incorrect > ( a.somecompany.com ). I'm > not that great at perl regexp's, so I'll leave the patch to someone > else. > :-) Dave, Thanks for the report. Fixed in CVS now. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.flittner at nethinks.com Tue Dec 12 10:05:01 2006 From: matthias.flittner at nethinks.com (matthias.flittner at nethinks.com) Date: Tue, 12 Dec 2006 10:05:01 +0100 Subject: [Nagiosplug-devel] no perfdata - check_apt.c Message-ID: The Plugin check-apt.c puts no perfdata. So I have patched it: Index: check_apt.c =================================================================== --- check_apt.c (revision 2) +++ check_apt.c (working copy) @@ -115,7 +115,7 @@ result = max_state(result, STATE_OK); } - printf(_("APT %s: %d packages available for %s (%d critical updates). %s%s%s%s\n"), + printf(_("APT %s: %d packages available for %s (%d critical updates). %s%s%s%s|available_upgrades=%d;;;0 critical_updates=%d;;;0\n"), state_text(result), packages_available, (upgrade==DIST_UPGRADE)?"dist-upgrade":"upgrade", @@ -123,7 +123,9 @@ (stderr_warning)?" warnings detected":"", (stderr_warning && exec_warning)?",":"", (exec_warning)?" errors detected":"", - (stderr_warning||exec_warning)?". run with -v for information.":"" + (stderr_warning||exec_warning)?". run with -v for information.":"", + packages_available, + sec_count ); return result; Could you put this patch into the next release of the nagios plugins? :-) Greets FliTTi -------------- next part -------------- An HTML attachment was scrubbed... URL: From injinerisanthosh at gmail.com Tue Dec 12 13:25:40 2006 From: injinerisanthosh at gmail.com (Santhosh Injineri) Date: Tue, 12 Dec 2006 17:55:40 +0530 Subject: [Nagiosplug-devel] check_disk_smb Message-ID: Hi All, I am having some problem in testing check_disk_smb binary .... I have built the binary on HP-UX Platform and I am sending the output and command i have run ... Command is : ./check_disk_smb -H 127.0.0.1 -s tmp -w 85% -c 95% Output is: Can't exec "//127.0.0.1/tmp": No such file or directory at ./check_disk_smb line 166. Use of uninitialized value in split at ./check_disk_smb line 172. Use of uninitialized value in pattern match (m//) at ./check_disk_smb line 180. Result from smbclient not suitable Please help me in this Regard Thanks in Advance Regards Santhosh -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.flittner at nethinks.com Tue Dec 12 14:08:41 2006 From: matthias.flittner at nethinks.com (matthias.flittner at nethinks.com) Date: Tue, 12 Dec 2006 14:08:41 +0100 Subject: [Nagiosplug-devel] Need help on check_apt binary In-Reply-To: Message-ID: Dear Santhosh, Have you run ./configure and make before you run the binary? Please run the binary with the option -v like this: ./check_apt -v and sent me the output. I hope I can help you. Best regards Matthias "Santhosh Injineri" 12.12.2006 13:44 To matthias.flittner at nethinks.com cc Subject Need help on check_apt binary Hi Matthias, I need some clarification on check_apt binary .... I am porting nagios-plugins on HP-UX and when i run check_apt binary by executing command ./check_apt i am getting output as ' -o 'Debug::NoLocking=true' -s -qq upgrade' exited with non-zero status. APT OK: 0 packages available for upgrade (0 critical updates). errors detected. run with -v for information. I am very new to Nagios .... Please help me in this Regard Any problem in binary or the way i am running the command Please help me in this Regard Thanks in Advance --Santhosh -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Tue Dec 12 18:38:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Dec 2006 09:38:17 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1614164 ] 1.4.4/5 - regex_internal.h:458:20: alloca.h: No such file or Message-ID: Bugs item #1614164, was opened at 2006-12-12 12:38 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=1614164&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: Open Resolution: None Priority: 5 Private: No Submitted By: alexus (a1exus) Assigned to: Nobody/Anonymous (nobody) Summary: 1.4.4/5 - regex_internal.h:458:20: alloca.h: No such file or Initial Comment: if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I../intl -I../plugins -I/usr/local/ssl/include -g -O2 -MT regex.o -MD -MP -MF ".deps/regex.Tpo" -c -o regex.o regex.c; \ then mv -f ".deps/regex.Tpo" ".deps/regex.Po"; else rm -f ".deps/regex.Tpo"; exit 1; fi In file included from regex.c:55: regex_internal.h:458:20: alloca.h: No such file or directory gmake[4]: *** [regex.o] Error 1 gmake[4]: Leaving directory `/usr/local/src/nagios-plugins-1.4.5/lib' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/local/src/nagios-plugins-1.4.5/lib' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/local/src/nagios-plugins-1.4.5/lib' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/local/src/nagios-plugins-1.4.5' gmake: *** [all] Error 2 d# find . -name regex.c ./lib/regex.c d# find . -name alloca.h d# ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1614164&group_id=29880 From noreply at sourceforge.net Tue Dec 12 18:40:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Dec 2006 09:40:26 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1614168 ] 1.4.5 - not compatible w/ OpenSSL 0.9.8d Message-ID: Bugs item #1614168, was opened at 2006-12-12 12:40 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=1614168&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: Open Resolution: None Priority: 5 Private: No Submitted By: alexus (a1exus) Assigned to: Nobody/Anonymous (nobody) Summary: 1.4.5 - not compatible w/ OpenSSL 0.9.8d Initial Comment: gmake[2]: Entering directory `/home/install/nagios/nagios-plugins-1.4.5/plugins' /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -L. -L/usr/local/ssl/lib -o check_http check_http.o sslutils.o netutils.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -lnsl -lresolv -lssl -lcrypto gcc -g -O2 -o check_http check_http.o sslutils.o netutils.o utils.o -L/home/install/nagios/nagios-plugins-1.4.5/plugins -L/usr/local/ssl/lib ../lib/libnagiosplug.a ../lib/libcoreutils.a -lnsl -lresolv -lssl -lcrypto /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x38): In function `dlfcn_load': : undefined reference to `dlopen' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0xa0): In function `dlfcn_load': : undefined reference to `dlclose' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0xc9): In function `dlfcn_load': : undefined reference to `dlerror' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x13e): In function `dlfcn_unload': : undefined reference to `dlclose' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x1f5): In function `dlfcn_bind_var': : undefined reference to `dlsym' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x241): In function `dlfcn_bind_var': : undefined reference to `dlerror' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x2d5): In function `dlfcn_bind_func': : undefined reference to `dlsym' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x321): In function `dlfcn_bind_func': : undefined reference to `dlerror' collect2: ld returned 1 exit status gmake[2]: *** [check_http] Error 1 gmake[2]: Leaving directory `/home/install/nagios/nagios-plugins-1.4.5/plugins' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/install/nagios/nagios-plugins-1.4.5' gmake: *** [all] Error 2 [root at localhost nagios-plugins-1.4.5]# ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1614168&group_id=29880 From seanius at seanius.net Tue Dec 12 23:17:53 2006 From: seanius at seanius.net (sean finney) Date: Tue, 12 Dec 2006 23:17:53 +0100 Subject: [Nagiosplug-devel] Need help on check_apt binary In-Reply-To: References: Message-ID: <1165961873.26325.2.camel@localhost> On Tue, 2006-12-12 at 14:08 +0100, matthias.flittner at nethinks.com wrote: > > Dear Santhosh, > > Have you run ./configure and make before you run the binary? Please > run the binary with the option -v like this: > > ./check_apt -v i believe his problem is he's trying to use a plugin that runs apt-get (a debian program) on hp-ux, which has no such program. so when ./configure runs, it doesn't detect apt-get, but for some reason the plugin got built anyway, and he's now trying to run it and PATH_TO_APT_GET (or whatever the #define is) is probably equal to the empty string, hence his rather strange error. this might also be the cause of the wierdness with teh check_smb plugin output mentioned earlier. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From noreply at sourceforge.net Wed Dec 13 08:14:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Dec 2006 23:14:49 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1614552 ] no perf-data check_procs Message-ID: Bugs item #1614552, was opened at 2006-12-13 07: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=1614552&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: FliTTi (flitti) Assigned to: Nobody/Anonymous (nobody) Summary: no perf-data check_procs Initial Comment: The plugincheck_procs doens't return perfdata. This patch will enable perf data. Please put it into the next release. Best regards, FliTTi ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1614552&group_id=29880 From noreply at sourceforge.net Wed Dec 13 08:16:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Dec 2006 23:16:30 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1614553 ] no perf-data check_apt Message-ID: Bugs item #1614553, was opened at 2006-12-13 07: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=1614553&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: FliTTi (flitti) Assigned to: Nobody/Anonymous (nobody) Summary: no perf-data check_apt Initial Comment: The plugin check_apt doens't return perfdata. This patch will enable perf data. Please put it into the next release. Best regards, FliTTi ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1614553&group_id=29880 From noreply at sourceforge.net Wed Dec 13 08:17:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Dec 2006 23:17:10 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1614554 ] no perf-data check_swap Message-ID: Bugs item #1614554, was opened at 2006-12-13 07:17 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=1614554&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: FliTTi (flitti) Assigned to: Nobody/Anonymous (nobody) Summary: no perf-data check_swap Initial Comment: The plugin check_swap doens't return perfdata. This patch will enable perf data. Please put it into the next release. Best regards, FliTTi ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1614554&group_id=29880 From bseklecki at collaborativefusion.com Sat Dec 16 01:15:15 2006 From: bseklecki at collaborativefusion.com (Brian A. Seklecki) Date: Fri, 15 Dec 2006 19:15:15 -0500 Subject: [Nagiosplug-devel] nagios check_carp for OpenBSD carp(4) Message-ID: <1166228115.50417.506.camel@soundwave.pgh.priv.collaborativefusion.com> Thoughts? Strategies? Ideas? --- Ask the machine directly? Ask an adjacent machine? Adjacent machine strat: If the monitoring machine is directly connected to the same ethernet segment, one could use pcap(3) to examine multicast packets. There are no utils I know of that do this, so a few lines of C probably. If the monitoring machine is more than one layer-3 device away or in a separate broadcast domain, an agent would have to be installed directly on the device or a device on the same segment. Machine directly: Agent Options: - Net-SNMP via PF-MIB (possibly via AgentX) - use check_snmp - Net-SNMP via pass through MIB and script - use check_snmp (maybe return an Integer as a boolean w/: -c "0:0" -w "0:0") - NRPE2 w/ SSL and - use check_nrpe (NRPE2 isn't in OpenBSD Ports) - SSH (via check_ssh and passphrase-less RSA/DSA Keys) Options for On-system: - Shell/Perl script to parse ifconfig(8) - C utility to ask /dev/pf pf(4) - Examine klog(9) for net.inet.carp.log= ---- Other thoughts: Preempt: Unlike "HSRP Groups" where interfaces can preempt can apply to select group of interfaces, it is safe to assume that if preempt is enabled and one interface in a SLAVE state; all other are in that state. Perhaps 4.0 features such as interface groups and multi-routing tables will change that. Other ideas? -- Brian A. Seklecki Collaborative Fusion, Inc. From noreply at sourceforge.net Mon Dec 18 17:06:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Dec 2006 08:06:48 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1618174 ] check_by_ssh adding -q option, to suppress MOTD Message-ID: Patches item #1618174, was opened at 2006-12-18 11:06 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=1618174&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: DVG (davevg) Assigned to: Nobody/Anonymous (nobody) Summary: check_by_ssh adding -q option, to suppress MOTD Initial Comment: This patch adds the -q option for the ssh command to suppress the Message of the Day output on some hosts. The current skip lines flag does not skip this output which causes host checks on remote hosts to fail if they have a MOTD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1618174&group_id=29880 From gavin at openfusion.com.au Tue Dec 19 04:12:24 2006 From: gavin at openfusion.com.au (Gavin Carr) Date: Tue, 19 Dec 2006 14:12:24 +1100 Subject: [Nagiosplug-devel] Nagios::Plugin 0.15 released Message-ID: <20061219031224.GA14166@openfusion.com.au> Nagios::Plugin version 0.15 has just been released to CPAN (see http://search.cpan.org/dist/Nagios-Plugin/). Nagios::Plugin is a collection of perl modules to simplify writing nagios plugins, and is the successor to the nagios plugins utils.pm. This version primarily features interface cleanups, with the N::P::Threshold and N::P::Getopt modules now available through the main Nagios::Plugin object, with most of the work done by Nathan Vonnahme - thanks Nathan! Cheers, Gavin -- Gavin Carr Open Fusion - Open Source Business Solutions [ Linux - Perl - Apache ] http://www.openfusion.com.au - Fashion is a variable, but style is a constant - Programming Perl From andy.wolstenholme at opesprime.com Tue Dec 19 06:36:21 2006 From: andy.wolstenholme at opesprime.com (Andy Wolstenholme) Date: Tue, 19 Dec 2006 06:36:21 +0100 (CET) Subject: [Nagiosplug-devel] =?iso-8859-1?q?SNMP_and_hardware_?= Message-ID: <20061219053621.036EC4F4046@desire.netways.de> Hi, I am trying to collect information from our various servers regarding hardware, specifially disk status, cluster status etc. Is anyone able to advise the best approach to do this. Is this possible via SNMP, if so where can i locate the specific libraries where i can reach down to specific hardware components. the servers in question are running Dell openmanage so i guess, we could use snmp against this. Any suggestions are greatly apprecaited andy ...[write your message here]... - Andy Wolstenholme (andywooly) ----------------------- The mailing list archive is found here: http://www.nagiosexchange.org/nagiosplug-devel.31.0.html From chris.snell at gmail.com Tue Dec 19 06:38:32 2006 From: chris.snell at gmail.com (Christopher Snell) Date: Mon, 18 Dec 2006 22:38:32 -0700 Subject: [Nagiosplug-devel] nagios check_carp for OpenBSD carp(4) In-Reply-To: <1166228115.50417.506.camel@soundwave.pgh.priv.collaborativefusion.com> References: <1166228115.50417.506.camel@soundwave.pgh.priv.collaborativefusion.com> Message-ID: <4052b0840612182138x41a1d05bm9ddeeaecad4ee6a4@mail.gmail.com> On 12/15/06, Brian A. Seklecki wrote: > Thoughts? Strategies? Ideas? > --- > > Ask the machine directly? Ask an adjacent machine? Joel Knight just released an updated OpenBSD SNMP MIB that supports reading data from the sensors framework. Perhaps he could be persuaded to add support for CARP state detection? :) Chris From ae at op5.se Tue Dec 19 10:39:50 2006 From: ae at op5.se (Andreas Ericsson) Date: Tue, 19 Dec 2006 10:39:50 +0100 Subject: [Nagiosplug-devel] SNMP and hardware In-Reply-To: <20061219053621.036EC4F4046@desire.netways.de> References: <20061219053621.036EC4F4046@desire.netways.de> Message-ID: <4587B366.7060800@op5.se> Andy Wolstenholme wrote: > Hi, > > I am trying to collect information from our various servers regarding hardware, specifially disk status, cluster status etc. > > Is anyone able to advise the best approach to do this. Is this possible via SNMP, if so where can i locate the specific libraries where i can reach down to specific hardware components. > > the servers in question are running Dell openmanage so i guess, we could use snmp against this. > I think you just answered your own question. I believe there are plugins that query Dell openmanage on www.nagiosexchange.org. It shouldn't be hard writing some up otherwise. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From matthias.flittner at nethinks.com Tue Dec 19 12:58:54 2006 From: matthias.flittner at nethinks.com (matthias.flittner at nethinks.com) Date: Tue, 19 Dec 2006 12:58:54 +0100 Subject: [Nagiosplug-devel] a exim question Message-ID: my question is: Is there now a plugin which can track the exim4 queue time shown in mainlog? Or must i create one? :-) Best regards, FliTTi -------------- next part -------------- An HTML attachment was scrubbed... URL: From william at elan.net Tue Dec 19 16:31:36 2006 From: william at elan.net (william(at)elan.net) Date: Tue, 19 Dec 2006 07:31:36 -0800 (PST) Subject: [Nagiosplug-devel] =?iso-8859-1?q?SNMP_and_hardware?= In-Reply-To: <20061219053621.036EC4F4046@desire.netways.de> References: <20061219053621.036EC4F4046@desire.netways.de> Message-ID: On Tue, 19 Dec 2006, Andy Wolstenholme wrote: > Hi, > > I am trying to collect information from our various servers regarding > hardware, specifially disk status, cluster status etc. > Is anyone able to advise the best approach to do this. Is this > possible via SNMP, if so where can i locate the specific libraries where > i can reach down to specific hardware components. > the servers in question are running Dell openmanage so i guess, we could > use snmp against this. http://www.elan.net/~william/nagios/plugins/check_snmp_dell_powersupply.pl (Dell specific plugin to check power supplies) http://www.elan.net/~william/nagios/plugins/check_snmp_temperature.pl (this supports Dell and Cisco a pre-set types, but can also be used for other types of hardware reporting SNMP temperature data) http://www.elan.net/~william/nagios/plugins/check_snmp_table.pl (this is incudes examples for Dell fans & voltage; it is general plugin though to be used for various SNMP data where the names of sensors are reported in one table and data in related table with .x endings matching names table) If you're using Megaraid then there is great SNMP plugin for megaraid at: http://www.ibiblio.org/john/megaraid/ Good luck :) -- William Leibzon Elan Networks william at elan.net From skreuzer at f2o.org Tue Dec 19 21:23:07 2006 From: skreuzer at f2o.org (Steven Kreuzer) Date: Tue, 19 Dec 2006 15:23:07 -0500 Subject: [Nagiosplug-devel] Nagios::Plugin 0.15 released In-Reply-To: <20061219031224.GA14166@openfusion.com.au> References: <20061219031224.GA14166@openfusion.com.au> Message-ID: Hi All I updated the FreeBSD port of Nagios::Plugin from 0.14 to 0.15 and I submitted a PR for it to be committed to cvs. I attached a diff to bring the port up to the latest on your machine: To patch: cd /usr/ports/net-mgmt/p5-Nagios-Plugin patch -p1 < /path/to/p5-Nagios-Plugin.diif Of course, any and all feedback is very appreciated. Thanks, Steven -------------- next part -------------- A non-text attachment was scrubbed... Name: p5-Nagios-Plugin.diff Type: application/octet-stream Size: 1632 bytes Desc: not available URL: -------------- next part -------------- On Dec 18, 2006, at 10:12 PM, Gavin Carr wrote: > Nagios::Plugin version 0.15 has just been released to CPAN (see > http://search.cpan.org/dist/Nagios-Plugin/). Nagios::Plugin is a > collection of perl modules to simplify writing nagios plugins, > and is the successor to the nagios plugins utils.pm. > > This version primarily features interface cleanups, with the > N::P::Threshold and N::P::Getopt modules now available through > the main Nagios::Plugin object, with most of the work done by > Nathan Vonnahme - thanks Nathan! > > Cheers, > Gavin > > -- > Gavin Carr > Open Fusion - Open Source Business Solutions [ Linux - Perl - Apache ] > http://www.openfusion.com.au > - Fashion is a variable, but style is a constant - Programming Perl > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________________ > 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 lavalamp at spiritual-machines.org Tue Dec 19 20:21:19 2006 From: lavalamp at spiritual-machines.org (Brian A. Seklecki) Date: Tue, 19 Dec 2006 14:21:19 -0500 (EST) Subject: [Nagiosplug-devel] nagios check_carp for OpenBSD carp(4) In-Reply-To: <4052b0840612182138x41a1d05bm9ddeeaecad4ee6a4@mail.gmail.com> References: <1166228115.50417.506.camel@soundwave.pgh.priv.collaborativefusion.com> <4052b0840612182138x41a1d05bm9ddeeaecad4ee6a4@mail.gmail.com> Message-ID: <20061219141528.I95919@arbitor.digitalfreaks.org> Chris: Right, when I have a second here, I was going to ry to merge the PF-MIB patch into opti@'s new version of Net-SNMP 5.4 (the PF-MIB I have right now is for the old-school ucd-snmp !) http://www.packetmischief.ca/openbsd/snmp/ ~BAS On Mon, 18 Dec 2006, Christopher Snell wrote: > On 12/15/06, Brian A. Seklecki wrote: >> Thoughts? Strategies? Ideas? >> --- >> >> Ask the machine directly? Ask an adjacent machine? > > Joel Knight just released an updated OpenBSD SNMP MIB that supports > reading data from the sensors framework. Perhaps he could be > persuaded to add support for CARP state detection? :) > > Chris > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________________ > 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 > l8* -lava (Brian A. Seklecki - Pittsburgh, PA, USA) http://www.spiritual-machines.org/ "...from back in the heady days when "helpdesk" meant nothing, "diskquota" meant everything, and lives could be bought and sold for a couple of pages of laser printout - and frequently were." From lavalamp at spiritual-machines.org Tue Dec 19 20:21:19 2006 From: lavalamp at spiritual-machines.org (Brian A. Seklecki) Date: Tue, 19 Dec 2006 14:21:19 -0500 (EST) Subject: [Nagiosplug-devel] nagios check_carp for OpenBSD carp(4) In-Reply-To: <4052b0840612182138x41a1d05bm9ddeeaecad4ee6a4@mail.gmail.com> References: <1166228115.50417.506.camel@soundwave.pgh.priv.collaborativefusion.com> <4052b0840612182138x41a1d05bm9ddeeaecad4ee6a4@mail.gmail.com> Message-ID: <20061219141528.I95919@arbitor.digitalfreaks.org> Chris: Right, when I have a second here, I was going to ry to merge the PF-MIB patch into opti@'s new version of Net-SNMP 5.4 (the PF-MIB I have right now is for the old-school ucd-snmp !) http://www.packetmischief.ca/openbsd/snmp/ ~BAS On Mon, 18 Dec 2006, Christopher Snell wrote: > On 12/15/06, Brian A. Seklecki wrote: >> Thoughts? Strategies? Ideas? >> --- >> >> Ask the machine directly? Ask an adjacent machine? > > Joel Knight just released an updated OpenBSD SNMP MIB that supports > reading data from the sensors framework. Perhaps he could be > persuaded to add support for CARP state detection? :) > > Chris > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________________ > 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 > l8* -lava (Brian A. Seklecki - Pittsburgh, PA, USA) http://www.spiritual-machines.org/ "...from back in the heady days when "helpdesk" meant nothing, "diskquota" meant everything, and lives could be bought and sold for a couple of pages of laser printout - and frequently were." ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Net-snmp-users mailing list Net-snmp-users at lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users From noreply at sourceforge.net Tue Dec 19 22:57:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Dec 2006 13:57:28 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1619078 ] fix typo in contrib/check_snmp_disk_monitor.pl Message-ID: Patches item #1619078, was opened at 2006-12-19 13: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=1619078&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: Allen Smith (lazlor) Assigned to: Nobody/Anonymous (nobody) Summary: fix typo in contrib/check_snmp_disk_monitor.pl Initial Comment: The warn/crit checks were wrong. It would never alarm. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1619078&group_id=29880 From enabled at myrealbox.com Tue Dec 19 23:09:38 2006 From: enabled at myrealbox.com (Joel Knight) Date: Tue, 19 Dec 2006 15:09:38 -0700 Subject: [Nagiosplug-devel] nagios check_carp for OpenBSD carp(4) In-Reply-To: <20061219141528.I95919@arbitor.digitalfreaks.org> References: <1166228115.50417.506.camel@soundwave.pgh.priv.collaborativefusion.com> <4052b0840612182138x41a1d05bm9ddeeaecad4ee6a4@mail.gmail.com> <20061219141528.I95919@arbitor.digitalfreaks.org> Message-ID: <45886322.4040809@myrealbox.com> Brian A. Seklecki wrote: > Chris: > > Right, when I have a second here, I was going to ry to merge the PF-MIB > patch into opti@'s new version of Net-SNMP 5.4 (the PF-MIB I have right > now is for the old-school ucd-snmp !) > > http://www.packetmischief.ca/openbsd/snmp/ The MIBs currently work with Net-SNMP 5.1 which is what's in the OpenBSD ports tree. The patch to ucd-snmp was obsolete some time ago. .joel ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Net-snmp-users mailing list Net-snmp-users at lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users From enabled at myrealbox.com Tue Dec 19 23:09:38 2006 From: enabled at myrealbox.com (Joel Knight) Date: Tue, 19 Dec 2006 15:09:38 -0700 Subject: [Nagiosplug-devel] nagios check_carp for OpenBSD carp(4) In-Reply-To: <20061219141528.I95919@arbitor.digitalfreaks.org> References: <1166228115.50417.506.camel@soundwave.pgh.priv.collaborativefusion.com> <4052b0840612182138x41a1d05bm9ddeeaecad4ee6a4@mail.gmail.com> <20061219141528.I95919@arbitor.digitalfreaks.org> Message-ID: <45886322.4040809@myrealbox.com> Brian A. Seklecki wrote: > Chris: > > Right, when I have a second here, I was going to ry to merge the PF-MIB > patch into opti@'s new version of Net-SNMP 5.4 (the PF-MIB I have right > now is for the old-school ucd-snmp !) > > http://www.packetmischief.ca/openbsd/snmp/ The MIBs currently work with Net-SNMP 5.1 which is what's in the OpenBSD ports tree. The patch to ucd-snmp was obsolete some time ago. .joel From siutkowskij at gmail.com Wed Dec 20 13:20:26 2006 From: siutkowskij at gmail.com (Jacek Siutkowski) Date: Wed, 20 Dec 2006 13:20:26 +0100 Subject: [Nagiosplug-devel] check_ntpd Message-ID: <1166617226.11753.49.camel@passat.prokom.pl> Hello! I'm using nagios-plugins-1.4-2.0.rh7.rf on old (but updated) rh7.3 through local nrpe. On Nagios console I discovered frequent alarms concerning this NTP, which actually is constantly flapping. Locally issued /path/check_ntp -H 127.0.0.1 had acknowledged that, but ntpd was still running and in sync with parent one. After issuing command: "/path/check_ntp -H 127.0.0.1 -v" it turned out that check_ntp was returning critical state when "offset 0.000000" and OK state every one offset is different from 0.000000. I suppose some divide by zero problem or similar .... On rh7.3 is installed ntp-4.1.1-1 and kernel 2.4.30. Jacek From dermoth at aei.ca Wed Dec 20 14:50:42 2006 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Wed, 20 Dec 2006 08:50:42 -0500 Subject: [Nagiosplug-devel] check_ntpd In-Reply-To: <1166617226.11753.49.camel@passat.prokom.pl> References: <1166617226.11753.49.camel@passat.prokom.pl> Message-ID: <45893FB2.90902@aei.ca> Jacek Siutkowski wrote: > Hello! > > I'm using nagios-plugins-1.4-2.0.rh7.rf on old (but updated) rh7.3 > through local nrpe. On Nagios console I discovered frequent alarms > concerning this NTP, which actually is constantly flapping. > Locally issued /path/check_ntp -H 127.0.0.1 had acknowledged that, but > ntpd was still running and in sync with parent one. > After issuing command: "/path/check_ntp -H 127.0.0.1 -v" it turned out > that check_ntp was returning critical state when "offset 0.000000" and > OK state every one offset is different from 0.000000. > I suppose some divide by zero problem or similar .... > > On rh7.3 is installed ntp-4.1.1-1 and kernel 2.4.30. > Older versions of check_ntp (perl script) has many known issues and was replaced by a C version in nagios-plugins-1.4.5. Please upgrade. I made a patch for the specific situation you're talking above. You can try it but keep in mind it doesn't fix all issues. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: nagios-plugins-1.4.check_ntp.patch Type: text/x-patch Size: 1071 bytes Desc: not available URL: From mha at cm4all.com Wed Dec 20 16:17:00 2006 From: mha at cm4all.com (Matthias Haider) Date: Wed, 20 Dec 2006 16:17:00 +0100 Subject: [Nagiosplug-devel] check_disk inode bug ? Message-ID: <3D307C02-4478-4557-BD47-5A6047B7CD11@cm4all.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hello , i am trying to check the inode usage of a partition (/dev/sda2 on / type ext3 (rw,errors=remount-ro)) , where df -ih says there are 31% of inodes used, but check_disk exits with CRITICAL when setting --icritical to 5%: ~# /usr/lib/nagios/plugins/check_disk -vvv --icritical 5% / For /, used_pct=38 free_pct=62 used_units=3344 free_units=5567 total_units=9388 used_inodes_pct=31 Freespace_units result=0 Freespace% result=0 Usedspace_units result=0 Usedspace_percent result=0 Usedinodes_percent result=2 DISK CRITICAL - free space: / 5567 MB (62% inode=69%);| / =3344MB;-2147483648;-2147483648;0;9388 why is Usedinodes_percent result=2 when used_inodes_pct=31 and the critical threshosd is 5% ??? is this a bug? thanks, Matthias -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFiVPszSQdV7jRRyURAhMTAKDlANL7UURodYB7kaNOmihHJlaZ6wCfa8nh aqimoNumJKt4ohvhfBwOiZg= =NRmE -----END PGP SIGNATURE----- From nagios at nagios.org Thu Dec 21 19:52:00 2006 From: nagios at nagios.org (Ethan Galstad) Date: Thu, 21 Dec 2006 12:52:00 -0600 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins Message-ID: <458AD7D0.1090902@nagios.org> Hi Everyone - One of the things that Nagios 3 will support is the ability to use the embedded Perl interpreter for specific perl plugins only, instead of all or nothing. The Nagios 3 development code currently support the following... Line 2 of a Perl plugin may start with one of the following: #USE_EPN -or- #NO_EPN If the #USE_EPN statement is found, Nagios will use the embedded Perl interpreter to run the plugin. If #NO_EPN is found, it will not be used (even if epn is compiled in and enabled in the Nagios daemon). If neither directive is found, Nagios will default to the behavior specified by a new 'use_embedded_perl_implicitly' variable in the main Nagios config file. Plugin devs - would you prefer different statements other than #USE_EPN / #NO_EPN, or are they okay? Any other comments or suggestions? Ethan Galstad, Nagios Developer --- Email: nagios at nagios.org Website: http://www.nagios.org From klausman at schwarzvogel.de Thu Dec 21 20:10:58 2006 From: klausman at schwarzvogel.de (Tobias Klausmann) Date: Thu, 21 Dec 2006 20:10:58 +0100 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <458AD7D0.1090902@nagios.org> References: <458AD7D0.1090902@nagios.org> Message-ID: <20061221191058.GA12311@eric.schwarzvogel.de> Hi! On Thu, 21 Dec 2006, Ethan Galstad wrote: > Line 2 of a Perl plugin may start with one of the following: > > #USE_EPN > > -or- > > #NO_EPN > > Plugin devs - would you prefer different statements other than #USE_EPN > / #NO_EPN, or are they okay? Any other comments or suggestions? I'd go for a more namespace-like approach: # Nagios: use_epn vs. # Nagios: no_epn also, it'd be nicer maybe to use more similar positive/negative flags, for example +epn/-epn. So, in all: # Nagios: +epn vs. # Nagios: -epn In the future, one could add more execution hints like this: # Nagios: -epn,+foo,-multithreaded,+volatile Just my loose change ;) Regards, Tobias -- Never touch a burning system. From gavin at openfusion.com.au Thu Dec 21 23:39:01 2006 From: gavin at openfusion.com.au (Gavin Carr) Date: Fri, 22 Dec 2006 09:39:01 +1100 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <20061221191058.GA12311@eric.schwarzvogel.de> References: <458AD7D0.1090902@nagios.org> <20061221191058.GA12311@eric.schwarzvogel.de> Message-ID: <20061221223901.GB22917@openfusion.com.au> On Thu, Dec 21, 2006 at 08:10:58PM +0100, Tobias Klausmann wrote: > On Thu, 21 Dec 2006, Ethan Galstad wrote: > > Line 2 of a Perl plugin may start with one of the following: > > > > #USE_EPN > > > > -or- > > > > #NO_EPN > > > > Plugin devs - would you prefer different statements other than #USE_EPN > > / #NO_EPN, or are they okay? Any other comments or suggestions? > > I'd go for a more namespace-like approach: > > # Nagios: use_epn > vs. > # Nagios: no_epn +1 on the Nagios: (or nagios:) label. > also, it'd be nicer maybe to use more similar positive/negative > flags, for example +epn/-epn. > > So, in all: > > # Nagios: +epn > vs. > # Nagios: -epn > > In the future, one could add more execution hints like this: > > # Nagios: -epn,+foo,-multithreaded,+volatile I don't much mind USE_EPN/NO_EPN (or use_epn/no_epn maybe) or +epn/-epn. I quite like the idea Tobias' general idea though - you end up with something like vim modelines: # vim:et:sw=2:ai:sm I'd quite like some flexibility about location too. Would it be much work to allow the tags to occur anywhere within the first or last 1024 bytes of the file, say? Cheers, Gavin From nagios at nagios.org Fri Dec 22 00:39:41 2006 From: nagios at nagios.org (Ethan Galstad) Date: Thu, 21 Dec 2006 17:39:41 -0600 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <20061221223901.GB22917@openfusion.com.au> References: <458AD7D0.1090902@nagios.org> <20061221191058.GA12311@eric.schwarzvogel.de> <20061221223901.GB22917@openfusion.com.au> Message-ID: <458B1B3D.4000103@nagios.org> Gavin Carr wrote: > On Thu, Dec 21, 2006 at 08:10:58PM +0100, Tobias Klausmann wrote: >> On Thu, 21 Dec 2006, Ethan Galstad wrote: >>> Line 2 of a Perl plugin may start with one of the following: >>> >>> #USE_EPN >>> >>> -or- >>> >>> #NO_EPN >>> >>> Plugin devs - would you prefer different statements other than #USE_EPN >>> / #NO_EPN, or are they okay? Any other comments or suggestions? >> I'd go for a more namespace-like approach: >> >> # Nagios: use_epn >> vs. >> # Nagios: no_epn > > +1 on the Nagios: (or nagios:) label. > >> also, it'd be nicer maybe to use more similar positive/negative >> flags, for example +epn/-epn. >> >> So, in all: >> >> # Nagios: +epn >> vs. >> # Nagios: -epn >> >> In the future, one could add more execution hints like this: >> >> # Nagios: -epn,+foo,-multithreaded,+volatile > > I don't much mind USE_EPN/NO_EPN (or use_epn/no_epn maybe) or +epn/-epn. > I quite like the idea Tobias' general idea though - you end up with > something like vim modelines: > > # vim:et:sw=2:ai:sm > > I'd quite like some flexibility about location too. Would it be much work > to allow the tags to occur anywhere within the first or last 1024 bytes > of the file, say? > > > Cheers, > Gavin > I like Tobias' suggestion as well. As far as flexible location, that could be arranged. Limiting its location the the beginning X lines of the plugin would be far easier that figuring out how many lines the plugin has and working backwards. In order to reduce overhead/increase speed of detection the keywords, I would suggest we limit the possible location to the first 100 lines or less. Ton, Benoit, others... does this sound okay? Ethan Galstad, Nagios Developer --- Email: nagios at nagios.org Website: http://www.nagios.org From benoit.mortier at opensides.be Fri Dec 22 00:46:14 2006 From: benoit.mortier at opensides.be (Benoit Mortier) Date: Fri, 22 Dec 2006 00:46:14 +0100 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <458B1B3D.4000103@nagios.org> References: <458AD7D0.1090902@nagios.org> <20061221223901.GB22917@openfusion.com.au> <458B1B3D.4000103@nagios.org> Message-ID: <200612220046.15084.benoit.mortier@opensides.be> Le Vendredi 22 D?cembre 2006 00:39, Ethan Galstad a ?crit?: [..] > >> So, in all: > >> > >> # Nagios: +epn > >> vs. > >> # Nagios: -epn > >> > >> In the future, one could add more execution hints like this: > >> > >> # Nagios: -epn,+foo,-multithreaded,+volatile > > > > I don't much mind USE_EPN/NO_EPN (or use_epn/no_epn maybe) or > > +epn/-epn. I quite like the idea Tobias' general idea though - you end > > up with something like vim modelines: > > > > # vim:et:sw=2:ai:sm > > > > I'd quite like some flexibility about location too. Would it be much > > work to allow the tags to occur anywhere within the first or last 1024 > > bytes of the file, say? > > > > > > Cheers, > > Gavin > > I like Tobias' suggestion as well. > > As far as flexible location, that could be arranged. Limiting its > location the the beginning X lines of the plugin would be far easier > that figuring out how many lines the plugin has and working backwards. > In order to reduce overhead/increase speed of detection the keywords, I > would suggest we limit the possible location to the first 100 lines or > less. > > Ton, Benoit, others... does this sound okay? Hello, For me i like the tobias idea also Cheers -- Benoit Mortier CEO www.opensides.be Contributor to Gosa Project : http://gosa.gonicus.de/ Contributeur to Nagios Plugins : http://nagiosplug.sourceforge.net/ From noreply at sourceforge.net Fri Dec 22 04:20:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Dec 2006 19:20:10 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1526072 ] CVS fails to compile on Solaris 9 Message-ID: <200612220320.kBM3KA6d007090@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1526072, was opened at 2006-07-20 11:48 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1526072&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: maemigh (maemigh) Assigned to: Ton Voon (tonvoon) Summary: CVS fails to compile on Solaris 9 Initial Comment: I retrieved the source from CVS and ran into the following error during compilation: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I../intl -I../plugins -I/include -g -O2 -c utils_base.c In file included from ../plugins/common.h:119, from utils_base.c:16: /usr/include/sys/swap.h:47: #error "Cannot use swapctl in the large files compilation environment" gmake[4]: *** [utils_base.o] Error 1 gmake[4]: Leaving directory `/tmp/nagiosplug/lib' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/tmp/nagiosplug/lib' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/tmp/nagiosplug/lib' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/tmp/nagiosplug' gmake: *** [all] Error 2 I took a quick look into it, but I wasn't able to come up with much. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2006-12-21 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: 2006-12-07 08:31 Message: Logged In: YES user_id=664364 Originator: NO maemigh, I think this is resolved now. Can you please try the next snapshot. I've marked the call into pending so it will auto close after 7 days if there is no update. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1526072&group_id=29880 From dermoth at aei.ca Fri Dec 22 06:28:13 2006 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Fri, 22 Dec 2006 00:28:13 -0500 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <200612220046.15084.benoit.mortier@opensides.be> References: <458AD7D0.1090902@nagios.org> <20061221223901.GB22917@openfusion.com.au> <458B1B3D.4000103@nagios.org> <200612220046.15084.benoit.mortier@opensides.be> Message-ID: <458B6CED.2070209@aei.ca> Benoit Mortier wrote: > Le Vendredi 22 D?cembre 2006 00:39, Ethan Galstad a ?crit : [..] >> I like Tobias' suggestion as well. >> >> As far as flexible location, that could be arranged. Limiting its >> location the the beginning X lines of the plugin would be far easier >> that figuring out how many lines the plugin has and working backwards. >> In order to reduce overhead/increase speed of detection the keywords, I >> would suggest we limit the possible location to the first 100 lines or >> less. >> >> Ton, Benoit, others... does this sound okay? > > Hello, > > For me i like the tobias idea also > > Cheers I like the Vim modeline style which is very similar to Tobias's idea. # nagios:epn # nagios:noepn # nagios:epn:foo=8:nobar Thomas From pitchfork at ederdrom.de Fri Dec 22 07:25:38 2006 From: pitchfork at ederdrom.de (Joerg Linge) Date: Fri, 22 Dec 2006 07:25:38 +0100 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <458B6CED.2070209@aei.ca> References: <458AD7D0.1090902@nagios.org> <200612220046.15084.benoit.mortier@opensides.be> <458B6CED.2070209@aei.ca> Message-ID: <200612220725.39222.pitchfork@ederdrom.de> Am Freitag, 22. Dezember 2006 06:28 schrieb Thomas Guyot-Sionnest: [...] > > Hello, > > > > For me i like the tobias idea also > > > > Cheers > > I like the Vim modeline style which is very similar to Tobias's idea. > > # nagios:epn > # nagios:noepn > > # nagios:epn:foo=8:nobar Yes, sounds good. J?rg From ton.voon at altinity.com Fri Dec 22 10:05:35 2006 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 22 Dec 2006 09:05:35 +0000 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <458B1B3D.4000103@nagios.org> References: <458AD7D0.1090902@nagios.org> <20061221191058.GA12311@eric.schwarzvogel.de> <20061221223901.GB22917@openfusion.com.au> <458B1B3D.4000103@nagios.org> Message-ID: <26CE556D-8C1C-4F0D-B3F5-BFD4DE387023@altinity.com> On 21 Dec 2006, at 23:39, Ethan Galstad wrote: > I like Tobias' suggestion as well. > > As far as flexible location, that could be arranged. Limiting its > location the the beginning X lines of the plugin would be far easier > that figuring out how many lines the plugin has and working backwards. > In order to reduce overhead/increase speed of detection the > keywords, I > would suggest we limit the possible location to the first 100 lines or > less. > > Ton, Benoit, others... does this sound okay? Sorry, I've stayed quiet on this because I don't use epn, so don't necessarily understand the issues. I know Gavin Carr uses epn, but I'm not sure who else currently on the plugin team. My British penny (just less than two cents) says: vim style comments; limit macro to first 10 lines. Maybe you could cache the plugin name (keyed on file location?) so that you don't need to keep re-reading the plugin? Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Sun Dec 24 06:40:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Dec 2006 21:40:14 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1603745 ] check_disk remains in "uninterruptible sleep" state Message-ID: Bugs item #1603745, was opened at 2006-11-27 09:34 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1603745&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: blablup (blablup) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk remains in "uninterruptible sleep" state Initial Comment: On 2 Servers the plugin stays in an "uninterruptible sleep" state an there is no way to kill it (except reboot the system).That only happens if i use the -x DEVICE function, if I use the -p Path function everything looks good. It doesn?t matter which device I specify, every time it hangs. ps -aux looks like this: nagios 12783 0.0 0.0 1388 548 ? Ds 12:15 0:00 /home/nagios/check_disk -w 10% -c 5% -x /dev/hda nagios 12905 0.0 0.0 1388 548 ? Ds 12:17 0:00 /home/nagios/check_disk -w 10% -c 5% -x /dev/hda nagios 12997 0.0 0.0 1384 544 ? Ds 12:18 0:00 /home/nagios/check_disk -w 10% -c 5% -x /dev/hda n Best regards BlaBlup ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2006-12-24 00:40 Message: Logged In: YES user_id=375623 Originator: NO Works for me. It looks like there is something in the way. Please bring in on in the mailing list; I think it's an issue with your distribution / setup. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1603745&group_id=29880 From noreply at sourceforge.net Tue Dec 26 09:13:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Dec 2006 00:13:53 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1614164 ] 1.4.4/5 - regex_internal.h:458:20: alloca.h: No such file or Message-ID: Bugs item #1614164, was opened at 2006-12-13 04:38 Message generated for change (Comment added) made by daspez You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1614164&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: Open Resolution: None Priority: 5 Private: No Submitted By: alexus (a1exus) Assigned to: Nobody/Anonymous (nobody) Summary: 1.4.4/5 - regex_internal.h:458:20: alloca.h: No such file or Initial Comment: if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I../intl -I../plugins -I/usr/local/ssl/include -g -O2 -MT regex.o -MD -MP -MF ".deps/regex.Tpo" -c -o regex.o regex.c; \ then mv -f ".deps/regex.Tpo" ".deps/regex.Po"; else rm -f ".deps/regex.Tpo"; exit 1; fi In file included from regex.c:55: regex_internal.h:458:20: alloca.h: No such file or directory gmake[4]: *** [regex.o] Error 1 gmake[4]: Leaving directory `/usr/local/src/nagios-plugins-1.4.5/lib' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/local/src/nagios-plugins-1.4.5/lib' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/local/src/nagios-plugins-1.4.5/lib' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/local/src/nagios-plugins-1.4.5' gmake: *** [all] Error 2 d# find . -name regex.c ./lib/regex.c d# find . -name alloca.h d# ---------------------------------------------------------------------- Comment By: David (daspez) Date: 2006-12-26 19:13 Message: Logged In: YES user_id=1676837 Originator: NO Try compiling using the "--without-included-regex" parameter. I have had the same issue under FreeBSD 5.5 and it compiles using the above paramter. HIH. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1614164&group_id=29880 From noreply at sourceforge.net Tue Dec 26 16:13:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Dec 2006 07:13:27 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1614164 ] 1.4.4/5 - regex_internal.h:458:20: alloca.h: No such file or Message-ID: Bugs item #1614164, was opened at 2006-12-12 12:38 Message generated for change (Comment added) made by a1exus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1614164&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: Open Resolution: None Priority: 5 Private: No Submitted By: alexus (a1exus) Assigned to: Nobody/Anonymous (nobody) Summary: 1.4.4/5 - regex_internal.h:458:20: alloca.h: No such file or Initial Comment: if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I../intl -I../plugins -I/usr/local/ssl/include -g -O2 -MT regex.o -MD -MP -MF ".deps/regex.Tpo" -c -o regex.o regex.c; \ then mv -f ".deps/regex.Tpo" ".deps/regex.Po"; else rm -f ".deps/regex.Tpo"; exit 1; fi In file included from regex.c:55: regex_internal.h:458:20: alloca.h: No such file or directory gmake[4]: *** [regex.o] Error 1 gmake[4]: Leaving directory `/usr/local/src/nagios-plugins-1.4.5/lib' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/local/src/nagios-plugins-1.4.5/lib' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/local/src/nagios-plugins-1.4.5/lib' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/local/src/nagios-plugins-1.4.5' gmake: *** [all] Error 2 d# find . -name regex.c ./lib/regex.c d# find . -name alloca.h d# ---------------------------------------------------------------------- >Comment By: alexus (a1exus) Date: 2006-12-26 10:13 Message: Logged In: YES user_id=227889 Originator: YES this is what i did for "work-around" alexus at d:/usr/local/src/nagios-plugins-1.4.5> cd lib alexus at d:/usr/local/src/nagios-plugins-1.4.5/lib> ls -la alloca.h lrwxr-xr-x 1 root wheel 34 Dec 12 22:39 alloca.h -> /usr/src/gnu/usr.bin/sort/alloca.h alexus at d:/usr/local/src/nagios-plugins-1.4.5/lib> ---------------------------------------------------------------------- Comment By: David (daspez) Date: 2006-12-26 03:13 Message: Logged In: YES user_id=1676837 Originator: NO Try compiling using the "--without-included-regex" parameter. I have had the same issue under FreeBSD 5.5 and it compiles using the above paramter. HIH. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1614164&group_id=29880 From nagios at nagios.org Tue Dec 26 17:48:48 2006 From: nagios at nagios.org (Ethan Galstad) Date: Tue, 26 Dec 2006 10:48:48 -0600 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <26CE556D-8C1C-4F0D-B3F5-BFD4DE387023@altinity.com> References: <458AD7D0.1090902@nagios.org> <20061221191058.GA12311@eric.schwarzvogel.de> <20061221223901.GB22917@openfusion.com.au> <458B1B3D.4000103@nagios.org> <26CE556D-8C1C-4F0D-B3F5-BFD4DE387023@altinity.com> Message-ID: <45915270.6000807@nagios.org> Ton Voon wrote: > > On 21 Dec 2006, at 23:39, Ethan Galstad wrote: > >> I like Tobias' suggestion as well. >> >> As far as flexible location, that could be arranged. Limiting its >> location the the beginning X lines of the plugin would be far easier >> that figuring out how many lines the plugin has and working backwards. >> In order to reduce overhead/increase speed of detection the keywords, I >> would suggest we limit the possible location to the first 100 lines or >> less. >> >> Ton, Benoit, others... does this sound okay? > > Sorry, I've stayed quiet on this because I don't use epn, so don't > necessarily understand the issues. I know Gavin Carr uses epn, but I'm > not sure who else currently on the plugin team. > > My British penny (just less than two cents) says: vim style comments; > limit macro to first 10 lines. Maybe you could cache the plugin name > (keyed on file location?) so that you don't need to keep re-reading the > plugin? > > Ton Okay, CVS code now supports the following two incantations in the 2nd-10th lines of Perl plugins: # nagios:+epn # nagios:-epn Its probably better to cache the plugin directives as you mentioned, so I'll take a look at doing that. Although I can see it would be useful to allow people to tweak plugin directives without having to restart Nagios. Ethan Galstad, Nagios Developer --- Email: nagios at nagios.org Website: http://www.nagios.org From noreply at sourceforge.net Wed Dec 27 06:09:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Dec 2006 21:09:13 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1603745 ] check_disk remains in "uninterruptible sleep" state Message-ID: Bugs item #1603745, was opened at 2006-11-27 09:34 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1603745&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: blablup (blablup) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk remains in "uninterruptible sleep" state Initial Comment: On 2 Servers the plugin stays in an "uninterruptible sleep" state an there is no way to kill it (except reboot the system).That only happens if i use the -x DEVICE function, if I use the -p Path function everything looks good. It doesn?t matter which device I specify, every time it hangs. ps -aux looks like this: nagios 12783 0.0 0.0 1388 548 ? Ds 12:15 0:00 /home/nagios/check_disk -w 10% -c 5% -x /dev/hda nagios 12905 0.0 0.0 1388 548 ? Ds 12:17 0:00 /home/nagios/check_disk -w 10% -c 5% -x /dev/hda nagios 12997 0.0 0.0 1384 544 ? Ds 12:18 0:00 /home/nagios/check_disk -w 10% -c 5% -x /dev/hda n Best regards BlaBlup ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2006-12-27 00:09 Message: Logged In: YES user_id=375623 Originator: NO Works for me. It looks like there is something in the way. Please bring in on in the mailing list; I think it's an issue with your distribution / setup. ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2006-12-24 00:40 Message: Logged In: YES user_id=375623 Originator: NO Works for me. It looks like there is something in the way. Please bring in on in the mailing list; I think it's an issue with your distribution / setup. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1603745&group_id=29880 From sroegner at gmx.de Thu Dec 28 08:18:50 2006 From: sroegner at gmx.de (Steffen Roegner) Date: Thu, 28 Dec 2006 08:18:50 +0100 Subject: [Nagiosplug-devel] SNMP and hardware In-Reply-To: <20061219053621.036EC4F4046@desire.netways.de> References: <20061219053621.036EC4F4046@desire.netways.de> Message-ID: <45936FDA.7030401@gmx.de> Andy Wolstenholme schrieb: > Hi, > > I am trying to collect information from our various servers regarding hardware, specifially disk status, cluster status etc. > > Is anyone able to advise the best approach to do this. Is this possible via SNMP, if so where can i locate the specific libraries where i can reach down to specific hardware components. > > the servers in question are running Dell openmanage so i guess, we could use snmp against this. > > Any suggestions are greatly apprecaited > > andy > > Andy You might want to give my check_omsa_snmp plugin a shot. It does what you are requesting, querying dell servers with openmanage on them via snmp. And it has the advantage of either checking all implemented features (result would look like this: "PowerSupply, TemperatureProbe, VoltageProbe, CoolingDevice are ok") or explicitly checking one (or some) of these. Some documentation (also containing the download link) can be found here: http://www.sroegner.de/nagios/check_omsa_snmp.php cheers Steffen > > - Andy Wolstenholme (andywooly) > > ----------------------- > The mailing list archive is found here: > http://www.nagiosexchange.org/nagiosplug-devel.31.0.html > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________________ > 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 >