From spainter at rw3.com Fri Mar 5 15:19:26 2010 From: spainter at rw3.com (Shane Painter) Date: Fri, 5 Mar 2010 06:19:26 -0800 Subject: [Nagiosplug-devel] Coding NagiosXI Wizard Add-In for MSSQL/Jobs Message-ID: Greetings, Could someone please point me in the right direction to properly code a wizard add-in for the new (and very exciting) NagiosXI? I cannot seem to find any documentation relating to this wizard within the new product. I would like to contribute (with some help from my DBA) a nice wizard to add/configure monitoring for Microsoft SQL, including SQL Job status. Thanks in advance for your assistance. Cheers, -Shane Shane Painter Director, Information Technology Office 512.380.4151 / Mobile 512.294.5890 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 1533 bytes Desc: image001.gif URL: From dermoth at aei.ca Wed Mar 10 08:22:14 2010 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Wed, 10 Mar 2010 02:22:14 -0500 Subject: [Nagiosplug-devel] [PATCH] shortname enhancement Message-ID: <1268205734-17873-1-git-send-email-dermoth@aei.ca> Any comment on this patch? It's ugly but I can't think of any better way without re-writing entirely N::P. This patch makes shortname use the defined plugin's name if set, otherwise the normal method should prevail. To do so I had to generate shortname during np initialization instead of at use time. --- lib/Nagios/Plugin.pm | 16 +++------------- lib/Nagios/Plugin/Functions.pm | 14 +++++++++----- t/Nagios-Plugin-01.t | 8 +++++++- 3 files changed, 19 insertions(+), 19 deletions(-) diff --git a/lib/Nagios/Plugin.pm b/lib/Nagios/Plugin.pm index 697005a..82bbfcb 100644 --- a/lib/Nagios/Plugin.pm +++ b/lib/Nagios/Plugin.pm @@ -11,6 +11,7 @@ use Carp; use base qw(Class::Accessor::Fast); Nagios::Plugin->mk_accessors(qw( + shortname perfdata messages opts @@ -45,11 +46,8 @@ sub new { }, ); - my $shortname = undef; - if (exists $args{shortname}) { - $shortname = $args{shortname}; - delete $args{shortname}; - } + my $shortname = Nagios::Plugin::Functions::get_shortname(\%args); + delete $args{shortname} if (exists $args{shortname}); my $self = { shortname => $shortname, perfdata => [], # to be added later @@ -106,14 +104,6 @@ sub max_state_alt { Nagios::Plugin::Functions::max_state_alt(@_); } -# Override default shortname accessor to add default -sub shortname { - my $self = shift; - $self->{shortname} = shift if @_; - return $self->{shortname} || - Nagios::Plugin::Functions::get_shortname(); -} - # top level interface to Nagios::Plugin::Threshold sub check_threshold { my $self = shift; diff --git a/lib/Nagios/Plugin/Functions.pm b/lib/Nagios/Plugin/Functions.pm index 4ff6118..43f4282 100644 --- a/lib/Nagios/Plugin/Functions.pm +++ b/lib/Nagios/Plugin/Functions.pm @@ -54,12 +54,15 @@ my $_use_die = 0; sub _use_die { @_ ? $_use_die = shift : $_use_die }; sub get_shortname { - my %arg = @_; + my $arg = shift; - return $arg{plugin}->shortname if $arg{plugin}; + my $shortname = undef; - my $shortname = uc basename($ENV{NAGIOS_PLUGIN} || $0); - $shortname =~ s/^CHECK_//; # Remove any leading CHECK_ + return $arg->{shortname} if (defined($arg->{shortname})); + $shortname = $arg->{plugin} if (defined( $arg->{plugin})); + + $shortname = uc basename($shortname || $ENV{NAGIOS_PLUGIN} || $0); + $shortname =~ s/^CHECK_(?:BY_)?//; # Remove any leading CHECK_[BY_] $shortname =~ s/\..*$//; # Remove any trailing suffix return $shortname; } @@ -116,7 +119,8 @@ sub nagios_exit { # Setup output my $output = "$STATUS_TEXT{$code}"; $output .= " - $message" if defined $message && $message ne ''; - my $shortname = get_shortname(plugin => $arg->{plugin}); + my $shortname = ($arg->{plugin} ? $arg->{plugin}->shortname : undef); + $shortname ||= get_shortname(); #??Should happen only if funnctions are called directly $output = "$shortname $output" if $shortname; if ($arg->{plugin}) { my $plugin = $arg->{plugin}; diff --git a/t/Nagios-Plugin-01.t b/t/Nagios-Plugin-01.t index 3ada472..947a704 100644 --- a/t/Nagios-Plugin-01.t +++ b/t/Nagios-Plugin-01.t @@ -1,7 +1,7 @@ # Nagios::Plugin original test cases use strict; -use Test::More tests => 13; +use Test::More tests => 15; BEGIN { use_ok('Nagios::Plugin') }; @@ -23,6 +23,12 @@ is($p->shortname, "NAGIOS-PLUGIN-01", "shortname should default on new"); $p = Nagios::Plugin->new( shortname => "SIZE", () ); is($p->shortname, "SIZE", "shortname set correctly on new"); +$p = Nagios::Plugin->new( plugin => "check_stuff", () ); +is($p->shortname, "STUFF", "shortname uses plugin name as default"); + +$p = Nagios::Plugin->new( shortname => "SIZE", plugin => "check_stuff", () ); +is($p->shortname, "SIZE", "shortname is not overriden by default"); + diag "warn if < 10, critical if > 25 " if $ENV{TEST_VERBOSE}; my $t = $p->set_thresholds( warning => "10:25", critical => "~:25" ); -- 1.7.0.1 From ton.voon at opsera.com Wed Mar 10 10:18:15 2010 From: ton.voon at opsera.com (Ton Voon) Date: Wed, 10 Mar 2010 09:18:15 +0000 Subject: [Nagiosplug-devel] [PATCH] shortname enhancement In-Reply-To: <1268205734-17873-1-git-send-email-dermoth@aei.ca> References: <1268205734-17873-1-git-send-email-dermoth@aei.ca> Message-ID: On 10 Mar 2010, at 07:22, Thomas Guyot-Sionnest wrote: > Any comment on this patch? It's ugly but I can't think of any better > way without re-writing entirely N::P. > > > This patch makes shortname use the defined plugin's name if set, > otherwise the normal method should prevail. To do so I had to > generate shortname during np initialization instead of at use time. Doing it during initialization sounds reasonable. I think there is also the case where no shortname is wanted. So N::P- >new( shortname => "" ) should not set a prefix (with no space added at the beginning too!) Can you add a test case for this as well? Ton From noreply at sourceforge.net Thu Mar 11 00:15:26 2010 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 10 Mar 2010 23:15:26 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2968305 ] check_dhcp: send a REQUEST after receiving OFFERs Message-ID: Patches item #2968305, was opened at 2010-03-10 17:15 Message generated for change (Tracker Item Submitted) made by mikhollo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2968305&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: release-1.4.14 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike Holloway (mikhollo) Assigned to: Nobody/Anonymous (nobody) Summary: check_dhcp: send a REQUEST after receiving OFFERs Initial Comment: Patch against Plugin Version (-V output): 1.4.14 Plugin Name: check_dhcp Example Plugin Commandline: check_dhcp -i egiga0 Tested on operating system: linux Tested on architecture: arm/freebsd/linux Tested with compiler: gcc Patch adds the sending of a DHCPREQUEST after receiving OFFERs. This allows DHCP servers to release any IPs allocated by the OFFER back to their free pools immediately, rather than waiting for the offer to timeout. Some DHCP servers hold these offers for a long time, and will happily issue a new IP to the same device each time because the previous OFFER wasn't followed by a subsequent broadcast/unicast REQUEST. This could lead to an exhaustion of IP addresses from the DHCP server's free pool on some implementations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2968305&group_id=29880 From holger at CIS.FU-Berlin.DE Mon Mar 15 01:50:30 2010 From: holger at CIS.FU-Berlin.DE (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Mon, 15 Mar 2010 01:50:30 +0100 Subject: [Nagiosplug-devel] [PATCH] Let check_ntp_peer check the number of truechimers Message-ID: <20100315005030.GH13869726@CIS.FU-Berlin.DE> This patch adds support for checking the number of usable time sources? to the check_ntp_peer plugin. The new "-m" and "-n" options allow for specifying the according WARNING and CRITICAL thresholds (and thereby activating the truechimers check), respectively. ? That is, the number of peers which are classified as "truechimers" by NTP's intersection algorithm. --- If nobody objects, I'll commit this patch in a few days. NEWS | 1 + plugins/check_ntp_peer.c | 72 ++++++++++++++++++++++++++++++++++++--------- plugins/t/check_ntp.t | 24 +++++++------- 3 files changed, 70 insertions(+), 27 deletions(-) diff --git a/NEWS b/NEWS index 443389a..ea5e162 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,7 @@ This file documents the major additions and syntax changes between releases. 1.4.15 ... ENHANCEMENTS + New check_ntp_peer -m and -n options to check the number of usable time sources ("truechimers") FIXES Fix check_ircd binding to wrong interface (#668778) Add proxy-authorization option to check_http (Marcel Kuiper - #1323230, Bryan Irvine - #2863925) diff --git a/plugins/check_ntp_peer.c b/plugins/check_ntp_peer.c index e8325bc..d4689bc 100644 --- a/plugins/check_ntp_peer.c +++ b/plugins/check_ntp_peer.c @@ -56,6 +56,9 @@ static char *scrit="-1:16"; static short do_jitter=0; static char *jwarn="-1:5000"; static char *jcrit="-1:10000"; +static short do_truechimers=0; +static char *twarn="0:"; +static char *tcrit="0:"; static int syncsource_found=0; static int li_alarm=0; @@ -63,6 +66,7 @@ int process_arguments (int, char **); thresholds *offset_thresholds = NULL; thresholds *jitter_thresholds = NULL; thresholds *stratum_thresholds = NULL; +thresholds *truechimer_thresholds = NULL; void print_help (void); void print_usage (void); @@ -121,6 +125,7 @@ typedef struct { #define OP_READVAR 0x02 /* In peer status bytes, bits 6,7,8 determine clock selection status */ #define PEER_SEL(x) ((ntohs(x)>>8)&0x07) +#define PEER_TRUECHIMER 0x02 #define PEER_INCLUDED 0x04 #define PEER_SYNCSOURCE 0x06 @@ -160,12 +165,12 @@ void print_ntp_control_message(const ntp_control_message *p){ for(i=0;i= PEER_INCLUDED){ - if(PEER_SEL(peer[i].status) >= PEER_SYNCSOURCE){ - printf(" <-- current sync source"); - } else { - printf(" <-- current sync candidate"); - } + if(PEER_SEL(peer[i].status) >= PEER_SYNCSOURCE){ + printf(" <-- current sync source"); + } else if(PEER_SEL(peer[i].status) >= PEER_INCLUDED){ + printf(" <-- current sync candidate"); + } else if(PEER_SEL(peer[i].status) >= PEER_TRUECHIMER){ + printf(" <-- outlyer, but truechimer"); } printf("\n"); } @@ -194,7 +199,7 @@ setup_control_request(ntp_control_message *p, uint8_t opcode, uint16_t seq){ * status is pretty much useless as syncsource_found is a global variable * used later in main to check is the server was synchronized. It works * so I left it alone */ -int ntp_request(const char *host, double *offset, int *offset_result, double *jitter, int *stratum){ +int ntp_request(const char *host, double *offset, int *offset_result, double *jitter, int *stratum, int *num_truechimers){ int conn=-1, i, npeers=0, num_candidates=0; double tmp_offset = 0; int min_peer_sel=PEER_INCLUDED; @@ -209,6 +214,7 @@ int ntp_request(const char *host, double *offset, int *offset_result, double *ji status = STATE_OK; *offset_result = STATE_UNKNOWN; *jitter = *stratum = -1; + *num_truechimers = 0; /* Long-winded explanation: * Getting the sync peer offset, jitter and stratum requires a number of @@ -261,11 +267,14 @@ int ntp_request(const char *host, double *offset, int *offset_result, double *ji * at least some candidates. In the latter case we'll issue * a warning but go ahead with the check on them. */ for (i = 0; i < npeers; i++){ - if (PEER_SEL(peers[i].status) >= PEER_INCLUDED){ - num_candidates++; - if(PEER_SEL(peers[i].status) >= PEER_SYNCSOURCE){ - syncsource_found=1; - min_peer_sel=PEER_SYNCSOURCE; + if(PEER_SEL(peers[i].status) >= PEER_TRUECHIMER){ + (*num_truechimers)++; + if(PEER_SEL(peers[i].status) >= PEER_INCLUDED){ + num_candidates++; + if(PEER_SEL(peers[i].status) >= PEER_SYNCSOURCE){ + syncsource_found=1; + min_peer_sel=PEER_SYNCSOURCE; + } } } } @@ -413,6 +422,8 @@ int process_arguments(int argc, char **argv){ {"scrit", required_argument, 0, 'C'}, {"jwarn", required_argument, 0, 'j'}, {"jcrit", required_argument, 0, 'k'}, + {"twarn", required_argument, 0, 'm'}, + {"tcrit", required_argument, 0, 'n'}, {"timeout", required_argument, 0, 't'}, {"hostname", required_argument, 0, 'H'}, {"port", required_argument, 0, 'p'}, @@ -424,7 +435,7 @@ int process_arguments(int argc, char **argv){ usage ("\n"); while (1) { - c = getopt_long (argc, argv, "Vhv46qw:c:W:C:j:k:t:H:p:", longopts, &option); + c = getopt_long (argc, argv, "Vhv46qw:c:W:C:j:k:m:n:t:H:p:", longopts, &option); if (c == -1 || c == EOF || c == 1) break; @@ -467,6 +478,14 @@ int process_arguments(int argc, char **argv){ do_jitter=1; jcrit = optarg; break; + case 'm': + do_truechimers=1; + twarn = optarg; + break; + case 'n': + do_truechimers=1; + tcrit = optarg; + break; case 'H': if(is_host(optarg) == FALSE) usage2(_("Invalid hostname/address"), optarg); @@ -526,8 +545,16 @@ char *perfd_stratum (int stratum) TRUE, 0, TRUE, 16); } +char *perfd_truechimers (int num_truechimers) +{ + return perfdata ("truechimers", num_truechimers, "", + do_truechimers, (int)truechimer_thresholds->warning->end, + do_truechimers, (int)truechimer_thresholds->critical->end, + TRUE, 0, FALSE, 0); +} + int main(int argc, char *argv[]){ - int result, offset_result, stratum; + int result, offset_result, stratum, num_truechimers; double offset=0, jitter=0; char *result_line, *perfdata_line; @@ -544,6 +571,7 @@ int main(int argc, char *argv[]){ set_thresholds(&offset_thresholds, owarn, ocrit); set_thresholds(&jitter_thresholds, jwarn, jcrit); set_thresholds(&stratum_thresholds, swarn, scrit); + set_thresholds(&truechimer_thresholds, twarn, tcrit); /* initialize alarm signal handling */ signal (SIGALRM, socket_timeout_alarm_handler); @@ -552,7 +580,7 @@ int main(int argc, char *argv[]){ alarm (socket_timeout); /* This returns either OK or WARNING (See comment preceeding ntp_request) */ - result = ntp_request(server_address, &offset, &offset_result, &jitter, &stratum); + result = ntp_request(server_address, &offset, &offset_result, &jitter, &stratum, &num_truechimers); if(offset_result == STATE_UNKNOWN) { /* if there's no sync peer (this overrides ntp_request output): */ @@ -564,6 +592,9 @@ int main(int argc, char *argv[]){ result = max_state_alt(result, get_status(fabs(offset), offset_thresholds)); } + if(do_truechimers) + result = max_state_alt(result, get_status(num_truechimers, truechimer_thresholds)); + if(do_stratum) result = max_state_alt(result, get_status(stratum, stratum_thresholds)); @@ -604,6 +635,10 @@ int main(int argc, char *argv[]){ asprintf(&result_line, "%s, stratum=%i", result_line, stratum); asprintf(&perfdata_line, "%s %s", perfdata_line, perfd_stratum(stratum)); } + if (do_truechimers) { + asprintf(&result_line, "%s, truechimers=%i", result_line, num_truechimers); + asprintf(&perfdata_line, "%s %s", perfdata_line, perfd_truechimers(num_truechimers)); + } printf("%s|%s\n", result_line, perfdata_line); if(server_address!=NULL) free(server_address); @@ -640,6 +675,10 @@ void print_help(void){ printf (" %s\n", _("Warning threshold for jitter")); printf (" %s\n", "-k, --jcrit=THRESHOLD"); printf (" %s\n", _("Critical threshold for jitter")); + printf (" %s\n", "-m, --twarn=THRESHOLD"); + printf (" %s\n", _("Warning threshold for number of usable time sources (\"truechimers\")")); + printf (" %s\n", "-n, --tcrit=THRESHOLD"); + printf (" %s\n", _("Critical threshold for number of usable time sources (\"truechimers\")")); printf (_(UT_TIMEOUT), DEFAULT_SOCKET_TIMEOUT); printf (_(UT_VERBOSE)); @@ -668,6 +707,9 @@ void print_help(void){ printf(" %s\n", _("(See Notes above for more details on thresholds formats):")); printf(" %s\n", ("./check_ntp_peer -H ntpserv -w 0.5 -c 1 -j -1:100 -k -1:200")); printf("\n"); + printf(" %s\n", _("Only check the number of usable time sources (\"truechimers\"):")); + printf(" %s\n", ("./check_ntp_peer -H ntpserv -m :5 -n :3")); + printf("\n"); printf(" %s\n", _("Check only stratum:")); printf(" %s\n", ("./check_ntp_peer -H ntpserv -W 4 -C 6")); diff --git a/plugins/t/check_ntp.t b/plugins/t/check_ntp.t index b71c863..3eee6e1 100644 --- a/plugins/t/check_ntp.t +++ b/plugins/t/check_ntp.t @@ -34,9 +34,9 @@ my $hostname_invalid = getTestParameter( "NP_HOSTNAME_INVALID", my $ntp_okmatch1 = '/^NTP\sOK:\sOffset\s-?[0-9]+(\.[0-9]+)?(e-[0-9]{2})?\ssecs/'; my $ntp_warnmatch1 = '/^NTP\sWARNING:\sOffset\s-?[0-9]+(\.[0-9]+)?(e-[0-9]{2})?\ssecs/'; my $ntp_critmatch1 = '/^NTP\sCRITICAL:\sOffset\s-?[0-9]+(\.[0-9]+)?(e-[0-9]{2})?\ssecs/'; -my $ntp_okmatch2 = '/^NTP\sOK:\sOffset\s-?[0-9]+(\.[0-9]+)?(e-[0-9]{2})?\ssecs,\sjitter=[0-9]+\.[0-9]+,\sstratum=[0-9]{1,2}/'; -my $ntp_warnmatch2 = '/^NTP\sWARNING:\sOffset\s-?[0-9]+(\.[0-9]+)?(e-[0-9]{2})?\ssecs,\sjitter=[0-9]+\.[0-9]+,\sstratum=[0-9]{1,2}/'; -my $ntp_critmatch2 = '/^NTP\sCRITICAL:\sOffset\s-?[0-9]+(\.[0-9]+)?(e-[0-9]{2})?\ssecs,\sjitter=[0-9]+\.[0-9]+,\sstratum=[0-9]{1,2}/'; +my $ntp_okmatch2 = '/^NTP\sOK:\sOffset\s-?[0-9]+(\.[0-9]+)?(e-[0-9]{2})?\ssecs,\sjitter=[0-9]+\.[0-9]+,\sstratum=[0-9]{1,2},\struechimers=[0-9]+/'; +my $ntp_warnmatch2 = '/^NTP\sWARNING:\sOffset\s-?[0-9]+(\.[0-9]+)?(e-[0-9]{2})?\ssecs,\sjitter=[0-9]+\.[0-9]+,\sstratum=[0-9]{1,2},\struechimers=[0-9]+/'; +my $ntp_critmatch2 = '/^NTP\sCRITICAL:\sOffset\s-?[0-9]+(\.[0-9]+)?(e-[0-9]{2})?\ssecs,\sjitter=[0-9]+\.[0-9]+,\sstratum=[0-9]{1,2},\struechimers=[0-9]+/'; my $ntp_noresponse = '/^(CRITICAL - Socket timeout after 3 seconds)|(NTP CRITICAL: No response from NTP server)$/'; my $ntp_nosuchhost = '/^check_ntp.*: Invalid hostname/address - ' . $hostname_invalid . '/'; @@ -90,21 +90,21 @@ foreach my $plugin (@PLUGINS2) { SKIP: { skip "No NTP server defined", 1 unless $ntp_service; $res = NPTest->testCmd( - "./$plugin -H $ntp_service -w 1000 -c 2000 -W 20 -C 21 -j 100000 -k 200000" + "./$plugin -H $ntp_service -w 1000 -c 2000 -W 20 -C 21 -j 100000 -k 200000 -m 1: -n 0:" ); - cmp_ok( $res->return_code, '==', 0, "$plugin: Good NTP result with jitter and stratum check" ); - like( $res->output, $ntp_okmatch2, "$plugin: Output match OK with jitter and stratum" ); + cmp_ok( $res->return_code, '==', 0, "$plugin: Good NTP result with jitter, stratum, and truechimers check" ); + like( $res->output, $ntp_okmatch2, "$plugin: Output match OK with jitter, stratum, and truechimers" ); $res = NPTest->testCmd( - "./$plugin -H $ntp_service -w 1000 -c 2000 -W \\~:-1 -C 21 -j 100000 -k 200000" + "./$plugin -H $ntp_service -w 1000 -c 2000 -W \\~:-1 -C 21 -j 100000 -k 200000 -m 1: -n 0:" ); - cmp_ok( $res->return_code, '==', 1, "$plugin: Warning NTP result with jitter and stratum check" ); - like( $res->output, $ntp_warnmatch2, "$plugin: Output match WARNING with jitter and stratum" ); + cmp_ok( $res->return_code, '==', 1, "$plugin: Warning NTP result with jitter, stratum, and truechimers check" ); + like( $res->output, $ntp_warnmatch2, "$plugin: Output match WARNING with jitter, stratum, and truechimers" ); $res = NPTest->testCmd( - "./$plugin -H $ntp_service -w 1000 -c 2000 -W 20 -C 21 -j 100000 -k \\~:-1" + "./$plugin -H $ntp_service -w 1000 -c 2000 -W 20 -C 21 -j 100000 -k \\~:-1 -m 1: -n 0:" ); - cmp_ok( $res->return_code, '==', 2, "$plugin: Critical NTP result with jitter and stratum check" ); - like( $res->output, $ntp_critmatch2, "$plugin: Output match CRITICAL with jitter and stratum" ); + cmp_ok( $res->return_code, '==', 2, "$plugin: Critical NTP result with jitter, stratum, and truechimers check" ); + like( $res->output, $ntp_critmatch2, "$plugin: Output match CRITICAL with jitter, stratum, and truechimers" ); } } -- From massimiliano.ziccardi at gmail.com Mon Mar 15 17:10:12 2010 From: massimiliano.ziccardi at gmail.com (Massimiliano Ziccardi) Date: Mon, 15 Mar 2010 17:10:12 +0100 Subject: [Nagiosplug-devel] Question about a documentation ambiguity (Thresholds) Message-ID: <445a8b101003150910u560efb1h655689828da6d6e4@mail.gmail.com> Hi all. What is the right way to handle thresholds when developing Nagios plugins? The documentation ( http://nagiosplug.sourceforge.net/developer-guidelines.html#THRESHOLDFORMAT) says: 8x------ 10:20 Generate an alert if x < 10 or > 20, (outside the range of {10 .. 20}) 8x------ while few rows below says: 8x------ check_stuff -c10:20 Critical if "stuff" is 10 to 20 8x------ What is the right behaviour? (In my opinion, the second one is much clearer, however check_snmp works like described in the first case...) Regards, Massimiliano -------------- next part -------------- An HTML attachment was scrubbed... URL: From ton.voon at opsera.com Mon Mar 15 20:46:05 2010 From: ton.voon at opsera.com (Ton Voon) Date: Mon, 15 Mar 2010 19:46:05 +0000 Subject: [Nagiosplug-devel] Question about a documentation ambiguity (Thresholds) In-Reply-To: <445a8b101003150910u560efb1h655689828da6d6e4@mail.gmail.com> References: <445a8b101003150910u560efb1h655689828da6d6e4@mail.gmail.com> Message-ID: <8A332109-3D46-4E47-ADFF-227ACDDF34B0@opsera.com> On 15 Mar 2010, at 16:10, Massimiliano Ziccardi wrote: > Hi all. > > What is the right way to handle thresholds when developing Nagios > plugins? > > The documentation (http://nagiosplug.sourceforge.net/developer-guidelines.html#THRESHOLDFORMAT > ) says: > > 8x------ > 10:20 Generate an alert if x < 10 or > 20, (outside the range of > {10 .. 20}) > 8x------ > > while few rows below says: > > 8x------ > check_stuff -c10:20 Critical if "stuff" is 10 to 20 > 8x------ > > What is the right behaviour? (In my opinion, the second one is much > clearer, however check_snmp works like described in the first case...) The 1st is correct. I've updated the docs for the 2nd. I agree that the 2nd looks much cleaner. We've just not got round to changing this: http://nagiosplugins.org/rfc/new_threshold_syntax Ton -------------- next part -------------- An HTML attachment was scrubbed... URL: From dermoth at aei.ca Tue Mar 16 05:36:40 2010 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 16 Mar 2010 00:36:40 -0400 Subject: [Nagiosplug-devel] [PATCH] Let check_ntp_peer check the number of truechimers In-Reply-To: <20100315005030.GH13869726@CIS.FU-Berlin.DE> References: <20100315005030.GH13869726@CIS.FU-Berlin.DE> Message-ID: <4B9F0AD8.9090700@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/03/10 08:50 PM, Holger Wei? wrote: > This patch adds support for checking the number of usable time sources? > to the check_ntp_peer plugin. The new "-m" and "-n" options allow for > specifying the according WARNING and CRITICAL thresholds (and thereby > activating the truechimers check), respectively. > > ? That is, the number of peers which are classified as "truechimers" by > NTP's intersection algorithm. > --- > > If nobody objects, I'll commit this patch in a few days. Nice work Holger! Absolutely no objections from me... > NEWS | 1 + > plugins/check_ntp_peer.c | 72 ++++++++++++++++++++++++++++++++++++--------- > plugins/t/check_ntp.t | 24 +++++++------- > 3 files changed, 70 insertions(+), 27 deletions(-) - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFLnwrX6dZ+Kt5BchYRAtGeAKCZH0ezGO4occwljYv7BBee3SANNACg6EgP 5ebkWgwD/qF9rrZ/B2ImUL8= =qCLS -----END PGP SIGNATURE----- From Emmanuel.DOGUET at MANE.com Tue Mar 16 11:32:44 2010 From: Emmanuel.DOGUET at MANE.com (DOGUET Emmanuel) Date: Tue, 16 Mar 2010 11:32:44 +0100 Subject: [Nagiosplug-devel] subscribe Message-ID: <7309E5BCEDC4DC4BA820EF9497269EAD079A4618@frbslnt46.emea.sesam.mane.com> --- Emmanuel Doguet Ing?nieur syst?me Poste: 1442 GSM: 06 82 14 51 60 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Emmanuel.DOGUET at MANE.com Tue Mar 16 14:09:07 2010 From: Emmanuel.DOGUET at MANE.com (DOGUET Emmanuel) Date: Tue, 16 Mar 2010 14:09:07 +0100 Subject: [Nagiosplug-devel] check_disk option for Centreon Message-ID: <7309E5BCEDC4DC4BA820EF9497269EAD079C5CE0@frbslnt46.emea.sesam.mane.com> Hello, I use since weeks Nagios with Centreon (Migration from Hobbit/BB). I have wrote and adapts some plugins (IO, Oracle, RAC...) for working fine with Centreon Graph. Like for check_disk, I have modified the perf data output for always display in bytes unit (only perfdata). With this it's centreon who interpret the Unit ( MB, GB ) on the graph. Instead return: DISK WARNING - free space: / 567 MB (62% inode=98%);| /=343MB;95;864;0;960 For Centreon it's better to return: DISK WARNING - free space: / 562 MB (61% inode=98%);| /=365658112;;; I can send a patch if you want. Best regards PS: Sorry for my English... I'm French! --- Emmanuel Doguet Ing?nieur syst?me Poste: 1442 GSM: 06 82 14 51 60 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dermoth at aei.ca Wed Mar 17 01:32:41 2010 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 16 Mar 2010 20:32:41 -0400 Subject: [Nagiosplug-devel] check_disk option for Centreon In-Reply-To: <7309E5BCEDC4DC4BA820EF9497269EAD079C5CE0@frbslnt46.emea.sesam.mane.com> References: <7309E5BCEDC4DC4BA820EF9497269EAD079C5CE0@frbslnt46.emea.sesam.mane.com> Message-ID: <4BA02329.8040401@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/03/10 09:09 AM, DOGUET Emmanuel wrote: > Hello, > > > > I use since weeks Nagios with Centreon (Migration from Hobbit/BB). > > I have wrote and adapts some plugins (IO, Oracle, RAC?) for working > fine with Centreon Graph. > > > > Like for check_disk, I have modified the perf data output for always > display in bytes unit (only perfdata). > > With this it?s centreon who interpret the Unit ( MB, GB ) on the graph. > > > > > > > > Instead return: > > > > DISK WARNING - free space: / 567 MB (62% inode=98%);| /=343MB;95;864;0;960 > > > > For Centreon it?s better to return: > > > > DISK WARNING - free space: / 562 MB (61% inode=98%);| /=365658112;;; > > > > > > I can send a patch if you want. This is definitely something that will have to change; unfortunately we can't just change it between releases and break everyone's graphs. This will have to wait until a major release, end even then it would be best to provide a backward-compatibility option. For that reason I think it will be best to wait for the new thresholds format, as the new format will allow adding such options and should be the main feature of the next major release. There is an RFC for the new thresholds, although we still have to publish additional design notes that were discussed during the last OSMC conference. Anyone willing to help coding this feature is welcome; the current RFC is available here: http://nagiosplugins.org/rfc/new_threshold_syntax - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFLoCMp6dZ+Kt5BchYRAlocAKDA5IFsmYRaQSvqI5hAJOs9ktMICgCdE/MC 2j/LMg/ay1ZxQdf9VBNgaTY= =Zezp -----END PGP SIGNATURE----- From Emmanuel.DOGUET at MANE.com Wed Mar 17 09:05:22 2010 From: Emmanuel.DOGUET at MANE.com (DOGUET Emmanuel) Date: Wed, 17 Mar 2010 09:05:22 +0100 Subject: [Nagiosplug-devel] check_disk option for Centreon In-Reply-To: <4BA02329.8040401@aei.ca> References: <7309E5BCEDC4DC4BA820EF9497269EAD079C5CE0@frbslnt46.emea.sesam.mane.com> <4BA02329.8040401@aei.ca> Message-ID: <7309E5BCEDC4DC4BA820EF9497269EAD079C6967@frbslnt46.emea.sesam.mane.com> Hello, With centreon the format "label=value[uom]" don't produce graph with real unit. I'm prefere force "bytes" unit for example and Centreon convert display in MB, GB. For compatibility it can be juste an option "--force-bytes-perfdata" Best regards. -----Original Message----- From: Thomas Guyot-Sionnest [mailto:dermoth at aei.ca] Sent: mercredi 17 mars 2010 01:33 To: Nagios Plugin Development Mailing List Subject: Re: [Nagiosplug-devel] check_disk option for Centreon -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/03/10 09:09 AM, DOGUET Emmanuel wrote: > Hello, > > > > I use since weeks Nagios with Centreon (Migration from Hobbit/BB). > > I have wrote and adapts some plugins (IO, Oracle, RAC?) for working > fine with Centreon Graph. > > > > Like for check_disk, I have modified the perf data output for always > display in bytes unit (only perfdata). > > With this it?s centreon who interpret the Unit ( MB, GB ) on the graph. > > > > > > > > Instead return: > > > > DISK WARNING - free space: / 567 MB (62% inode=98%);| /=343MB;95;864;0;960 > > > > For Centreon it?s better to return: > > > > DISK WARNING - free space: / 562 MB (61% inode=98%);| /=365658112;;; > > > > > > I can send a patch if you want. This is definitely something that will have to change; unfortunately we can't just change it between releases and break everyone's graphs. This will have to wait until a major release, end even then it would be best to provide a backward-compatibility option. For that reason I think it will be best to wait for the new thresholds format, as the new format will allow adding such options and should be the main feature of the next major release. There is an RFC for the new thresholds, although we still have to publish additional design notes that were discussed during the last OSMC conference. Anyone willing to help coding this feature is welcome; the current RFC is available here: http://nagiosplugins.org/rfc/new_threshold_syntax - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFLoCMp6dZ+Kt5BchYRAlocAKDA5IFsmYRaQSvqI5hAJOs9ktMICgCdE/MC 2j/LMg/ay1ZxQdf9VBNgaTY= =Zezp -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________________ 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 dermoth at aei.ca Wed Mar 17 09:42:19 2010 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Wed, 17 Mar 2010 04:42:19 -0400 Subject: [Nagiosplug-devel] check_disk option for Centreon In-Reply-To: <7309E5BCEDC4DC4BA820EF9497269EAD079C6967@frbslnt46.emea.sesam.mane.com> References: <7309E5BCEDC4DC4BA820EF9497269EAD079C5CE0@frbslnt46.emea.sesam.mane.com> <4BA02329.8040401@aei.ca> <7309E5BCEDC4DC4BA820EF9497269EAD079C6967@frbslnt46.emea.sesam.mane.com> Message-ID: <4BA095EB.2000008@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/03/10 04:05 AM, DOGUET Emmanuel wrote: > Hello, > > With centreon the format "label=value[uom]" don't produce graph with real unit. I'm prefere force "bytes" unit for example and Centreon convert display in MB, GB. > > For compatibility it can be juste an option "--force-bytes-perfdata" The new thresholds format specify a unit option (where it makes sense; check_disk knows the unit is bytes) and a prefix (SI prefix, including the binary ones like Ki, Mi...), but the idea is that the prefix should be used for printing only and performance data should be in double format without any prefix. It will however be easy to add extra parameters to alter the functionality, so that is someone needs backwards-compatible output we could add an option for that. > -----Original Message----- > From: Thomas Guyot-Sionnest [mailto:dermoth at aei.ca] > Sent: mercredi 17 mars 2010 01:33 > To: Nagios Plugin Development Mailing List > Subject: Re: [Nagiosplug-devel] check_disk option for Centreon > > On 16/03/10 09:09 AM, DOGUET Emmanuel wrote: >> Hello, > > > >> I use since weeks Nagios with Centreon (Migration from Hobbit/BB). > >> I have wrote and adapts some plugins (IO, Oracle, RAC&) for working >> fine with Centreon Graph. > > > >> Like for check_disk, I have modified the perf data output for always >> display in bytes unit (only perfdata). > >> With this its centreon who interpret the Unit ( MB, GB ) on the graph. > > > > > > > >> Instead return: > > > >> DISK WARNING - free space: / 567 MB (62% inode=98%);| /=343MB;95;864;0;960 > > > >> For Centreon its better to return: > > > >> DISK WARNING - free space: / 562 MB (61% inode=98%);| /=365658112;;; > > > > > >> I can send a patch if you want. > > This is definitely something that will have to change; unfortunately we > can't just change it between releases and break everyone's graphs. This > will have to wait until a major release, end even then it would be best > to provide a backward-compatibility option. > > For that reason I think it will be best to wait for the new thresholds > format, as the new format will allow adding such options and should be > the main feature of the next major release. > > There is an RFC for the new thresholds, although we still have to > publish additional design notes that were discussed during the last OSMC > conference. Anyone willing to help coding this feature is welcome; the > current RFC is available here: > > http://nagiosplugins.org/rfc/new_threshold_syntax > - ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________________ 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 - ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________________ 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 - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFLoJXq6dZ+Kt5BchYRAjdBAKC3GSt5ykzcLCX/nEP+RP7W1iZO1ACgn8zS jA2Ck2HBYENDB0+w52rXXZg= =33Od -----END PGP SIGNATURE----- From dermoth at aei.ca Wed Mar 17 10:29:51 2010 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Wed, 17 Mar 2010 05:29:51 -0400 Subject: [Nagiosplug-devel] check_http bug? In-Reply-To: <4B75E897.8050106@srihosting.com> References: <4B75E897.8050106@srihosting.com> Message-ID: <4BA0A10F.5040708@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/02/10 06:47 PM, David Beuving wrote: > Hello, > > I have found a certain behavior in the check_http plugin that seems like > a bug to me. > > When using the plugin in verbose mode, it responds showing this as part > of the report: > > http://ipaddress:port/path > > This leads me to believe that it is sending the ipaddress as the host > header rather than the hostname, but after looking at the code it is > clear the check works by sending the hostname it simply shows ipaddress > in the verbose response. > > I have replaced line 912 in check_http.c: > use_ssl ? "https" : "http", server_address, > with > use_ssl ? "https" : "http", host_name ? host_name : server_address, > > Please let me know if this is a bug and something you will update in the > next release or if it is meant to work this way. Verbose output is mostly for debugging, and since the server's IP address can be forced I believe this is correct - i.e. this is where check_http connects, and the host header can be found in the output as well. If you specify -H only it shows the hostname there, because in that case server_address is copied from host_name. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFLoKEP6dZ+Kt5BchYRAn6gAJ96i9ooNPwgA6D7Vwa7gluvZr+YhACgiHlx Q4suqkcWHEVo/yMecqBw0fU= =WDt0 -----END PGP SIGNATURE----- From holger at CIS.FU-Berlin.DE Thu Mar 18 00:40:04 2010 From: holger at CIS.FU-Berlin.DE (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Thu, 18 Mar 2010 00:40:04 +0100 Subject: [Nagiosplug-devel] [PATCH] Let check_ntp_peer check the number of truechimers In-Reply-To: <4B9F0AD8.9090700@aei.ca> References: <20100315005030.GH13869726@CIS.FU-Berlin.DE> <4B9F0AD8.9090700@aei.ca> Message-ID: <20100317234004.GB14383@CIS.FU-Berlin.DE> * Thomas Guyot-Sionnest [2010-03-16 00:36]: > On 14/03/10 08:50 PM, Holger Wei? wrote: > > This patch adds support for checking the number of usable time sources? > > to the check_ntp_peer plugin. The new "-m" and "-n" options allow for > > specifying the according WARNING and CRITICAL thresholds (and thereby > > activating the truechimers check), respectively. > > > > ? That is, the number of peers which are classified as "truechimers" by > > NTP's intersection algorithm. > > --- > > > > If nobody objects, I'll commit this patch in a few days. > > Nice work Holger! Absolutely no objections from me... Thank you for looking into it, I committed the patch. Holger From noreply at sourceforge.net Thu Mar 18 15:19:35 2010 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 18 Mar 2010 14:19:35 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2972610 ] check_ldap doesnot compile on OpenSolaris Message-ID: Bugs item #2972610, was opened at 2010-03-18 15:19 Message generated for change (Tracker Item Submitted) made by wernerfrerichs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2972610&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: v1.4.14 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Werner Frerichs (wernerfrerichs) Assigned to: Nobody/Anonymous (nobody) Summary: check_ldap doesnot compile on OpenSolaris Initial Comment: root at nagmon:~/nagios-plugins-1.4.14# uname -a SunOS nagmon 5.11 snv_111b i86pc i386 i86pc Solaris root at nagmon:~/nagios-plugins-1.4.14# ./configure --prefix=/usr/nagios --enable-perl-modules root at nagmon:~/nagios-plugins-1.4.14# make ... root at nagmon:~/nagios-plugins-1.4.14# cd plugins root at nagmon:~/nagios-plugins-1.4.14/plugins# make check_ldap gcc -DLOCALEDIR=\"/usr/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I.. -I.. -I../lib -I../gl -I../intl -I/usr/include -DNP_VERSION='"1.4.14"' -g -O2 -MT check_ldap.o -MD -MP -MF .deps/check_ldap.Tpo -c -o check_ldap.o check_ldap.c mv -f .deps/check_ldap.Tpo .deps/check_ldap.Po /bin/sh ../libtool --tag=CC --mode=link gcc -DNP_VERSION='"1.4.14"' -g -O2 -L. -o check_ldap check_ldap.o netutils.o utils.o ../lib/libnagiosplug.a ../gl/libgnu.a -lnsl -lsocket -lresolv -lpthread -ldl gcc "-DNP_VERSION=\"1.4.14\"" -g -O2 -o check_ldap check_ldap.o netutils.o utils.o -L/root/nagios-plugins-1.4.14/plugins ../lib/libnagiosplug.a ../gl/libgnu.a -lnsl -lsocket -lresolv -lpthread -ldl Undefined first referenced symbol in file ldap_bind_s check_ldap.o ldap_perror check_ldap.o ldap_unbind check_ldap.o ldap_open check_ldap.o ldap_search_s check_ldap.o ld: fatal: symbol referencing errors. No output written to check_ldap collect2: ld returned 1 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2972610&group_id=29880 From cbaker at windstream.com Fri Mar 19 14:43:53 2010 From: cbaker at windstream.com (Charles H. Baker) Date: Fri, 19 Mar 2010 09:43:53 -0400 Subject: [Nagiosplug-devel] I have a patch for the check_raid plugin Message-ID: <1269006233.15040.5.camel@rain> I have a patch for the check_raid plugin. What is the best place to submit it? [Thu Mar 18 16:50:40 cbaker at rain: nrpe] # diff -u check_raid check_raid.20100318-1647 --- check_raid 2006-09-06 22:34:22.000000000 -0400 +++ check_raid.20100318-1647 2010-03-18 16:50:39.621141262 -0400 @@ -63,7 +63,7 @@ } elsif($s =~ /Resync/i) { $status = $ERRORS{WARNING} if(!$status); } else { - $status = $ERRORS{ERROR}; + $status = $ERRORS{CRITICAL}; } $message .= "$d:$sd:$s "; } [Thu Mar 18 16:50:42 cbaker at rain: nrpe] # -- Charles H. Baker, Unix System Administration Windstream Communications Charles.Baker at windstream.com | 864.331.7896 | 864.990.1297 All life is a chance. So take it! The person who goes furthest is the one who is willing to do and dare. Dale Carnegie From massimiliano.ziccardi at gmail.com Fri Mar 19 14:55:15 2010 From: massimiliano.ziccardi at gmail.com (Massimiliano Ziccardi) Date: Fri, 19 Mar 2010 14:55:15 +0100 Subject: [Nagiosplug-devel] JNRPE and Java plugins Message-ID: <445a8b101003190655j3d183a9fi6c0fbbc16cdd18aa@mail.gmail.com> Just to let you know: if you are interested, some year ago I started an OpenSource project that allows the creation of Java plugin for Nagios without the overhead of the JVM (just one JVM is necessary to execute the JNRPE software; the plugins then runs inside the same JVM). The project is called JNRPE since it is a Java implementation of the NRPE communication protocol; to execute JNRPE plugins you must use check_nrpe. If you need to execute legacy plugins, they be executed through JNRPE using the EXEC JNRPE plugin. The project URL is http://sourceforge.net/apps/mediawiki/jnrpe/index.php?title=Main_Page Regards, Massimiliano -------------- next part -------------- An HTML attachment was scrubbed... URL: From hrpoliveira at gmail.com Fri Mar 19 15:56:32 2010 From: hrpoliveira at gmail.com (Helder Oliveira) Date: Fri, 19 Mar 2010 14:56:32 +0000 Subject: [Nagiosplug-devel] JNRPE and Java plugins In-Reply-To: <445a8b101003190655j3d183a9fi6c0fbbc16cdd18aa@mail.gmail.com> References: <445a8b101003190655j3d183a9fi6c0fbbc16cdd18aa@mail.gmail.com> Message-ID: Hello, This is very interesting to me, i will check later and maybe i pick it because i'm already developing plugins in java for nagios.. Good job! On Fri, Mar 19, 2010 at 1:55 PM, Massimiliano Ziccardi wrote: > Just to let you know: if you are interested, some year ago I started an > OpenSource project that allows the creation of Java plugin for Nagios > without the overhead of the JVM (just one JVM is necessary to execute the > JNRPE software; the plugins then runs inside the same JVM). > > The project is called JNRPE since it is a Java implementation of the NRPE > communication protocol; to execute JNRPE plugins you must use check_nrpe. > If you need to execute legacy plugins, they be executed through JNRPE using > the EXEC JNRPE plugin. > > The project URL is > http://sourceforge.net/apps/mediawiki/jnrpe/index.php?title=Main_Page > > Regards, > Massimiliano > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________________ > 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 Sat Mar 20 02:52:38 2010 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 20 Mar 2010 01:52:38 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2973603 ] disk_check, -g group, failing calculations Message-ID: Bugs item #2973603, was opened at 2010-03-20 12:52 Message generated for change (Tracker Item Submitted) made by bekar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2973603&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bekar (bekar) Assigned to: Nobody/Anonymous (nobody) Summary: disk_check, -g group, failing calculations Initial Comment: >From a tinderbox build: # Failed test 'grouping: exit warning if the sum of free megs on mp1+mp2 is between -w and -c ' # at ./t/check_disk.t line 312. # got: 0 # expected: 1 # Looks like you failed 1 test of 78. .. Testing: ./check_disk -w 350 -c 348 -g group -p / -p /boot not ok 68 - grouping: exit warning if the sum of free megs on mp1+mp2 is between -w and -c Manually running the test and the check_disk command used to get the amount of disk space in the test shows: [root at dev00 plugins]# ./check_disk -w 350 -c 348 -p / -p /boot DISK CRITICAL - free space: / 275 MB (15% inode=91%); /boot 74 MB (80% inode=99%);| /=1518MB;1540;1542;0;1890 /boot=18MB;-252;-250;0;98 [root at dev00 plugins]# ./check_disk -w 350 -c 348 -g group -p / -p /boot DISK OK - free space: group 500 MB (26% inode=91%);| group=1386MB;1639;1641;0;1989 The test is doing the calculation properly (349), adding one and taking one for warning / critical. The check_disk it's self is coming up with the wrong number for free space in the group. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2973603&group_id=29880 From noreply at sourceforge.net Sat Mar 20 02:55:20 2010 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 20 Mar 2010 01:55:20 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2973604 ] check_time.t and check_udp.t fail Message-ID: Bugs item #2973604, was opened at 2010-03-20 12:55 Message generated for change (Tracker Item Submitted) made by bekar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2973604&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: Open Resolution: None Priority: 5 Private: No Submitted By: Bekar (bekar) Assigned to: Nobody/Anonymous (nobody) Summary: check_time.t and check_udp.t fail Initial Comment: Using a Centos 5 system, both of these test packages don't work properly as their contents describe. check_time.t uses variable names including 'udp', yet the '-u' flag isn't passed to the check. As it does both tcp/udp the test should probably seperate them out and do both. check_udp.t fails on the behaviour of 'nc' on the system. I've had to add in: skip "No compatable netcat available", 6 unless (system("nc -l -w 1 -p 3333 -u > /dev/null 2>&1") == 0); to skip these listener check for the moment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2973604&group_id=29880 From noreply at sourceforge.net Sat Mar 20 02:59:22 2010 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 20 Mar 2010 01:59:22 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2973603 ] disk_check, -g group, failing calculations Message-ID: Bugs item #2973603, was opened at 2010-03-20 12:52 Message generated for change (Comment added) made by bekar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2973603&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bekar (bekar) Assigned to: Nobody/Anonymous (nobody) Summary: disk_check, -g group, failing calculations Initial Comment: >From a tinderbox build: # Failed test 'grouping: exit warning if the sum of free megs on mp1+mp2 is between -w and -c ' # at ./t/check_disk.t line 312. # got: 0 # expected: 1 # Looks like you failed 1 test of 78. .. Testing: ./check_disk -w 350 -c 348 -g group -p / -p /boot not ok 68 - grouping: exit warning if the sum of free megs on mp1+mp2 is between -w and -c Manually running the test and the check_disk command used to get the amount of disk space in the test shows: [root at dev00 plugins]# ./check_disk -w 350 -c 348 -p / -p /boot DISK CRITICAL - free space: / 275 MB (15% inode=91%); /boot 74 MB (80% inode=99%);| /=1518MB;1540;1542;0;1890 /boot=18MB;-252;-250;0;98 [root at dev00 plugins]# ./check_disk -w 350 -c 348 -g group -p / -p /boot DISK OK - free space: group 500 MB (26% inode=91%);| group=1386MB;1639;1641;0;1989 The test is doing the calculation properly (349), adding one and taking one for warning / critical. The check_disk it's self is coming up with the wrong number for free space in the group. ---------------------------------------------------------------------- >Comment By: Bekar (bekar) Date: 2010-03-20 12:59 Message: Bloody hell, bad reporting there, sorry. Plugin Version (-V output): check_disk v1.4.14-65-ge11b (nagios-plugins 1.4.14) Operating System: Linux (Centos 5) Architecture: x86_64 Compiler: gcc version 4.1.2 20080704 (Red Hat 4.1.2-46) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2973603&group_id=29880 From noreply at sourceforge.net Tue Mar 23 19:43:51 2010 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Mar 2010 18:43:51 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2975393 ] check_http HTTP CONNECT through proxy patch Message-ID: Patches item #2975393, was opened at 2010-03-23 13:43 Message generated for change (Tracker Item Submitted) made by mfrostp83 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2975393&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: release-1.4.14 Status: Open Resolution: None Priority: 5 Private: No Submitted By: mfrostp83 (mfrostp83) Assigned to: Nobody/Anonymous (nobody) Summary: check_http HTTP CONNECT through proxy patch Initial Comment: check_http cannot (as of 1.4.14) speak the HTTP CONNECT protocol through a proxy. This is primarily used for checking SSL through a proxy. The attached patch allows this functionality by using the -K or --http-connect flag telling check_http to connect with HTTP CONNECT. Note that this option depends on SSL being enabled and will only connect to a remote host using port 443 which is not adjustable from the command-line. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2975393&group_id=29880 From noreply at sourceforge.net Thu Mar 25 11:21:55 2010 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Mar 2010 10:21:55 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2976391 ] check_ldap fails on non default port for ldap with TLS Message-ID: Bugs item #2976391, was opened at 2010-03-25 11:21 Message generated for change (Tracker Item Submitted) made by rsauvat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2976391&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: v1.4.14 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Remi SAUVAT (rsauvat) Assigned to: Nobody/Anonymous (nobody) Summary: check_ldap fails on non default port for ldap with TLS Initial Comment: Hi, I have a openldap server running with TLS. The server is running fine with all other applications. But the nagios plugin check_ldap fail to contact my ldap server if I use a non default port. The plugin is working if I use the default port 636 on my ldap server and the plugin. Result from the command line ldap_bind: Can't contact LDAP server (-1) Could not init startTLS at port 8982! Plugin Version: 1.4.14 Plugin Name: check_ldap Plugin Commandline showing issues: /usr/share/nagios/libexec/check_ldaps -T -3 -H 'myldapserver.company.com' -p '8982' -b 'dc=ldap,dc=company,dc=com' -D 'cn=bind,dc=ldap,dc=company,dc=com' -P 'mydnpasswd' -w '10' -c '15' -v Operating System: Gentoo 2010 Architecture: amd64 Compiler: gcc (Gentoo 4.3.4 p1.1, pie-10.1.5) 4.3.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2976391&group_id=29880 From noreply at sourceforge.net Fri Mar 26 16:50:25 2010 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 26 Mar 2010 15:50:25 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2977105 ] check_ide_smart.c won't build with gcc 2.96 Message-ID: Bugs item #2977105, was opened at 2010-03-26 18:50 Message generated for change (Tracker Item Submitted) made by flatworm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2977105&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: Konstantin Khomoutov (flatworm) Assigned to: Nobody/Anonymous (nobody) Summary: check_ide_smart.c won't build with gcc 2.96 Initial Comment: check_ide_smart.c fails to build with gcc 2.96 raising this error: check_ide_smart.c: In function `main': check_ide_smart.c:164: parse error before `static' check_ide_smart.c:182: `longopts' undeclared (first use in this function) check_ide_smart.c:182: (Each undeclared identifier is reported only once check_ide_smart.c:182: for each function it appears in.) (This particular build was configured without --enable-extra-opts, but I beleive this won't change anything, see below.) As it seems, the failing piece of code assumes the compiler supports C99, that is, allows to mix initializations with declarations, which gcc 2.96 doesn't. The attached patch trivially fixes this problem by moving the code which performs initialization after the declaration of a static struct data. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2977105&group_id=29880 From noreply at sourceforge.net Fri Mar 26 16:51:26 2010 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 26 Mar 2010 15:51:26 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2977105 ] check_ide_smart.c won't build with gcc 2.96 Message-ID: Bugs item #2977105, was opened at 2010-03-26 18:50 Message generated for change (Comment added) made by flatworm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2977105&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: snapshot tarball Status: Open Resolution: None Priority: 5 Private: No Submitted By: Konstantin Khomoutov (flatworm) Assigned to: Nobody/Anonymous (nobody) Summary: check_ide_smart.c won't build with gcc 2.96 Initial Comment: check_ide_smart.c fails to build with gcc 2.96 raising this error: check_ide_smart.c: In function `main': check_ide_smart.c:164: parse error before `static' check_ide_smart.c:182: `longopts' undeclared (first use in this function) check_ide_smart.c:182: (Each undeclared identifier is reported only once check_ide_smart.c:182: for each function it appears in.) (This particular build was configured without --enable-extra-opts, but I beleive this won't change anything, see below.) As it seems, the failing piece of code assumes the compiler supports C99, that is, allows to mix initializations with declarations, which gcc 2.96 doesn't. The attached patch trivially fixes this problem by moving the code which performs initialization after the declaration of a static struct data. ---------------------------------------------------------------------- >Comment By: Konstantin Khomoutov (flatworm) Date: 2010-03-26 18:51 Message: Updated category and group to sensible values. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2977105&group_id=29880 From mark.frost1 at pepsico.com Fri Mar 26 17:07:26 2010 From: mark.frost1 at pepsico.com (Frost, Mark {PBC}) Date: Fri, 26 Mar 2010 12:07:26 -0400 Subject: [Nagiosplug-devel] question on check_procs and shell environment Message-ID: It seems that the check_procs configuration used on HPUX (and it looks like AIX although I haven't tested that one) doesn't handle command arguments at all, although the command implies that it does. It uses "/usr/bin/ps -el" as the execution command which does not return arguments. The end result is that the "command" and "arguments" values are to the same value (i.e. command=sh and arguments=sh) which is pretty useless. -a and --ereg-arguments-array just match on the command value. By comparison, on Linux, these values are fully accessible. While you can run 'ps' on HPUX and get more fields and better sets of arguments, you still don't quite get them all. There are no variants of 'ps' on HPUX that will give all the fields that the check_procs command allows unless you turn on UNIX95 standards compliance. Then you can make the HPUX 'ps' function like Linux 'ps' and specify the fields you want. However, this means you have to set an environment variable as in UNIX95= /usr/bin/ps -ex -o 'state uid pid ppid vsz sz pcpu comm args' I prefer to "really fix it" approach to "mostly fix it". check_procs calls run_cmd(). The comments in the code seem to indicate that the idea of passing in any environment is not allowed other than the single variable that is hardcoded in run_cmd_open (LC_ALL=C). I changed the code to also include the "UNIX95=" environment variable and check_procs works as it does on Linux. The only way I can think of to make this work reasonably is to somehow allow passing in this environment variable via run_cmd() say via a compile time options like the setting of PS_COMMAND, but it's my impression that this is not something that anyone wants to do for security reasons under any circumstances. I think the spopen() call is the wave of the future for these things, but it works similarly in that it doesn't allow environment arguments to be passed in. Is this idea of passing in environment just something that is an impassible barrier? (I realize I could probably just make a little shell script that runs this flavor of the 'ps' command and compile the plugins with that. I may end up doing that, but that's a solution for me and not a generalized solution for everyone else who wants to run on this platform and use check_procs). Thanks Mark From dermoth at aei.ca Sat Mar 27 04:54:03 2010 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Fri, 26 Mar 2010 23:54:03 -0400 Subject: [Nagiosplug-devel] question on check_procs and shell environment In-Reply-To: References: Message-ID: <4BAD815B.2030301@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26/03/10 12:07 PM, Frost, Mark {PBC} wrote: > It seems that the check_procs configuration used on HPUX (and it looks like AIX although I haven't tested that one) doesn't handle command arguments at all, although the command implies that it does. It uses "/usr/bin/ps -el" as the execution command which does not return arguments. The end result is that the "command" and "arguments" values are to the same value (i.e. command=sh and arguments=sh) which is pretty useless. -a and --ereg-arguments-array just match on the command value. > > By comparison, on Linux, these values are fully accessible. > > While you can run 'ps' on HPUX and get more fields and better sets of arguments, you still don't quite get them all. There are no variants of 'ps' on HPUX that will give all the fields that the check_procs command allows unless you turn on UNIX95 standards compliance. Then you can make the HPUX 'ps' function like Linux 'ps' and specify the fields you want. However, this means you have to set an environment variable as in > > UNIX95= /usr/bin/ps -ex -o 'state uid pid ppid vsz sz pcpu comm args' > > I prefer to "really fix it" approach to "mostly fix it". > > check_procs calls run_cmd(). The comments in the code seem to indicate that the idea of passing in any environment is not allowed other than the single variable that is hardcoded in run_cmd_open (LC_ALL=C). I changed the code to also include the "UNIX95=" environment variable and check_procs works as it does on Linux. > > The only way I can think of to make this work reasonably is to somehow allow passing in this environment variable via run_cmd() say via a compile time options like the setting of PS_COMMAND, but it's my impression that this is not something that anyone wants to do for security reasons under any circumstances. I think the spopen() call is the wave of the future for these things, but it works similarly in that it doesn't allow environment arguments to be passed in. > > Is this idea of passing in environment just something that is an impassible barrier? Hi Mark, Thank you for this very insightful explanation of the issues with check_procs on HPUX. Do you know if the UNIX95 trick will work on any decently-recent version of UX? run_cmd() is deprecated in favour of cmd_run_array (where possible) and cmd_run. It seems you are using an old version of check_procs as it already uses cmd_run, which was changed on 2008-07-08 to fix some issues (best would be using cmd_run_array, although I don't think it really matter for check_procs). So the best fix would be updating lib/utils_cmd.c to add functions that allow passing arguments (flags could also be used to determine whenever the environment should be added or replaced). I also think the environment shouldn't be erased by default as it is right now (adding LC_ALL=C should be the responsibility of the caller where needed...) I can help help coding that as time allow (this means I can't right now but keep bugging me ;) as needed!) Let me know if you need further detail on what I'm suggesting here. Thanks - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFLrYFa6dZ+Kt5BchYRAjuQAKDYcOlHiNNUUsRqyOVTGVw/iVO8JwCg4eak +q52p54uA98+U9F43g90BE8= =ADG9 -----END PGP SIGNATURE----- From noreply at sourceforge.net Sat Mar 27 05:18:59 2010 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 27 Mar 2010 04:18:59 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2977105 ] check_ide_smart.c won't build with gcc 2.96 Message-ID: Bugs item #2977105, was opened at 2010-03-26 11:50 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2977105&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-1.4.15 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Konstantin Khomoutov (flatworm) >Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: check_ide_smart.c won't build with gcc 2.96 Initial Comment: check_ide_smart.c fails to build with gcc 2.96 raising this error: check_ide_smart.c: In function `main': check_ide_smart.c:164: parse error before `static' check_ide_smart.c:182: `longopts' undeclared (first use in this function) check_ide_smart.c:182: (Each undeclared identifier is reported only once check_ide_smart.c:182: for each function it appears in.) (This particular build was configured without --enable-extra-opts, but I beleive this won't change anything, see below.) As it seems, the failing piece of code assumes the compiler supports C99, that is, allows to mix initializations with declarations, which gcc 2.96 doesn't. The attached patch trivially fixes this problem by moving the code which performs initialization after the declaration of a static struct data. ---------------------------------------------------------------------- >Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2010-03-27 00:18 Message: Nice catch; fixed Thanks! ---------------------------------------------------------------------- Comment By: Konstantin Khomoutov (flatworm) Date: 2010-03-26 11:51 Message: Updated category and group to sensible values. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2977105&group_id=29880 From noreply at sourceforge.net Sat Mar 27 08:21:29 2010 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 27 Mar 2010 07:21:29 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1180762 ] check_ssh does not properly close connection Message-ID: Bugs item #1180762, was opened at 2005-04-11 07:41 Message generated for change (Comment added) made by christian42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1180762&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: M. Sean Finney (seanius) Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: check_ssh does not properly close connection Initial Comment: with 1.4 and later, it looks like check_ssh doesn't properly close connections. for example, this is the previous behaviour of check_ssh in the 1.3 series: Apr 11 10:24:03 appsrv1 sshd[9822]: Connection closed by xxx.xxx.64.52 but in 1.4: appsrv1 sshd[10154]: fatal: Read from socket failed: Connection reset by peer i think this is just because close() isn't being called. i will verify this shortly... ---------------------------------------------------------------------- Comment By: Christian (christian42) Date: 2010-03-27 00:21 Message: Sorry to revive such an old issue, but I don't think this is resolved yet. I just built nagiosplugins-1.4.14 on Solaris 10/x86 and see the same old issue: --------------------------------------------------------- ray1# uname -a SunOS ray1 5.10 Generic_141445-09 i86pc i386 i86pc ray1# pwd /home/c/nagios-plugins-1.4.14 ray1# file ./plugins/check_ssh ./plugins/check_ssh: ELF 32-bit LSB executable 80386 Version 1, dynamically linked, not stripped ray1# ./plugins/check_ssh localhost SSH OK - Sun_SSH_1.1.2 (protocol 2.0) ray1# dmesg | tail -1 Mar 27 08:06:43 ray1 sshd[7169]: [ID 800047 auth.crit] fatal: Read from socket failed: Connection reset by peer --------------------------------------------------------- A similar installation on sparc (also with 1.4.14) shows the same result. When running through truss(1) it seems that the socket /is/ being closed though: ------------------------------- 10758/1: 0.0278 so_socket(PF_INET, SOCK_STREAM, IPPROTO_IP, "", SOV_DEFAULT) = 3 10758/1: 0.0280 connect(3, 0x0002CF10, 16, SOV_DEFAULT) = 0 [...] 10758/1: 0.0338 close(3) = 0 ------------------------------- So, maybe it's something else (and not a missing close()) causing these messages? During the connect and when one is fast enough, for a second or so one can see in netstat: 127.0.0.1.33748 127.0.0.1.22 49152 0 49152 0 FIN_WAIT_2 127.0.0.1.22 127.0.0.1.33748 49152 0 49152 0 CLOSE_WAIT Any ideas how to debug this further? Thanks, Christian. PS: Why was this closed as "Wont Fix" when clearly a change has been commited? ---------------------------------------------------------------------- Comment By: Sergey Svishchev (shattered) Date: 2007-11-06 00:13 Message: Logged In: YES user_id=45207 Originator: NO I'm using OpenSSH_3.8.1p1 FreeBSD-20060123 (shipped in FreeBSD 5.5) and can reproduce it at will. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2007-11-02 05:58 Message: Logged In: YES user_id=375623 Originator: NO Yes, emias made me realize that on IRC yesterday. I looked into it and I won't fix this because: 1. I can't reproduce it on OpenSSH, even with DEBUG logging (What SSH server/version are you using?) 2. There's no simple way to do that. It would at the very least require implementing the key exchange part of the protocol; I didn't even look further as this is way beyond the scope of this plugin. I suggest that you rather look into your SSH daemon or logging daemon configuration; or get this fixed with your ssh vendor. ---------------------------------------------------------------------- Comment By: Sergey Svishchev (shattered) Date: 2007-11-01 22:32 Message: Logged In: YES user_id=45207 Originator: NO It's check_ssh, not check_by_ssh. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2007-11-01 19:29 Message: Logged In: YES user_id=375623 Originator: NO There's no close in there, and no signs of seanius's commit. He either forgot to commit or commited it to the wrong branch... I'll take a look shortly. Since I never used check_by_ssh it'll help if you can give me a sample command-ling and what to look for (In logs I guess), so I won't have to reinvent the wheel :) Thanks ---------------------------------------------------------------------- Comment By: Sergey Svishchev (shattered) Date: 2007-10-31 07:34 Message: Logged In: YES user_id=45207 Originator: NO This is still a problem in 1.4.3 -- evidently, close() is not enough. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-04-11 11:07 Message: Logged In: YES user_id=226838 yup, calling close() before exiting resolves this problem, i've committed a change to cvs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1180762&group_id=29880 From mark.frost1 at pepsico.com Tue Mar 30 17:57:30 2010 From: mark.frost1 at pepsico.com (Frost, Mark {PBC}) Date: Tue, 30 Mar 2010 11:57:30 -0400 Subject: [Nagiosplug-devel] question on check_procs and shell environment In-Reply-To: <4BAD815B.2030301@aei.ca> References: <4BAD815B.2030301@aei.ca> Message-ID: >-----Original Message----- >From: Thomas Guyot-Sionnest [mailto:dermoth at aei.ca] >Sent: Friday, March 26, 2010 11:54 PM >To: Nagios Plugin Development Mailing List >Subject: Re: [Nagiosplug-devel] question on check_procs and shell >environment > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On 26/03/10 12:07 PM, Frost, Mark {PBC} wrote: >> It seems that the check_procs configuration used on HPUX (and it looks >like AIX although I haven't tested that one) doesn't handle command >arguments at all, although the command implies that it does. It uses >"/usr/bin/ps -el" as the execution command which does not return >arguments. The end result is that the "command" and "arguments" values >are to the same value (i.e. command=sh and arguments=sh) which is pretty >useless. -a and --ereg-arguments-array just match on the command value. >> >> By comparison, on Linux, these values are fully accessible. >> >> While you can run 'ps' on HPUX and get more fields and better sets of >arguments, you still don't quite get them all. There are no variants of >'ps' on HPUX that will give all the fields that the check_procs command >allows unless you turn on UNIX95 standards compliance. Then you can >make the HPUX 'ps' function like Linux 'ps' and specify the fields you >want. However, this means you have to set an environment variable as in >> >> UNIX95= /usr/bin/ps -ex -o 'state uid pid ppid vsz sz pcpu comm args' >> >> I prefer to "really fix it" approach to "mostly fix it". >> >> check_procs calls run_cmd(). The comments in the code seem to >indicate that the idea of passing in any environment is not allowed >other than the single variable that is hardcoded in run_cmd_open >(LC_ALL=C). I changed the code to also include the "UNIX95=" >environment variable and check_procs works as it does on Linux. >> >> The only way I can think of to make this work reasonably is to somehow >allow passing in this environment variable via run_cmd() say via a >compile time options like the setting of PS_COMMAND, but it's my >impression that this is not something that anyone wants to do for >security reasons under any circumstances. I think the spopen() call is >the wave of the future for these things, but it works similarly in that >it doesn't allow environment arguments to be passed in. >> >> Is this idea of passing in environment just something that is an >impassible barrier? > >Hi Mark, > >Thank you for this very insightful explanation of the issues with >check_procs on HPUX. Do you know if the UNIX95 trick will work on any >decently-recent version of UX? > Thomas, Honestly, I don't know. I have the impression that this is an HPUX only thing. I think other vendors have just adopted the UNIX95 standard outright. HPUX has held back for some reason. I think there's other incompatibilities with some of their other tools so they opted to make the UNIX95 support optional. Always swimming upstream... It appears that on AIX 5.3, the 'configure' script detects a method to extract the fields directly like Unix does. So perhaps the "AIX" note in the comment for HPUX refers to much older versions of AIX. My AIX builds seems to work OK for check_procs without additional fiddling. For now, I've just made a simple shell script that runs the proper 'ps' command and had check_procs call that as the PS_COMMAND. >run_cmd() is deprecated in favour of cmd_run_array (where possible) and >cmd_run. It seems you are using an old version of check_procs as it >already uses cmd_run, which was changed on 2008-07-08 to fix some issues >(best would be using cmd_run_array, although I don't think it really >matter for check_procs). > I'm using 1.4.14. I think I may have just writtn run_cmd() from memory and, well, misremembered. In the 1.4.14 check_procs.c, I see that the PS_COMMAND is run with: result = cmd_run( PS_COMMAND, &chld_out, &chld_err, 0); >So the best fix would be updating lib/utils_cmd.c to add functions that >allow passing arguments (flags could also be used to determine whenever >the environment should be added or replaced). I also think the >environment shouldn't be erased by default as it is right now (adding >LC_ALL=C should be the responsibility of the caller where needed...) > This confused me a little as the Nagios Plug-In Development Guidelines say that spopen() should be used if external commands should be executed (http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN250). But from looking at that function, it looks like it won't allow passing in environment variables either. Maybe the guidelines are outdated, but it's not clear if spopen() or cmd_run_array/cmd_run is preferred now. I think what I was really getting at was that in order to solve this particular HPUX issue, you'd need to pass in "UNIX95=" to the environment before executing the command, be it spopen() or the cmd_open()'s ultimate execve(). But none of those support passing in environment variables. They cmd_open() has that one hardcoded value for the environment and that's it. I'm getting the impression that passing in environment variables to such functions is considered a big security risk and that's why none of them support it. So if I were to consider trying to extend one of those functions to allow passing of an env array, am I creating a security problem that no one wants in the plugins? >I can help help coding that as time allow (this means I can't right now >but keep bugging me ;) as needed!) Let me know if you need further >detail on what I'm suggesting here. > >Thanks > >- -- >Thomas From nagios at isprime.org Tue Mar 30 18:01:43 2010 From: nagios at isprime.org (Kyle O'Donnell) Date: Tue, 30 Mar 2010 12:01:43 -0400 Subject: [Nagiosplug-devel] =?utf-8?q?question_on_check=5Fprocs_and_shell_?= =?utf-8?q?environment?= In-Reply-To: References: <4BAD815B.2030301@aei.ca> Message-ID: <145a561b962141f84a7ca5971f4ba161@localhost> The following works for AIX 5.3 and 6.1: ./configure --prefix=/opt/nagios --enable-perl-modules --with-ps-command="/usr/sysv/bin/ps -eo 's uid pid ppid vsz rss pcpu etime comm args'" --with-ps-format="%s %d %d %d %d %d %f %s %s %n" --with-ps-cols=10 --with-ps-varlist="procstat,&procuid,&procpid,&procppid,&procvsz,&procrss,&procpcpu,procetime,procprog,&pos" On Tue, 30 Mar 2010 11:57:30 -0400, "Frost, Mark {PBC}" wrote: >>-----Original Message----- >>From: Thomas Guyot-Sionnest [mailto:dermoth at aei.ca] >>Sent: Friday, March 26, 2010 11:54 PM >>To: Nagios Plugin Development Mailing List >>Subject: Re: [Nagiosplug-devel] question on check_procs and shell >>environment >> >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >>On 26/03/10 12:07 PM, Frost, Mark {PBC} wrote: >>> It seems that the check_procs configuration used on HPUX (and it looks >>like AIX although I haven't tested that one) doesn't handle command >>arguments at all, although the command implies that it does. It uses >>"/usr/bin/ps -el" as the execution command which does not return >>arguments. The end result is that the "command" and "arguments" values >>are to the same value (i.e. command=sh and arguments=sh) which is pretty >>useless. -a and --ereg-arguments-array just match on the command value. >>> >>> By comparison, on Linux, these values are fully accessible. >>> >>> While you can run 'ps' on HPUX and get more fields and better sets of >>arguments, you still don't quite get them all. There are no variants of >>'ps' on HPUX that will give all the fields that the check_procs command >>allows unless you turn on UNIX95 standards compliance. Then you can >>make the HPUX 'ps' function like Linux 'ps' and specify the fields you >>want. However, this means you have to set an environment variable as in >>> >>> UNIX95= /usr/bin/ps -ex -o 'state uid pid ppid vsz sz pcpu comm args' >>> >>> I prefer to "really fix it" approach to "mostly fix it". >>> >>> check_procs calls run_cmd(). The comments in the code seem to >>indicate that the idea of passing in any environment is not allowed >>other than the single variable that is hardcoded in run_cmd_open >>(LC_ALL=C). I changed the code to also include the "UNIX95=" >>environment variable and check_procs works as it does on Linux. >>> >>> The only way I can think of to make this work reasonably is to somehow >>allow passing in this environment variable via run_cmd() say via a >>compile time options like the setting of PS_COMMAND, but it's my >>impression that this is not something that anyone wants to do for >>security reasons under any circumstances. I think the spopen() call is >>the wave of the future for these things, but it works similarly in that >>it doesn't allow environment arguments to be passed in. >>> >>> Is this idea of passing in environment just something that is an >>impassible barrier? >> >>Hi Mark, >> >>Thank you for this very insightful explanation of the issues with >>check_procs on HPUX. Do you know if the UNIX95 trick will work on any >>decently-recent version of UX? >> > > Thomas, > > Honestly, I don't know. I have the impression that this is an HPUX only > thing. I think other vendors have just adopted the UNIX95 standard > outright. HPUX has held back for some reason. I think there's other > incompatibilities with some of their other tools so they opted to make > the UNIX95 support optional. Always swimming upstream... > > It appears that on AIX 5.3, the 'configure' script detects a method > to extract the fields directly like Unix does. So perhaps the "AIX" > note in the comment for HPUX refers to much older versions of AIX. > My AIX builds seems to work OK for check_procs without additional > fiddling. > > For now, I've just made a simple shell script that runs the proper > 'ps' command and had check_procs call that as the PS_COMMAND. > > >>run_cmd() is deprecated in favour of cmd_run_array (where possible) and >>cmd_run. It seems you are using an old version of check_procs as it >>already uses cmd_run, which was changed on 2008-07-08 to fix some issues >>(best would be using cmd_run_array, although I don't think it really >>matter for check_procs). >> > > I'm using 1.4.14. I think I may have just writtn run_cmd() from memory > and, well, misremembered. In the 1.4.14 check_procs.c, I see that > the PS_COMMAND is run with: > > result = cmd_run( PS_COMMAND, &chld_out, &chld_err, 0); > >>So the best fix would be updating lib/utils_cmd.c to add functions that >>allow passing arguments (flags could also be used to determine whenever >>the environment should be added or replaced). I also think the >>environment shouldn't be erased by default as it is right now (adding >>LC_ALL=C should be the responsibility of the caller where needed...) >> > > This confused me a little as the Nagios Plug-In Development Guidelines > say that spopen() should be used if external commands should be > executed > (http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN250). > But from looking at that function, it looks like it won't allow passing > in environment variables either. Maybe the guidelines are outdated, but > it's not clear if spopen() or cmd_run_array/cmd_run is preferred now. > > I think what I was really getting at was that in order to solve this > particular HPUX issue, you'd need to pass in "UNIX95=" to > the environment before executing the command, be it spopen() or the > cmd_open()'s ultimate execve(). But none of those support passing in > environment variables. They cmd_open() has that one hardcoded value for > the environment and that's it. I'm getting the impression that passing in > environment variables to such functions is considered a big security > risk and that's why none of them support it. So if I were to consider > trying to extend one of those functions to allow passing of an env > array, am I creating a security problem that no one wants in the > plugins? > >>I can help help coding that as time allow (this means I can't right now >>but keep bugging me ;) as needed!) Let me know if you need further >>detail on what I'm suggesting here. >> >>Thanks >> >>- -- >>Thomas > > > ------------------------------------------------------------------------------ > Download Intel? Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________________ > 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 dermoth at aei.ca Wed Mar 31 00:54:15 2010 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 30 Mar 2010 18:54:15 -0400 Subject: [Nagiosplug-devel] question on check_procs and shell environment In-Reply-To: References: <4BAD815B.2030301@aei.ca> Message-ID: <4BB28117.1060809@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30/03/10 11:57 AM, Frost, Mark {PBC} wrote: >> -----Original Message----- >> From: Thomas Guyot-Sionnest [mailto:dermoth at aei.ca] >> Sent: Friday, March 26, 2010 11:54 PM >> To: Nagios Plugin Development Mailing List >> Subject: Re: [Nagiosplug-devel] question on check_procs and shell >> environment >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 26/03/10 12:07 PM, Frost, Mark {PBC} wrote: >>> It seems that the check_procs configuration used on HPUX (and it looks >> like AIX although I haven't tested that one) doesn't handle command >> arguments at all, although the command implies that it does. It uses >> "/usr/bin/ps -el" as the execution command which does not return >> arguments. The end result is that the "command" and "arguments" values >> are to the same value (i.e. command=sh and arguments=sh) which is pretty >> useless. -a and --ereg-arguments-array just match on the command value. >>> By comparison, on Linux, these values are fully accessible. >>> >>> While you can run 'ps' on HPUX and get more fields and better sets of >> arguments, you still don't quite get them all. There are no variants of >> 'ps' on HPUX that will give all the fields that the check_procs command >> allows unless you turn on UNIX95 standards compliance. Then you can >> make the HPUX 'ps' function like Linux 'ps' and specify the fields you >> want. However, this means you have to set an environment variable as in >>> UNIX95= /usr/bin/ps -ex -o 'state uid pid ppid vsz sz pcpu comm args' >>> >>> I prefer to "really fix it" approach to "mostly fix it". >>> >>> check_procs calls run_cmd(). The comments in the code seem to >> indicate that the idea of passing in any environment is not allowed >> other than the single variable that is hardcoded in run_cmd_open >> (LC_ALL=C). I changed the code to also include the "UNIX95=" >> environment variable and check_procs works as it does on Linux. >>> The only way I can think of to make this work reasonably is to somehow >> allow passing in this environment variable via run_cmd() say via a >> compile time options like the setting of PS_COMMAND, but it's my >> impression that this is not something that anyone wants to do for >> security reasons under any circumstances. I think the spopen() call is >> the wave of the future for these things, but it works similarly in that >> it doesn't allow environment arguments to be passed in. >>> Is this idea of passing in environment just something that is an >> impassible barrier? >> >> Hi Mark, >> >> Thank you for this very insightful explanation of the issues with >> check_procs on HPUX. Do you know if the UNIX95 trick will work on any >> decently-recent version of UX? >> > > Thomas, > > Honestly, I don't know. I have the impression that this is an HPUX only > thing. I think other vendors have just adopted the UNIX95 standard > outright. HPUX has held back for some reason. I think there's other > incompatibilities with some of their other tools so they opted to make > the UNIX95 support optional. Always swimming upstream... I meant any decently-recent version of <> (I used "UX" as a diminutive). What I mean it that I don't want to break other HP-UX servers with a fix that work only on the newer ones, so I wanted to know if this has been working like that for some time. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFLsoEX6dZ+Kt5BchYRAmqGAJ92RmIShF+zWrpB9BuHn9QaeePmZACdF2T0 QJr/X3PHnDAclYqni6mom8Y= =q/rd -----END PGP SIGNATURE----- From noreply at sourceforge.net Wed Mar 31 03:38:29 2010 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Mar 2010 01:38:29 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1867716 ] check_snmp invalid performance data Message-ID: Bugs item #1867716, was opened at 2008-01-09 09:46 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1867716&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution >Group: release-1.4.15 >Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Joerg Linge (pitchfork) >Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: check_snmp invalid performance data Initial Comment: check_snmp produces invalid performance data. Version: check_snmp v1859 (nagios-plugins 1.4.11) Call: check_snmp -H localhost -C public -o sysUpTime.0 Output: SNMP OK - Timeticks: (49845368) 5 d | SNMPv2-MIB::sysUpTime.0=Timeticks: (49845368) 5 d OS: Linux SuSE 2.6.11.4-21.17-bigsmp Compiler: gcc version 3.3.5 20050117 (prerelease) (SUSE Linux) Kind regards J?rg ---------------------------------------------------------------------- >Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2010-03-30 21:38 Message: Reopened as this break half-working cases where although the method it broken, then end result is somewhat OK. A proper fix should check the string the same way as for getting the actual numeric value, and the string can then be cleaned up using a two-way numeric-string conversion. Example: Pre-1.4.12: $ ./check_snmp -H localhost -C public -o hrSWRunPerfMem.1 SNMP OK - 156 KBytes | HOST-RESOURCES-MIB::hrSWRunPerfMem.1=156 KBytes 1.4.14: $ ./check_snmp -H localhost -C public -o hrSWRunPerfMem.1 SNMP OK - 156 KBytes | v.1.4.12 has one valid perfdata string and a broken piece (what is supposed to be the unit associated with the OID). Since this will normally parse OK I'm counting that as a regression, although the fix was perfectly valid in that it sanitized the performance data. Will provide a better (hopefully) fix soon... ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-07-09 17:55 Message: Logged In: YES user_id=1694341 Originator: NO this problem is now fixed in svn. thank you for your report. ---------------------------------------------------------------------- Comment By: Joerg Linge (pitchfork) Date: 2008-01-12 06:07 Message: Logged In: YES user_id=1353850 Originator: YES sysUpTime.0 was just an example! I think check_snmp should only provide performance data on interger values. Just to be sure the performance data ist valid. J?rg ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2008-01-11 16:55 Message: Logged In: YES user_id=375623 Originator: NO This is the expected behavior; chhek_snmp doesn't know anything about TimeTicks Perhaps passing -Ot would help, but it would require different parsing and I don't know how it would affect any the the many special data formats in SNMP. This would be better suited as a feature request. However it would be much easier to just write a local check (run trough nrpe or check_by_ssh) that parse uptime. Also you should keep in mind that the SNMP uptime is the SNMP daemon uptime, not the server uptime (in other words you're ok as long as you don't restart the daemon). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1867716&group_id=29880 From noreply at sourceforge.net Wed Mar 31 04:40:22 2010 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Mar 2010 02:40:22 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1867716 ] check_snmp invalid performance data Message-ID: Bugs item #1867716, was opened at 2008-01-09 09:46 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1867716&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: release-1.4.15 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Joerg Linge (pitchfork) Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: check_snmp invalid performance data Initial Comment: check_snmp produces invalid performance data. Version: check_snmp v1859 (nagios-plugins 1.4.11) Call: check_snmp -H localhost -C public -o sysUpTime.0 Output: SNMP OK - Timeticks: (49845368) 5 d | SNMPv2-MIB::sysUpTime.0=Timeticks: (49845368) 5 d OS: Linux SuSE 2.6.11.4-21.17-bigsmp Compiler: gcc version 3.3.5 20050117 (prerelease) (SUSE Linux) Kind regards J?rg ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2010-03-30 22:40 Message: This problem is now fixed in Git. Thank you for your report. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2010-03-30 21:38 Message: Reopened as this break half-working cases where although the method it broken, then end result is somewhat OK. A proper fix should check the string the same way as for getting the actual numeric value, and the string can then be cleaned up using a two-way numeric-string conversion. Example: Pre-1.4.12: $ ./check_snmp -H localhost -C public -o hrSWRunPerfMem.1 SNMP OK - 156 KBytes | HOST-RESOURCES-MIB::hrSWRunPerfMem.1=156 KBytes 1.4.14: $ ./check_snmp -H localhost -C public -o hrSWRunPerfMem.1 SNMP OK - 156 KBytes | v.1.4.12 has one valid perfdata string and a broken piece (what is supposed to be the unit associated with the OID). Since this will normally parse OK I'm counting that as a regression, although the fix was perfectly valid in that it sanitized the performance data. Will provide a better (hopefully) fix soon... ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-07-09 17:55 Message: Logged In: YES user_id=1694341 Originator: NO this problem is now fixed in svn. thank you for your report. ---------------------------------------------------------------------- Comment By: Joerg Linge (pitchfork) Date: 2008-01-12 06:07 Message: Logged In: YES user_id=1353850 Originator: YES sysUpTime.0 was just an example! I think check_snmp should only provide performance data on interger values. Just to be sure the performance data ist valid. J?rg ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2008-01-11 16:55 Message: Logged In: YES user_id=375623 Originator: NO This is the expected behavior; chhek_snmp doesn't know anything about TimeTicks Perhaps passing -Ot would help, but it would require different parsing and I don't know how it would affect any the the many special data formats in SNMP. This would be better suited as a feature request. However it would be much easier to just write a local check (run trough nrpe or check_by_ssh) that parse uptime. Also you should keep in mind that the SNMP uptime is the SNMP daemon uptime, not the server uptime (in other words you're ok as long as you don't restart the daemon). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1867716&group_id=29880 From dermoth at aei.ca Wed Mar 31 09:04:43 2010 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Wed, 31 Mar 2010 03:04:43 -0400 Subject: [Nagiosplug-devel] [Fwd: [PATCH] check_snmp: Update last patch to copy value verbatim] Message-ID: <4BB2F40B.5030504@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I re-worked last commit (check_snmp fix) as I realized I didn't need to use the double-conversion; merely taking the pointer diff for string length is enough to get only the strtod-parseable portion of the string. This patch is done against the previous commit (08d8d119) so you can easily compare it with with the last commit in Git. The double-conversion gives more predictable results while copying the value (this patch) ensure backwards-compatibility of anything using perfdata. Any comment? - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFLsvQK6dZ+Kt5BchYRAsRbAKDaGEjbswLVKCoBqUFWdYA8vVP8FgCgycQ9 fUzOOQW8EgBbdxekNa9FwuA= =jxeJ -----END PGP SIGNATURE----- -------------- next part -------------- An embedded message was scrubbed... From: Thomas Guyot-Sionnest Subject: [PATCH] check_snmp: Update last patch to copy value verbatim Date: Wed, 31 Mar 2010 02:59:33 -0400 Size: 3110 URL: From christian.masopust at siemens.com Wed Mar 31 14:34:23 2010 From: christian.masopust at siemens.com (Masopust, Christian) Date: Wed, 31 Mar 2010 14:34:23 +0200 Subject: [Nagiosplug-devel] check_procs (pst3), Solaris 10 and Zones Message-ID: <60721B67EAF0994EAFFB561767B7001404817E9D@nets13ha.ww300.siemens.net> Hi all, as I had the problem that my check_procs in my Solaris 10 global-zone always also counts all processes from other zones, I modified pst3.c the following way (diff is against pst3.c from nagios-plugins 1.4.14): diff -w pst3.c-orig pst3.c 53a54,56 > #ifdef SOLARIS10 > #include > #endif 81a85,87 > #ifdef SOLARIS10 > zoneid_t my_zoneid; > #endif 101a108,115 > #ifdef SOLARIS10 > /* get my zone-id */ > if ((my_zoneid = getzoneid()) == -1) { > fprintf(stderr, "%s: cannot read my zone-id\n"); > exit(1); > } > #endif > 157a172,178 > #ifdef SOLARIS10 > /* process not running in my zone? */ > if (my_zoneid != psinfo.pr_zoneid) { > continue; > } > #endif > this will cause pst3 to output only processes from the zone it is running. (Makefile has to be modified too to define "SOLARIS10" in CFLAGS) maybe that's useful for some others too :-))) christian ___________________________________________________________ Christian Masopust SIEMENS AG SIS SDE SVI CON IPB Tel: +43 (0) 5 1707 26866 E-mail: christian.masopust at siemens.com Addr: Austria, 1210 Vienna, Siemensstra?e 90-92, B. 33, Rm. 243 Leader of the RUGA Firma: Siemens Aktiengesellschaft ?sterreich, Rechtsform: Aktiengesellschaft, Sitz: Wien, Firmenbuchnummer: FN 60562 m, Firmenbuchgericht: Handelsgericht Wien, DVR 0001708 ___________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: