From dag at wieers.com Thu Sep 1 12:45:22 2005 From: dag at wieers.com (Dag Wieers) Date: Thu Sep 1 12:45:22 2005 Subject: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status Message-ID: Hi, We noticed a problem on some systems due to the fact that the process was already exited when issuing spclose() and spclose() didn't check this properly (followed by a non-zero return code, generating a warning). Causing the plugin to variably return: DNS WARNING - nslookup returned error status This seems to be system-dependent (load/kernel scheduler). On RHEL3 we didn't see this, but with RHEL4's 2.6 kernel it happened frequently. I noticed this is also reported on Sourceforge's bugtracker at: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1250191&group_id=29880 where they check if the process has already finished. This would fix similar problems with check_dig and probably other checks, where you get warning messages as well, like: DNS WARNING - 0.008 seconds response time (servername. 600 IN A 1.2.3.4)|time=0.008382s;;;0.000000 This is a pretty urgent bug imo, warranting a new release ? Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] -------------- next part -------------- --- nagios-plugins-1.4.1/plugins/popen.c.orig 2005-08-02 13:44:47.631761141 +0200 +++ nagios-plugins-1.4.1/plugins/popen.c 2005-08-02 13:52:24.589616713 +0200 @@ -221,8 +221,13 @@ return (1); while (waitpid (pid, &status, 0) < 0) + { + if (errno == ECHILD) + return (0); /* Child has already exited */ + if (errno != EINTR) return (1); /* error other than EINTR from waitpid() */ + } if (WIFEXITED (status)) return (WEXITSTATUS (status)); /* return child's termination status */ From noreply at sourceforge.net Fri Sep 2 02:36:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 2 02:36:00 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1280470 ] check_procs cannot detect zombies on AIX Message-ID: Bugs item #1280470, was opened at 2005-09-02 10:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1280470&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Elwell (elwell2000) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs cannot detect zombies on AIX Initial Comment: ./check_procs -s Z -v Not parseable: Z 188558 98382 Not parseable: Z 196776 98382 PROCS OK: 0 processes with STATE = Z should return 2 zombies - AIX lists them as >> ps auxwww | egrep "USER|def" USER PID %CPU %MEM SZ RSS TTY STAT STIME TIME COMMAND root 188558 Z 0:00 root 196776 Z 0:00 >> ps -efal | egrep "UID|def" F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 50005 Z root 188558 98382 0 60 20 0:00 50005 Z root 196776 98382 0 60 20 0:00 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1280470&group_id=29880 From seanius at seanius.net Fri Sep 2 03:55:17 2005 From: seanius at seanius.net (sean finney) Date: Fri Sep 2 03:55:17 2005 Subject: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: References: Message-ID: <20050902105422.GA873@seanius.net> hi dag, On Thu, Sep 01, 2005 at 08:40:33PM +0200, Dag Wieers wrote: > I noticed this is also reported on Sourceforge's bugtracker at: > > https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1250191&group_id=29880 > > where they check if the process has already finished. > > This would fix similar problems with check_dig and probably other checks, > where you get warning messages as well, like: > > DNS WARNING - 0.008 seconds response time (servername. 600 IN A 1.2.3.4)|time=0.008382s;;;0.000000 > > This is a pretty urgent bug imo, warranting a new release ? i'm not sure that annoyance == urgency. we're currently (albeit slowly) in the process of making the popen/spopen calls obsolete by way of a much more safe/efficient/clean architecture, but this particular patch is small and straightforward enough that i'll go ahead and commit it to head and we can decide later whether it warrants a new 1.4 series release. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From seanius at seanius.net Fri Sep 2 03:57:10 2005 From: seanius at seanius.net (sean finney) Date: Fri Sep 2 03:57:10 2005 Subject: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: <20050902105422.GA873@seanius.net> References: <20050902105422.GA873@seanius.net> Message-ID: <20050902105619.GA919@seanius.net> On Fri, Sep 02, 2005 at 06:54:22AM -0400, sean finney wrote: > i'm not sure that annoyance == urgency. we're currently (albeit on second thought, this is really more than just an annoyance.. so we really ought to roll out a newer 1.4 series with this fix. i guess the question then is how soon? sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From noreply at sourceforge.net Fri Sep 2 04:05:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 2 04:05:46 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1250191 ] ECHILD in waitpid (popen.c:spclose) Message-ID: Bugs item #1250191, was opened at 2005-08-02 08:39 Message generated for change (Comment added) made by seanius You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1250191&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Peter Pramberger (peterpramb) >Assigned to: M. Sean Finney (seanius) Summary: ECHILD in waitpid (popen.c:spclose) Initial Comment: After installing Nagios 2.0b3 and plugins 1.4/1.4.1 on a CentOS 4.1 machine (a RedHat ES 4.1 clone, kernel-2.6.9, glibc-2.3.4) I found that the check_dns plugin always aborts with "DNS WARNING - nslookup returned error status" except in the first run. However running it in verbose mode always shows a successful nslookup output. After some debugging I found that the waitpid call in popen.c:spclose() returns a ECHILD, which triggers a failure return value to be passed back to check_dns. Cacthing the ECHILD always produces a reasonable output, so the child with nslookup is really working. >From the (linux) manpage: ECHILD if the process specified in pid does not exist or is not a child of the calling process. (This can happen for one's own child if the action for SIGCHLD is set to SIG_IGN. See also the LINUX NOTES section about threads.) Shouldn't waitpid be successful in reading the exit status of the child? Maybe a bug in glibc? Anyone else seen this? ---------------------------------------------------------------------- >Comment By: M. Sean Finney (seanius) Date: 2005-09-02 07:03 Message: Logged In: YES user_id=226838 ECHLD is returned in this context when the child has already exited, and shouldn't be treated as an error. i'll commit a change to cvs shortly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1250191&group_id=29880 From seanius at seanius.net Fri Sep 2 04:26:26 2005 From: seanius at seanius.net (sean finney) Date: Fri Sep 2 04:26:26 2005 Subject: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: <20050902105619.GA919@seanius.net> References: <20050902105422.GA873@seanius.net> <20050902105619.GA919@seanius.net> Message-ID: <20050902112451.GA1226@seanius.net> now, a question about this patch... the code in question: == while (waitpid (pid, &status, 0) < 0) { if (errno == ECHILD) return (0); /* Child has already exited */ if (errno != EINTR) return (1); /* error other than EINTR from waitpid() */ } if (WIFEXITED (status)) return (WEXITSTATUS (status)); /* return child's termination status */ return (1); == does this remove the check for the child's exit status? sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From dag at wieers.com Fri Sep 2 05:04:10 2005 From: dag at wieers.com (Dag Wieers) Date: Fri Sep 2 05:04:10 2005 Subject: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: <20050902112451.GA1226@seanius.net> References: <20050902105422.GA873@seanius.net> <20050902105619.GA919@seanius.net> <20050902112451.GA1226@seanius.net> Message-ID: On Fri, 2 Sep 2005, sean finney wrote: > now, a question about this patch... > > the code in question: > > == > while (waitpid (pid, &status, 0) < 0) > { > if (errno == ECHILD) > return (0); /* Child has already exited */ > > if (errno != EINTR) > return (1); /* error other than EINTR from waitpid() */ > } > > if (WIFEXITED (status)) > return (WEXITSTATUS (status)); /* return child's termination status */ > > return (1); > == > > does this remove the check for the child's exit status? The patch is not mine, but I think you are correct. It probably should be something like: while (waitpid (pid, &status, 0) < 0) { switch(errno) { case ECHILD: break; /* Child has already exited */ case EINTR: break; /* Interrupted function call */ case default: return 1; } } if (WIFEXITED (status)) return (WEXITSTATUS (status)); /* return child's termination status */ return 1; I add the author (Peter Pramberger) of this patch into the discussion as well. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From ton.voon at altinity.com Fri Sep 2 05:04:13 2005 From: ton.voon at altinity.com (Ton Voon) Date: Fri Sep 2 05:04:13 2005 Subject: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: <20050902112451.GA1226@seanius.net> References: <20050902105422.GA873@seanius.net> <20050902105619.GA919@seanius.net> <20050902112451.GA1226@seanius.net> Message-ID: Sean, I've been investigating this issue this morning and it's getting quite disturbing. My feeling is that this is a red hat problem. My colleague has access to a RHEL4 server (2.6.8 kernel) and gets this problem occasionally too. I can also reproduce the error consistently if I set "signal (SIGCHLD, SIG_IGN)" in check_dns.c. So this appears to happen if a process finishes before the parent issues a waitpid. But in normal behaviour, a process always stays in a zombie state until the waitpid is issued. To answer your specific question below, you therefore cannot get the exit status of the child because it has already been reaped. Searching on the web, it appears there was some patch made around ECHILD errors: http://www.redhat.com/archives/fedora-announce-list/ 2005-January/msg00004.html (search for ECHILD). Dag, I would appreciate if you can confirm if you have this patch and that you still get the errors. I've also found rant about how Redhat have inconsistent behaviour around this area: http://listgateway.unipi.it/pipermail/ntop-dev/2003- April/002625.html. This is interesting to note because ntop also use a secure_popen mechanism to make external calls. I'm going to look through their current code to see if there are any fixes around here. I'm not keen on the patch because it seems to be just ignoring some peculiar behaviour. I think there is more to this problem than meets the eye. Ton On 2 Sep 2005, at 12:24, sean finney wrote: > now, a question about this patch... > > the code in question: > > == > while (waitpid (pid, &status, 0) < 0) > { > if (errno == ECHILD) > return (0); /* Child has > already exited */ > > if (errno != EINTR) > return (1); /* error other than > EINTR from waitpid() */ > } > > if (WIFEXITED (status)) > return (WEXITSTATUS (status)); /* return child's > termination status */ > > return (1); > == > > does this remove the check for the child's exit status? > > > > sean > http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon The contents of this email and any files transmitted with it are confidential and intended solely for the use of the individuals to whom it is addressed. If you are not the intended recipient or have received this e-mail in error please notify the sender and destroy this e-mail immediately. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly prohibited. From tonvoon at mac.com Fri Sep 2 05:04:18 2005 From: tonvoon at mac.com (Ton Voon) Date: Fri Sep 2 05:04:18 2005 Subject: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: <20050902105619.GA919@seanius.net> References: <20050902105422.GA873@seanius.net> <20050902105619.GA919@seanius.net> Message-ID: <5751CBB3-02B7-4D5D-9375-9ACB95FE5970@mac.com> On 2 Sep 2005, at 11:56, sean finney wrote: > On Fri, Sep 02, 2005 at 06:54:22AM -0400, sean finney wrote: > >> i'm not sure that annoyance == urgency. we're currently (albeit >> > > on second thought, this is really more than just an annoyance.. > so we really ought to roll out a newer 1.4 series with this fix. > i guess the question then is how soon? Agreed it needs a release. I think we can issue a 1.4.2 when we get this fixed. Ton -------------- next part -------------- An HTML attachment was scrubbed... URL: From ae at op5.se Fri Sep 2 05:16:30 2005 From: ae at op5.se (Andreas Ericsson) Date: Fri Sep 2 05:16:30 2005 Subject: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: References: <20050902105422.GA873@seanius.net> <20050902105619.GA919@seanius.net> <20050902112451.GA1226@seanius.net> Message-ID: <43184258.7010105@op5.se> Dag Wieers wrote: > On Fri, 2 Sep 2005, sean finney wrote: > > >>now, a question about this patch... >> >>the code in question: >> >>== >> while (waitpid (pid, &status, 0) < 0) >> { >> if (errno == ECHILD) >> return (0); /* Child has already exited */ >> >> if (errno != EINTR) >> return (1); /* error other than EINTR from waitpid() */ >> } >> >> if (WIFEXITED (status)) >> return (WEXITSTATUS (status)); /* return child's termination status */ >> >>> return (1); >> >>== >> >>does this remove the check for the child's exit status? > > > The patch is not mine, but I think you are correct. It probably should be > something like: > > while (waitpid (pid, &status, 0) < 0) { > > switch(errno) { > case ECHILD: break; /* Child has already exited */ This is a never-ending loop. If we get ECHILD once, we'll get it every time. > case EINTR: break; /* Interrupted function call */ > case default: return 1; This is bad, because all commands that exit successfully will return 1 and thus issue a warning. > } > > } > Below this point is never reached. > if (WIFEXITED (status)) > return (WEXITSTATUS (status)); /* return child's termination status */ > > return 1; > I've revamped the runcmd thingie and it's been running stable for a couple of months, so it's ready for implementation. CVS commit access or a couple of hours with Sean and it'll be available for download in a jiffy. A snapshot is already available at http://oss.op5.se/nagios/ although that snapshot has a bug in check_load.c when neither /proc/loadavg or getloadavg() is available (which is inherited from the official distro, but still). -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Lead Developer From dag at wieers.com Fri Sep 2 05:18:11 2005 From: dag at wieers.com (Dag Wieers) Date: Fri Sep 2 05:18:11 2005 Subject: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: References: <20050902105422.GA873@seanius.net> <20050902105619.GA919@seanius.net> <20050902112451.GA1226@seanius.net> Message-ID: On Fri, 2 Sep 2005, Ton Voon wrote: > Searching on the web, it appears there was some patch made around ECHILD > errors: > http://www.redhat.com/archives/fedora-announce-list/2005-January/msg00004.html > (search for ECHILD). Dag, I would appreciate if you can confirm if you have > this patch and that you still get the errors. Peter's patch (that I attached again) fixed the problem for us on all the affected system we saw the problem. All of these were RHEL4 systems. Peter reportedly was running CentOS4. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From seanius at seanius.net Fri Sep 2 06:03:04 2005 From: seanius at seanius.net (sean finney) Date: Fri Sep 2 06:03:04 2005 Subject: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: <43184434.1010000@pramberger.at> References: <20050902105422.GA873@seanius.net> <20050902105619.GA919@seanius.net> <20050902112451.GA1226@seanius.net> <43184434.1010000@pramberger.at> Message-ID: <20050902130153.GA2211@seanius.net> (sending a second copy to the list, the first got caught with too many cc's) On Fri, Sep 02, 2005 at 02:23:16PM +0200, Peter Pramberger wrote: > Please keep in mind that ECHILD is an error condition - there was no process > found to check for. status' value is not defined after the call to waitpid, so > the result of WIFEXITED is unpredictable. yes, this is why simply changing to the switch statement proposed by dag would not work. the question is, how do we get at the status in this case? this is from r'ing tfm for sigaction(2): POSIX.1-1990 disallowed setting the action for SIGCHLD to SIG_IGN. POSIX.1-2001 allows this possibility, so that ignoring SIGCHLD can be used to prevent the creation of zombies (see wait(2)). Nevertheless, the historical BSD and System V behaviours for ignoring SIGCHLD differ, so that the only completely portable method of ensuring that terminated children do not become zombies is to catch the SIGCHLD signal and per- form a wait(2) or similar. so what, redhat is now defaulting to having that set? i think i see a way around this, but i'm not sure: - set a signal handler for SIGCHLD - when SIGCHLD is thrown, we do exactly the opposite from the above, and *not* call any wait functions. i think that should leave the child as a zombie, for our later call to waitpid. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From peter at pramberger.at Fri Sep 2 06:05:23 2005 From: peter at pramberger.at (Peter Pramberger) Date: Fri Sep 2 06:05:23 2005 Subject: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: References: <20050902105422.GA873@seanius.net> <20050902105619.GA919@seanius.net> <20050902112451.GA1226@seanius.net> Message-ID: <43184434.1010000@pramberger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dag Wieers schrieb: > The patch is not mine, but I think you are correct. It probably should be > something like: > > while (waitpid (pid, &status, 0) < 0) { > > switch(errno) { > case ECHILD: break; /* Child has already exited */ > case EINTR: break; /* Interrupted function call */ > case default: return 1; > } > > } > > if (WIFEXITED (status)) > return (WEXITSTATUS (status)); /* return child's termination status */ > > return 1; Please keep in mind that ECHILD is an error condition - there was no process found to check for. status' value is not defined after the call to waitpid, so the result of WIFEXITED is unpredictable. Regards, Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDGEQ0cKsx5K5ighwRAhGLAJ95mMl3d4nZbsbGsxbK5XYx1IDokACeKR+Y PX0uxOcqU6E029dwtfg1RWw= =C1aM -----END PGP SIGNATURE----- From seanius at seanius.net Fri Sep 2 06:05:33 2005 From: seanius at seanius.net (sean finney) Date: Fri Sep 2 06:05:33 2005 Subject: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: <43184434.1010000@pramberger.at> References: <20050902105422.GA873@seanius.net> <20050902105619.GA919@seanius.net> <20050902112451.GA1226@seanius.net> <43184434.1010000@pramberger.at> Message-ID: <20050902124058.GA1858@seanius.net> On Fri, Sep 02, 2005 at 02:23:16PM +0200, Peter Pramberger wrote: > Please keep in mind that ECHILD is an error condition - there was no process > found to check for. status' value is not defined after the call to waitpid, so > the result of WIFEXITED is unpredictable. yes, this is why simply changing to the switch statement proposed by dag would not work. the question is, how do we get at the status in this case? this is from r'ing tfm for sigaction(2): POSIX.1-1990 disallowed setting the action for SIGCHLD to SIG_IGN. POSIX.1-2001 allows this possibility, so that ignoring SIGCHLD can be used to prevent the creation of zombies (see wait(2)). Nevertheless, the historical BSD and System V behaviours for ignoring SIGCHLD differ, so that the only completely portable method of ensuring that terminated children do not become zombies is to catch the SIGCHLD signal and per- form a wait(2) or similar. so what, redhat is now defaulting to having that set? i think i see a way around this, but i'm not sure: - set a signal handler for SIGCHLD - when SIGCHLD is thrown, we do exactly the opposite from the above, and *not* call any wait functions. i think that should leave the child as a zombie, for our later call to waitpid. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ae at op5.se Fri Sep 2 06:46:05 2005 From: ae at op5.se (Andreas Ericsson) Date: Fri Sep 2 06:46:05 2005 Subject: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: <20050902130153.GA2211@seanius.net> References: <20050902105422.GA873@seanius.net> <20050902105619.GA919@seanius.net> <20050902112451.GA1226@seanius.net> <43184434.1010000@pramberger.at> <20050902130153.GA2211@seanius.net> Message-ID: <43185758.9010405@op5.se> sean finney wrote: > (sending a second copy to the list, the first got caught with too many > cc's) > > On Fri, Sep 02, 2005 at 02:23:16PM +0200, Peter Pramberger wrote: > >>Please keep in mind that ECHILD is an error condition - there was no process >>found to check for. status' value is not defined after the call to waitpid, so >>the result of WIFEXITED is unpredictable. > > > yes, this is why simply changing to the switch statement proposed by dag > would not work. the question is, how do we get at the status in this > case? > > this is from r'ing tfm for sigaction(2): > > POSIX.1-1990 disallowed setting the action for SIGCHLD to SIG_IGN. > POSIX.1-2001 allows this possibility, so that ignoring SIGCHLD can be > used to prevent the creation of zombies (see wait(2)). Nevertheless, > the historical BSD and System V behaviours for ignoring SIGCHLD differ, > so that the only completely portable method of ensuring that terminated > children do not become zombies is to catch the SIGCHLD signal and per- > form a wait(2) or similar. > > so what, redhat is now defaulting to having that set? i think i see a > way around this, but i'm not sure: > > - set a signal handler for SIGCHLD > - when SIGCHLD is thrown, we do exactly the opposite from the above, and > *not* call any wait functions. > I wrote a test-program for this. On FC3 with linux-2.6.12-1372 (weird patch-number, I know), when SIGCHLD is explicitly set to SIG_IGN, the children exit immediately and nothing good ever comes of it. When no sighandlers are installed, children hang around for the waitpid(2) call. Setting SIGCHLD to SIG_IGN is the default, according to signal(7) > i think that should leave the child as a zombie, for our later call to > waitpid. > In theory, it should work. In reality, it doesn't (FC3). I'm not sure why yet. If anyone's interested in the test-program (some non-working code is commented out), email me off-list and I'll send it to you. oss.op5.se is currently down, or I'd post it there (some jackass hit a cable with a 4 tonne construction machine). -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Lead Developer From peter at pramberger.at Fri Sep 2 06:53:40 2005 From: peter at pramberger.at (Peter Pramberger) Date: Fri Sep 2 06:53:40 2005 Subject: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: <20050902130153.GA2211@seanius.net> References: <20050902105422.GA873@seanius.net> <20050902105619.GA919@seanius.net> <20050902112451.GA1226@seanius.net> <43184434.1010000@pramberger.at> <20050902130153.GA2211@seanius.net> Message-ID: <431854F0.2020406@pramberger.at> sean finney schrieb: > so what, redhat is now defaulting to having that set? i think i see a > way around this, but i'm not sure: > > - set a signal handler for SIGCHLD > - when SIGCHLD is thrown, we do exactly the opposite from the above, and > *not* call any wait functions. > > i think that should leave the child as a zombie, for our later call to > waitpid. Maybe somehow like this? It's only a rough draft and looks very ugly, but it seems to work. Regards, Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: nagios-plugins-1.4.1-waitpid2.patch Type: text/x-patch Size: 1421 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From tonvoon at mac.com Fri Sep 2 06:53:41 2005 From: tonvoon at mac.com (Ton Voon) Date: Fri Sep 2 06:53:41 2005 Subject: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: <20050902124058.GA1858@seanius.net> References: <20050902105422.GA873@seanius.net> <20050902105619.GA919@seanius.net> <20050902112451.GA1226@seanius.net> <43184434.1010000@pramberger.at> <20050902124058.GA1858@seanius.net> Message-ID: <5A53B227-0F01-4439-9CAA-B20ADED87BBC@mac.com> On 2 Sep 2005, at 13:40, sean finney wrote: > so what, redhat is now defaulting to having that set? i think i see a > way around this, but i'm not sure: > > - set a signal handler for SIGCHLD > - when SIGCHLD is thrown, we do exactly the opposite from the > above, and > *not* call any wait functions. > > i think that should leave the child as a zombie, for our later call to > waitpid. Tried this patch to popen.c: --- popen.c.original 2005-09-02 14:02:33.760495184 +0100 +++ popen.c 2005-09-02 14:30:08.322963456 +0100 @@ -67,6 +67,8 @@ /*extern pid_t *childpid = NULL; *//* ptr to array allocated at run- time */ static int maxfd; / * from our open_max(), {Prog openmax} */ +void sigchld_handler(int signo) { printf( "Caught sigchld\n"); return; } /* Do nothing */ + FILE * spopen (const char *cmdstring) { @@ -171,6 +173,7 @@ if (pipe (pfderr) < 0) return (NULL); /* errno set by pipe() */ + signal(SIGCHLD, &sigchld_handler); if ((pid = fork ()) < 0) return (NULL); /* errno set by fork() */ else if (pid == 0) { /* child */ While this works consistently on debian and MacOSX (with output of: Caught sigchld DNS OK: 0.099 seconds response time altinity.com returns 216.68.81.208|time=0.098571s;;;0.000000 wrapped in a 'while true; do ./check_dns -H altinity.com || break ; done' loop), I still get the occasional error on Red Hat. Amazingly, there is no Caught sigchld for the failing scenario, which I find hard to understand. Any other suggestions from anyone? Ton -------------- next part -------------- An HTML attachment was scrubbed... URL: From srunschke at abit.de Fri Sep 2 08:03:46 2005 From: srunschke at abit.de (srunschke at abit.de) Date: Fri Sep 2 08:03:46 2005 Subject: Antwort: Re: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: <20050902105422.GA873@seanius.net> Message-ID: nagiosplug-devel-admin at lists.sourceforge.net schrieb am 02.09.2005 12:54:22: > i'm not sure that annoyance == urgency. we're currently (albeit > slowly) in the process of making the popen/spopen calls obsolete > by way of a much more safe/efficient/clean architecture, but this > particular patch is small and straightforward enough that i'll go ahead > and commit it to head and we can decide later whether it warrants a new > 1.4 series release. Does that mean I can relay my boss to you next time he comes to me screaming like "WTF IS THIS SHIT?! I am getting like 10 mails every 5 minutes on my Blackberry saying our DNS is WARNING! Do we have a problem? If not, get me rid of those mails. NOW!" ;-) I am monitoring our 10 DNS Servers and now you go figure how much mail those produce... Since I was unable to stop them, I had to disable mail on WARNING states for DNS - which is NOT a good solution by itself. Btw, those messages started popping up after upgrading to new state-of-the-art hardware and RHES4. regards sash -------------------------------------------------- Sascha Runschke Netzwerk Administration IT-Services ABIT AG Robert-Bosch-Str. 1 40668 Meerbusch Tel.:+49 (0) 2150.9153.226 Mobil:+49 (0) 173.5419665 mailto:SRunschke at abit.de http://www.abit.net http://www.abit-epos.net --------------------------------- Sicherheitshinweis zur E-Mail Kommunikation / Security note regarding email communication: http://www.abit.net/sicherheitshinweis.html From srunschke at abit.de Fri Sep 2 08:09:39 2005 From: srunschke at abit.de (srunschke at abit.de) Date: Fri Sep 2 08:09:39 2005 Subject: Antwort: Re: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: <43185758.9010405@op5.se> Message-ID: nagiosplug-devel-admin at lists.sourceforge.net schrieb am 02.09.2005 15:44:56: > In theory, it should work. In reality, it doesn't (FC3). I'm not sure > why yet. > > If anyone's interested in the test-program (some non-working code is > commented out), email me off-list and I'll send it to you. oss.op5.se is > currently down, or I'd post it there (some jackass hit a cable with a 4 > tonne construction machine). If it is of any help, I would like to offer to escalate this issue to the RedHat Support. Since we have a dozen support subscribtions for RH Enterprise, I can easily create a ticket and let them solve it for us ;-) I just need some technical description of the problem so that someone not into Nagios would be able to understand it. I'm not sure I could word it properly myself. regards sash -------------------------------------------------- Sascha Runschke Netzwerk Administration IT-Services ABIT AG Robert-Bosch-Str. 1 40668 Meerbusch Tel.:+49 (0) 2150.9153.226 Mobil:+49 (0) 173.5419665 mailto:SRunschke at abit.de http://www.abit.net http://www.abit-epos.net --------------------------------- Sicherheitshinweis zur E-Mail Kommunikation / Security note regarding email communication: http://www.abit.net/sicherheitshinweis.html From ton.voon at altinity.com Fri Sep 2 09:17:23 2005 From: ton.voon at altinity.com (Ton Voon) Date: Fri Sep 2 09:17:23 2005 Subject: Antwort: Re: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: References: Message-ID: <74858C96-F609-4778-901C-518178136F47@altinity.com> On 2 Sep 2005, at 16:02, srunschke at abit.de wrote: > nagiosplug-devel-admin at lists.sourceforge.net schrieb am 02.09.2005 > 12:54:22: > > >> i'm not sure that annoyance == urgency. we're currently (albeit >> slowly) in the process of making the popen/spopen calls obsolete >> by way of a much more safe/efficient/clean architecture, but this >> particular patch is small and straightforward enough that i'll go >> ahead >> and commit it to head and we can decide later whether it warrants >> a new >> 1.4 series release. >> > > Does that mean I can relay my boss to you next time he comes to > me screaming like "WTF IS THIS SHIT?! I am getting like 10 mails > every 5 minutes on my Blackberry saying our DNS is WARNING! > Do we have a problem? If not, get me rid of those mails. NOW!" > > ;-) > > I am monitoring our 10 DNS Servers and now you go figure how > much mail those produce... Since I was unable to stop them, I > had to disable mail on WARNING states for DNS - which is NOT > a good solution by itself. > > Btw, those messages started popping up after upgrading to new > state-of-the-art hardware and RHES4. > I agree this is not a good state of affairs, which is why I am prepared to create a new release when we have a good fix for this. Peter Pramberger has provided a 2nd patch which I can test from Monday and Sean Finney and Andreas Ericsson are looking into it too through their new routines for running external commands. This definitely looks like a change that Redhat have made to their kernel (confirmed by your server upgrade), so it was really outside of our hands. I'm surprised we haven't had more complaints about this because it must affect every external call.... Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon The contents of this email and any files transmitted with it are confidential and intended solely for the use of the individuals to whom it is addressed. If you are not the intended recipient or have received this e-mail in error please notify the sender and destroy this e-mail immediately. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly prohibited. From sghosh at sghosh.org Fri Sep 2 20:44:06 2005 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Fri Sep 2 20:44:06 2005 Subject: Antwort: Re: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: <74858C96-F609-4778-901C-518178136F47@altinity.com> References: <74858C96-F609-4778-901C-518178136F47@altinity.com> Message-ID: Seems to be some conflict going on in the kernel level... http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.13 http://www.linux-mips.org/archives/linux-cvs-patches/2005-08/msg00022.html http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;h=1b5ef3e96c7161fad6a8c2c41a927e5d795ee2fa;hp=793c77c6ef9c5353432126b2e545bf6ad9f07799;hb=98fdffccea6cc3fe9dba32c0fcc310bcb5d71529;f=arch/um/kernel/process.c -- -sg From ton.voon at altinity.com Mon Sep 5 03:40:15 2005 From: ton.voon at altinity.com (Ton Voon) Date: Mon Sep 5 03:40:15 2005 Subject: Antwort: Re: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: References: Message-ID: <2892C657-9D7B-4859-B433-3FC0C2C20BCB@altinity.com> On 2 Sep 2005, at 16:08, srunschke at abit.de wrote: > If it is of any help, I would like to offer to escalate this issue > to the RedHat Support. Since we have a dozen support subscribtions > for RH Enterprise, I can easily create a ticket and let them solve > it for us ;-) > I just need some technical description of the problem so that > someone not into Nagios would be able to understand it. I'm not > sure I could word it properly myself. Sascha, I would like to take you up on this offer. I've managed to reduce the test case down to the included tar file, so there are no nagios plugins involved. Instructions are: gunzip and untar and cd make ./run_tests 10 On my RHEL4 server (Red Hat Enterprise Linux version 4 Update 1, 2.6.9-11.EL) , this will fail anywhere between 40% to 70% of the time. Running the same on MacOS10.4.1 and Debian 3.1 gives me 100% success. In child_test.c, you can amend the command that is executed. These were the results I got (after 100 runs): - /bin/date 100% - /bin/cat /etc/hosts 100% - /usr/bin/dig redhat.com 69% - /bin/sleep 1 100% - /usr/bin/nslookup redhat.com 90% (after 100 runs), 40% (after 10 runs) - /bin/ping -c 1 localhost 100% - /bin/ping -c 1 192.168.10.32 100% So it looks like only DNS resolution stuff is causing problems. Using Peter's trick of waiting for childtermd to be set by the SIGCHLD handler (commented in child_test.c) changes it to 100% success at all times. Definitely looks like a Redhat problem. Can you escalate to them. I think a technical summary could be: "wait() sometimes fails if child executes nslookup/dig command". I'm happy for you to contact me if you need more information. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon The contents of this email and any files transmitted with it are confidential and intended solely for the use of the individuals to whom it is addressed. If you are not the intended recipient or have received this e-mail in error please notify the sender and destroy this e-mail immediately. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly prohibited. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rhel4_child.tar.gz Type: application/x-gzip Size: 1474 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonvoon at mac.com Mon Sep 5 03:51:11 2005 From: tonvoon at mac.com (Ton Voon) Date: Mon Sep 5 03:51:11 2005 Subject: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: <431854F0.2020406@pramberger.at> References: <20050902105422.GA873@seanius.net> <20050902105619.GA919@seanius.net> <20050902112451.GA1226@seanius.net> <43184434.1010000@pramberger.at> <20050902130153.GA2211@seanius.net> <431854F0.2020406@pramberger.at> Message-ID: <89789F8C-9CA5-4723-9603-DAE31A680D1E@mac.com> On 2 Sep 2005, at 14:34, Peter Pramberger wrote: > sean finney schrieb: > >> so what, redhat is now defaulting to having that set? i think i >> see a >> way around this, but i'm not sure: >> >> - set a signal handler for SIGCHLD >> - when SIGCHLD is thrown, we do exactly the opposite from the >> above, and >> *not* call any wait functions. >> >> i think that should leave the child as a zombie, for our later >> call to >> waitpid. >> > > Maybe somehow like this? It's only a rough draft and looks very > ugly, but it > seems to work. > > > Regards, > Peter > > --- nagios-plugins-1.4.1/plugins/popen.c.orig 2005-09-02 > 15:06:55.929161410 +0200 > +++ nagios-plugins-1.4.1/plugins/popen.c 2005-09-02 > 15:26:13.632795170 +0200 > @@ -31,6 +31,7 @@ > FILE *spopen (const char *); > int spclose (FILE *); > RETSIGTYPE popen_timeout_alarm_handler (int); > +RETSIGTYPE popen_sigchld_handler (int); > > #include /* ANSI C header > file */ > #include > @@ -66,6 +67,7 @@ > /*int *childerr = NULL;*//* ptr to array allocated at run-time */ > /*extern pid_t *childpid = NULL; *//* ptr to array allocated at > run-time */ > static int maxfd; /* from our > open_max(), {Prog openmax} */ > +static volatile int childtermd = 0; > > FILE * > spopen (const char *cmdstring) > @@ -86,6 +88,9 @@ > limit.rlim_cur = 0; > setrlimit (RLIMIT_CORE, &limit); > #endif > + if (signal (SIGCHLD, popen_sigchld_handler) == SIG_ERR) { > + usage4 (_("Cannot catch SIGCHLD")); > + } > > env[0] = strdup("LC_ALL=C"); > env[1] = '\0'; > @@ -220,11 +225,10 @@ > if (fclose (fp) == EOF) > return (1); > > + while (!childtermd); /* wait > until SIGCHLD */ > + > while (waitpid (pid, &status, 0) < 0) > { > - if (errno == ECHILD) > - return (0); /* Child has > already exited */ > - > if (errno != EINTR) > return (1); /* error other > than EINTR from waitpid() */ > } > @@ -260,6 +264,13 @@ > } > } > > +void > +popen_sigchld_handler (int signo) > +{ > + if (signo == SIGCHLD) > + childtermd = 1; > +} > + > > int > open_max (void) > Peter, Thanks, this patch seems to work fine. I want to see what Red Hat have to say about the issue first (since Sascha will raise it with them). If they haven't come back within a week, we can put this patch in. Ton From ae at op5.se Mon Sep 5 04:10:35 2005 From: ae at op5.se (Andreas Ericsson) Date: Mon Sep 5 04:10:35 2005 Subject: Antwort: Re: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: <2892C657-9D7B-4859-B433-3FC0C2C20BCB@altinity.com> References: <2892C657-9D7B-4859-B433-3FC0C2C20BCB@altinity.com> Message-ID: <431C2744.6090904@op5.se> Ton Voon wrote: > On 2 Sep 2005, at 16:08, srunschke at abit.de wrote: > >> If it is of any help, I would like to offer to escalate this issue >> to the RedHat Support. Since we have a dozen support subscribtions >> for RH Enterprise, I can easily create a ticket and let them solve >> it for us ;-) >> I just need some technical description of the problem so that >> someone not into Nagios would be able to understand it. I'm not >> sure I could word it properly myself. > > > Sascha, > > I would like to take you up on this offer. > > I've managed to reduce the test case down to the included tar file, so there are > no nagios plugins involved. Instructions are: > > gunzip and untar and cd > make > ./run_tests 10 > > On my RHEL4 server (Red Hat Enterprise Linux version 4 Update 1, 2.6.9-11.EL) , > this will fail anywhere between 40% to 70% of the time. Running the same on > MacOS10.4.1 and Debian 3.1 gives me 100% success. > > In child_test.c, you can amend the command that is executed. These were the > results I got (after 100 runs): > > - /bin/date 100% > - /bin/cat /etc/hosts 100% > - /usr/bin/dig redhat.com 69% > - /bin/sleep 1 100% > - /usr/bin/nslookup redhat.com 90% (after 100 runs), 40% (after 10 runs) > - /bin/ping -c 1 localhost 100% > - /bin/ping -c 1 192.168.10.32 100% > > So it looks like only DNS resolution stuff is causing problems. Using Peter's > trick of waiting for childtermd to be set by the SIGCHLD handler (commented in > child_test.c) changes it to 100% success at all times. > > Definitely looks like a Redhat problem. Can you escalate to them. I think a > technical summary could be: "wait() sometimes fails if child executes > nslookup/dig command". > More likely, it fails if the child sets any of its filedescriptors to non-blocking (including sockets). I remember seeing something about that somewhere. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Lead Developer From peter at pramberger.at Mon Sep 5 05:26:29 2005 From: peter at pramberger.at (Peter Pramberger) Date: Mon Sep 5 05:26:29 2005 Subject: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: <89789F8C-9CA5-4723-9603-DAE31A680D1E@mac.com> References: <20050902105422.GA873@seanius.net> <20050902105619.GA919@seanius.net> <20050902112451.GA1226@seanius.net> <43184434.1010000@pramberger.at> <20050902130153.GA2211@seanius.net> <431854F0.2020406@pramberger.at> <89789F8C-9CA5-4723-9603-DAE31A680D1E@mac.com> Message-ID: <431C37EF.6070706@pramberger.at> Ton Voon schrieb: > > Peter, > > Thanks, this patch seems to work fine. I want to see what Red Hat have > to say about the issue first (since Sascha will raise it with them). If > they haven't come back within a week, we can put this patch in. Well, if not here is a cleaned up version of the patch. Hopefully noone will write a plugin which has to fork its own child's ... Regards, Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: nagios-plugins-1.4.1-waitpid2b.patch Type: text/x-patch Size: 1596 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From srunschke at abit.de Mon Sep 5 06:44:21 2005 From: srunschke at abit.de (srunschke at abit.de) Date: Mon Sep 5 06:44:21 2005 Subject: Antwort: Re: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: <2892C657-9D7B-4859-B433-3FC0C2C20BCB@altinity.com> Message-ID: nagiosplug-devel-admin at lists.sourceforge.net schrieb am 05.09.2005 12:38:00: > On my RHEL4 server (Red Hat Enterprise Linux version 4 Update 1, 2. > 6.9-11.EL) , this will fail anywhere between 40% to 70% of the time. > Running the same on MacOS10.4.1 and Debian 3.1 gives me 100% success. I have tried your testsuite, but the results are a bit unexpected. I only have around 2-5% failure reports. Often I even have 0% failures. Sometimes I run 5 consecutive ./run_test 1000 and get 5 100% ok returned. I either get 0 failures or 2-5%, never anything else. > So it looks like only DNS resolution stuff is causing problems. > Using Peter's trick of waiting for childtermd to be set by the > SIGCHLD handler (commented in child_test.c) changes it to 100% > success at all times. If I activate the while, I always get 0% failure. > Definitely looks like a Redhat problem. Can you escalate to them. I > think a technical summary could be: "wait() sometimes fails if child > executes nslookup/dig command". > > I'm happy for you to contact me if you need more information. I would love to see if you could tweak the test a bit more to generate a higher percentage of errors, just like check_dig does for me. I'm not sure if RH will be impressed by those few errors. I'm going to escalate it now anyways. regards sash -------------------------------------------------- Sascha Runschke Netzwerk Administration IT-Services ABIT AG Robert-Bosch-Str. 1 40668 Meerbusch Tel.:+49 (0) 2150.9153.226 Mobil:+49 (0) 173.5419665 mailto:SRunschke at abit.de http://www.abit.net http://www.abit-epos.net --------------------------------- Sicherheitshinweis zur E-Mail Kommunikation / Security note regarding email communication: http://www.abit.net/sicherheitshinweis.html From noreply at sourceforge.net Mon Sep 5 09:28:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 5 09:28:32 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1250191 ] ECHILD in waitpid (popen.c:spclose) Message-ID: Bugs item #1250191, was opened at 2005-08-02 13:39 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1250191&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Peter Pramberger (peterpramb) >Assigned to: Ton Voon (tonvoon) Summary: ECHILD in waitpid (popen.c:spclose) Initial Comment: After installing Nagios 2.0b3 and plugins 1.4/1.4.1 on a CentOS 4.1 machine (a RedHat ES 4.1 clone, kernel-2.6.9, glibc-2.3.4) I found that the check_dns plugin always aborts with "DNS WARNING - nslookup returned error status" except in the first run. However running it in verbose mode always shows a successful nslookup output. After some debugging I found that the waitpid call in popen.c:spclose() returns a ECHILD, which triggers a failure return value to be passed back to check_dns. Cacthing the ECHILD always produces a reasonable output, so the child with nslookup is really working. >From the (linux) manpage: ECHILD if the process specified in pid does not exist or is not a child of the calling process. (This can happen for one's own child if the action for SIGCHLD is set to SIG_IGN. See also the LINUX NOTES section about threads.) Shouldn't waitpid be successful in reading the exit status of the child? Maybe a bug in glibc? Anyone else seen this? ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2005-09-05 17:27 Message: Logged In: YES user_id=664364 Agreed with Sean to take over this call. Have created a testcase. Sascha Runschke is raising this to Red Hat. New patch from Peter Pramberger attached. Depending on reply from Red Hat, will apply patch next week. Ton ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-02 12:03 Message: Logged In: YES user_id=226838 ECHLD is returned in this context when the child has already exited, and shouldn't be treated as an error. i'll commit a change to cvs shortly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1250191&group_id=29880 From srunschke at abit.de Tue Sep 6 06:38:07 2005 From: srunschke at abit.de (srunschke at abit.de) Date: Tue Sep 6 06:38:07 2005 Subject: [Nagiosplug-devel] dig/nslookup wait() problems - RedHat support responses # Part 1 Message-ID: Got the first response today: > Can you please provide a sysreport of the system. This can be generated by > running the command sysreport as root. This contains useful information > which may be required by the engineer handling this escalation. > > From tests, it appears that the problem affects 2.6.9-11 kernels. > It seems to work fine with the 2.6.9-5 kernel. Can you try recreating > this on a 2.6.9-5 kernel if you are using a 2.6.9-11 kernel. I don't know why I should try it on a 2.6.9-5 machine now if they already found out that the older kernel is not affected... I launched a freshly installed RHES4 in a VMWare session and the child_test runs absolutely smooth in there - as expected considering what the support said. So hang on what he'll be telling me after studying my sysreport ;) regards sash -------------------------------------------------- Sascha Runschke Netzwerk Administration IT-Services ABIT AG Robert-Bosch-Str. 1 40668 Meerbusch Tel.:+49 (0) 2150.9153.226 Mobil:+49 (0) 173.5419665 mailto:SRunschke at abit.de http://www.abit.net http://www.abit-epos.net --------------------------------- Sicherheitshinweis zur E-Mail Kommunikation / Security note regarding email communication: http://www.abit.net/sicherheitshinweis.html From noreply at sourceforge.net Tue Sep 6 08:59:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 6 08:59:03 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1283131 ] check_load gives incorrect data on AIX Message-ID: Bugs item #1283131, was opened at 2005-09-06 16:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1283131&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 Submitted By: Andrew Elwell (elwell2000) Assigned to: Nobody/Anonymous (nobody) Summary: check_load gives incorrect data on AIX Initial Comment: compare output from check_load to that of "uptime" - they do not match and I'm seeing stupidly high (eg 30000) loads from the nagios plugin intermittently /usr/local/nagios/libexec/check_load -w 15,10,5 -c 30,25,20 ; uptime OK - load average: 0.01, 0.01, 0.24|load1=0.013;15.000;30.000;0; load5=0.012;10.000;25.000;0; load15=0.235;5.000;20.000;0; 04:48PM up 1 day, 5:55, 31 users, load average: 1.09, 1.07, 1.61 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1283131&group_id=29880 From gh at 3gupload.com Tue Sep 6 15:56:06 2005 From: gh at 3gupload.com (Garrett Honeycutt) Date: Tue Sep 6 15:56:06 2005 Subject: [Nagiosplug-devel] testing accounts Message-ID: <1126047297.7589.61.camel@gspot.internal.3gupload.com> I wrote check_mem to monitor memory usage of linux systems and would like to make it portable to other systems to enhance its usability. I am also working on a plugin to return lots of performance data from nfsstat for trend analysis and could use some more OS's for testing. I would greatly appreciate it anyone could give me an account on a machine with an OS of Solaris, AIX, HP-UX, True64, NetBSD, or FreeBSD. If you can provide me with an account, please email me off list. Thanks, -g -- // Garrett Honeycutt // Sr. Systems Administrator // 3GUpload.com, Inc. // 317.472.4969 Office From ae at op5.se Wed Sep 7 01:19:07 2005 From: ae at op5.se (Andreas Ericsson) Date: Wed Sep 7 01:19:07 2005 Subject: [Nagiosplug-devel] testing accounts In-Reply-To: <1126047297.7589.61.camel@gspot.internal.3gupload.com> References: <1126047297.7589.61.camel@gspot.internal.3gupload.com> Message-ID: <431EA238.40305@op5.se> Garrett Honeycutt wrote: > I wrote check_mem to monitor memory usage of linux systems and would > like to make it portable to other systems to enhance its usability. How did you write it? If it's written in perl, it's not portable enough (many old or stripped down systems don't have perl). If it's written in shell, it must only use commands specified in the SUS and POSIX to be portable, and must only use command-syntax required to be implemented in POSIX. If you've written it in C, you can use the sysinfo(2) system call on linux, but that's linux-specific. Using sysconf(3) where _SC_PHYSPAGES and _SC_PAGESIZE or _SC_PAGE_SIZE and _SC_AVPHYS_PAGES are defined should work. That way you can simply write an #ifdef fallthrough for non-supported systems (making the plugins build cleanly), and one can simply add #ifdef sections for systems as required/researched. Most systems have some mechanism similar to the sysinfo(2) call on linux. > I am > also working on a plugin to return lots of performance data from nfsstat > for trend analysis and could use some more OS's for testing. I would > greatly appreciate it anyone could give me an account on a machine with > an OS of Solaris, AIX, HP-UX, True64, NetBSD, or FreeBSD. If you can > provide me with an account, please email me off list. > http://www.testdrive.hp.com Sign up, sign in, do the testing. They have all of the above, except Solaris, and it's free. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Lead Developer From ton.voon at altinity.com Wed Sep 7 01:43:04 2005 From: ton.voon at altinity.com (Ton Voon) Date: Wed Sep 7 01:43:04 2005 Subject: [Nagiosplug-devel] testing accounts In-Reply-To: <431EA238.40305@op5.se> References: <1126047297.7589.61.camel@gspot.internal.3gupload.com> <431EA238.40305@op5.se> Message-ID: On 7 Sep 2005, at 09:18, Andreas Ericsson wrote: > Garrett Honeycutt wrote: > >> I wrote check_mem to monitor memory usage of linux systems and would >> like to make it portable to other systems to enhance its usability. >> > > > How did you write it? If it's written in perl, it's not portable > enough (many old or stripped down systems don't have perl). I don't have an issue with perl. All current distributions of Unix include perl and it saves lots of crazy programming, so I am not going to dismiss an enhancement just because of the requirement of perl. >> I am >> also working on a plugin to return lots of performance data from >> nfsstat >> for trend analysis and could use some more OS's for testing. I would >> greatly appreciate it anyone could give me an account on a machine >> with >> an OS of Solaris, AIX, HP-UX, True64, NetBSD, or FreeBSD. If you can >> provide me with an account, please email me off list. >> > > http://www.testdrive.hp.com > Sign up, sign in, do the testing. They have all of the above, > except Solaris, and it's free. That is useful to know. Thanks. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon The contents of this email and any files transmitted with it are confidential and intended solely for the use of the individuals to whom it is addressed. If you are not the intended recipient or have received this e-mail in error please notify the sender and destroy this e-mail immediately. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly prohibited. From ae at op5.se Wed Sep 7 02:06:16 2005 From: ae at op5.se (Andreas Ericsson) Date: Wed Sep 7 02:06:16 2005 Subject: [Nagiosplug-devel] testing accounts In-Reply-To: References: <1126047297.7589.61.camel@gspot.internal.3gupload.com> <431EA238.40305@op5.se> Message-ID: <431EAD6F.1070703@op5.se> Ton Voon wrote: > > On 7 Sep 2005, at 09:18, Andreas Ericsson wrote: > >> Garrett Honeycutt wrote: >> >>> I wrote check_mem to monitor memory usage of linux systems and would >>> like to make it portable to other systems to enhance its usability. >>> >> >> >> How did you write it? If it's written in perl, it's not portable >> enough (many old or stripped down systems don't have perl). > > > I don't have an issue with perl. All current distributions of Unix > include perl and it saves lots of crazy programming, so I am not going > to dismiss an enhancement just because of the requirement of perl. > That's fine for the networking plugins that run off the Nagios server. The local ones should be written in C or shell, since they are bound to run on a plethora of ancient or embedded systems where glazing such as perl isn't available. If you sift through the current distro you'll find that this is already the case. The only exception is check_file_age.pl, which could be rewritten in C with just under 30 lines of code (35 if you want error-checking). -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Lead Developer From noreply at sourceforge.net Wed Sep 7 16:20:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 7 16:20:04 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1284352 ] check_dhcp -s not compatible with helpers/relays Message-ID: Bugs item #1284352, was opened at 2005-09-07 16:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1284352&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 Submitted By: Greg Connor (nekodojo) Assigned to: Nobody/Anonymous (nobody) Summary: check_dhcp -s not compatible with helpers/relays Initial Comment: check_dhcp -s is supposed to verify that a response is received from a certain server (or servers). But, when used with a dhcp relay agent (or an iphelper in Cisco speak) the offer appears to come from the relay, not the actual server which answered. When the plugin is used with $HOSTADDRESS$ to target a particular server, the reply comes from the relay/forwarder and not from the dhcp server, so the status will show an error even if the DHCP server we want to test is up. This can be worked around by testing the relays with -s instead of the ip of the dhcp server. However, if there are multiple servers to be monitored and they are not on the same network as the nagios server. In that case, the plugin will always report at least one answer from each relay and the plugin can't tell if all the dhcp servers are working. The expected behavior is to use the IP from "siaddr" if it is non-zero, which would indicate that the reply was forwarded on behalf of a remote DHCP server. (see diff for a suggested fix) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1284352&group_id=29880 From khan at khan.org Thu Sep 8 03:25:05 2005 From: khan at khan.org (Khan Klatt) Date: Thu Sep 8 03:25:05 2005 Subject: [Nagiosplug-devel] Problem compiling check_snmp.c on Solaris 8 [with fix?] Message-ID: <30A4A13F-63D9-4FEB-8766-E436116A62E9@khan.org> First, forgive me if I'm not following proper conventions, this is my first contribution to an open source project, and I am not a C coder (outside of the odd hello_world.c)... After struggling to get check_snmp to compile (all the other plugins compiled fine), I browsed the CVS tree, and got version 1.53 to compile "out of the box". It looks like the performance data enhancement in 1.54 caused the compile on Solaris 8 to break (SunOS ephemeral 5.8 Generic_108528-17 sun4u sparc SUNW,UltraSPARC-IIi- cEngine). Specifically, this is the error I was getting after "./configure" and "make": # make check_snmp source='check_snmp.c' object='check_snmp.o' libtool=no \ depfile='.deps/check_snmp.Po' tmpdepfile='.deps/check_snmp.TPo' \ depmode=gcc /bin/bash ../depcomp \ gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H - I. -I. -I.. -I.. -I../lib -I../intl -I/usr/local/ssl/include -g - O2 -c check_snmp.c check_snmp.c: In function `main': check_snmp.c:341: parse error before `char' check_snmp.c:342: `str' undeclared (first use in this function) check_snmp.c:342: (Each undeclared identifier is reported only once check_snmp.c:342: for each function it appears in.) make: *** [check_snmp.o] Error 1 After doing a bit of research on C tutorials, I came across this: http://crasseux.com/books/ctutorial/...undeclared--first-use-in-this- function-.html Which indicated that perhaps the string pointer (?) definition should be done outside of main{} After making this "fix", it compiled cleanly: # make check_snmp source='check_snmp.c' object='check_snmp.o' libtool=no \ depfile='.deps/check_snmp.Po' tmpdepfile='.deps/check_snmp.TPo' \ depmode=gcc /bin/bash ../depcomp \ gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H - I. -I. -I.. -I.. -I../lib -I../intl -I/usr/local/ssl/include -g - O2 -c check_snmp.c source='utils.c' object='utils.o' libtool=no \ depfile='.deps/utils.Po' tmpdepfile='.deps/utils.TPo' \ depmode=gcc /bin/bash ../depcomp \ gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H - I. -I. -I.. -I.. -I../lib -I../intl -I/usr/local/ssl/include -g - O2 -c utils.c source='popen.c' object='popen.o' libtool=no \ depfile='.deps/popen.Po' tmpdepfile='.deps/popen.TPo' \ depmode=gcc /bin/bash ../depcomp \ gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H - I. -I. -I.. -I.. -I../lib -I../intl -I/usr/local/ssl/include -g - O2 -c popen.c gcc -g -O2 -ldl -L. -R/usr/local/ssl/lib -L/usr/local/ssl/lib -o check_snmp check_snmp.o utils.o ../lib/libnagiosplug.a ../lib/ libcoreutils.a popen.o ../intl/libintl.a -lgen -lsocket -I/usr/ local/ssl/include If my fix is appropriate (i.e. doesn't break other builds), please consider applying the patch so that Solaris users will have more seamless installs out of the box. Patch diff below (basically moved line 341 -> 105) Thanks, and constructive criticism welcomed... (If I look like I know what I'm doing, it's largely coincidental) -K ----------------- # diff -C0 * *** check_snmp.c_1.57 Thu Sep 8 03:05:03 2005 --- check_snmp.c_1.58 Thu Sep 8 03:05:43 2005 *************** *** 104 **** --- 105 ---- + char *str[MAX_INPUT_BUFFER]; *************** *** 341 **** - char *str[MAX_INPUT_BUFFER]; --- 341 ---- From noreply at sourceforge.net Thu Sep 8 10:58:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 8 10:58:06 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1285165 ] changed output to match dev guidelines Message-ID: Patches item #1285165, was opened at 2005-09-08 12:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1285165&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Submitted By: monkeymanorg (monkeymanorg) Assigned to: Nobody/Anonymous (nobody) Summary: changed output to match dev guidelines Initial Comment: Trivial patch for standardization. Changed the plugin to conform to the developer guideline of "METRIC STATUS: Information text" in the one line output of the plugin. Also removed the #defines for the status codes. UNKNOWN was set to -1 instead of 3 and they are already included from common.h. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1285165&group_id=29880 From gh at 3gupload.com Thu Sep 8 11:03:12 2005 From: gh at 3gupload.com (Garrett Honeycutt) Date: Thu Sep 8 11:03:12 2005 Subject: [Nagiosplug-devel] re: Patch 1285165 Message-ID: <1126202528.20235.10.camel@gspot.internal.3gupload.com> This patch is for check_dhcp. Sorry the patch submission was not clear on that. -g -- // Garrett Honeycutt // Sr. Systems Administrator // 3GUpload.com, Inc. // 317.472.4969 Office From aivaturi2 at unlnotes.unl.edu Thu Sep 8 14:08:17 2005 From: aivaturi2 at unlnotes.unl.edu (Aditya Ivaturi) Date: Thu Sep 8 14:08:17 2005 Subject: [Nagiosplug-devel] plugin help Message-ID: This is the first time I am trying to write a plugin for Nagios. So please bear with me. We have an online testing system and I am writing a plugin to check how many users are actually taking a test. It is a module that is in built in the system and exported via http. So all I do is call that page and dump the number out. Nothing complicated. The code-block (perl) which dumps out is as follows: if ($content =~ m/Student Cache<\/TD>(\d*)<\/TD>/) { if ($1>$critical) { if ($verbose) { print "CRITICAL: $1 Users Online > $critical Critical Status \t Critical ErrorLev 2 | UsersOnline=$1;0;0;\n"; } else { print "CRITICAL: $1 Users Online | UsersOnline=$1;0;0;\n"; } exit $ERRORS{'CRITICAL'}; } elsif ($1>$warning) { if ($verbose) { print "WARNING: $1 # Users Online > $warning Warning Status \t Critical ErrorLev 1 | UsersOnline=$1;0;0;\n"; } else { print "WARNING: $1 Users Online | UsersOnline=$1;0;0;\n";}; exit $ERRORS{'WARNING'}; } else { if ($verbose) { print "OK: $1 Users Online - Status normal \t Normal ErrorLev 0 | UsersOnline=$1;0;0;\n"; } else { print "OK: $1 Users Online | UsersOnline=$1;0;0;\n"; } exit $ERRORS{'OK'}; } } For e.g the output will look like: OK: 12 Users Online | UsersOnline=12;0;0; where -w is 150 and -c is 200. But nagios complains by saying "NRPE: Unable to read output". Is the format of the output wrong or am I missing any steps? --Turi -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lynne.G.Lawrence at uscg.mil Fri Sep 9 06:46:09 2005 From: Lynne.G.Lawrence at uscg.mil (Lawrence, Lynne) Date: Fri Sep 9 06:46:09 2005 Subject: [Nagiosplug-devel] plugin help Message-ID: <8E90177DEBE3CA4EB5E3114D3C03E16941FC2E@OSC-EXMB-M-001.main.ads.uscg.mil> Perhaps your initial if statement is failing? I suggest that you add an else{} clause to the initial if{} regex match; put out some message and exit $ERRORS{UNKNOWN} for no match. Other than that, maybe check the file permissions to ensure that it is executable by the nagios user. Hope this helps, Lynne Lawrence QSS/USCG ________________________________ From: nagiosplug-devel-admin at lists.sourceforge.net [mailto:nagiosplug-devel-admin at lists.sourceforge.net] On Behalf Of Aditya Ivaturi Sent: Thursday, September 08, 2005 5:08 PM To: nagiosplug-devel at lists.sourceforge.net Subject: [Nagiosplug-devel] plugin help This is the first time I am trying to write a plugin for Nagios. So please bear with me. We have an online testing system and I am writing a plugin to check how many users are actually taking a test. It is a module that is in built in the system and exported via http. So all I do is call that page and dump the number out. Nothing complicated. The code-block (perl) which dumps out is as follows: if ($content =~ m/Student Cache<\/TD>(\d*)<\/TD>/) { if ($1>$critical) { if ($verbose) { print "CRITICAL: $1 Users Online > $critical Critical Status \t Critical ErrorLev 2 | UsersOnline=$1;0;0;\n"; } else { print "CRITICAL: $1 Users Online | UsersOnline=$1;0;0;\n"; } exit $ERRORS{'CRITICAL'}; } elsif ($1>$warning) { if ($verbose) { print "WARNING: $1 # Users Online > $warning Warning Status \t Critical ErrorLev 1 | UsersOnline=$1;0;0;\n"; } else { print "WARNING: $1 Users Online | UsersOnline=$1;0;0;\n";}; exit $ERRORS{'WARNING'}; } else { if ($verbose) { print "OK: $1 Users Online - Status normal \t Normal ErrorLev 0 | UsersOnline=$1;0;0;\n"; } else { print "OK: $1 Users Online | UsersOnline=$1;0;0;\n"; } exit $ERRORS{'OK'}; } } For e.g the output will look like: OK: 12 Users Online | UsersOnline=12;0;0; where -w is 150 and -c is 200. But nagios complains by saying "NRPE: Unable to read output". Is the format of the output wrong or am I missing any steps? --Turi -------------- next part -------------- An HTML attachment was scrubbed... URL: From aivaturi2 at unlnotes.unl.edu Fri Sep 9 06:50:24 2005 From: aivaturi2 at unlnotes.unl.edu (Aditya Ivaturi) Date: Fri Sep 9 06:50:24 2005 Subject: [Nagiosplug-devel] plugin help In-Reply-To: <8E90177DEBE3CA4EB5E3114D3C03E16941FC2E@OSC-EXMB-M-001.main.ads.uscg.mil> Message-ID: Well the if condition is not the problem I think, because when I execute it on command line I get exactly the result I was expecting. For e.g. this is one of the outputs: OK: 12 Users Online | UsersOnline=12;0;0; Where in fact there were only 12 users users using that system at that point. As far as permissions are concerned, I checked them and they all seem to be fine - owned by nagios and 755. --Turi Lynne.G.Lawrence at uscg.mil wrote on 09/09/2005 08:35:36 AM: > Perhaps your initial if statement is failing? I suggest that you > add an else{} clause to the initial if{} regex match; put out some > message and exit $ERRORS{UNKNOWN} for no match. Other than that, > maybe check the file permissions to ensure that it is executable by > the nagios user. > > Hope this helps, > > Lynne Lawrence > QSS/USCG > > From: nagiosplug-devel-admin at lists.sourceforge.net [mailto: > nagiosplug-devel-admin at lists.sourceforge.net] On Behalf Of Aditya Ivaturi > Sent: Thursday, September 08, 2005 5:08 PM > To: nagiosplug-devel at lists.sourceforge.net > Subject: [Nagiosplug-devel] plugin help > > This is the first time I am trying to write a plugin for Nagios. So > please bear with me. We have an online testing system and I am > writing a plugin to check how many users are actually taking a test. > It is a module that is in built in the system and exported via http. > So all I do is call that page and dump the number out. Nothing > complicated. The code-block (perl) which dumps out is as follows: > > > if ($content =~ m/Student Cache<\/TD>(\d*)<\/TD>/) { > if ($1>$critical) { > if ($verbose) { > print "CRITICAL: $1 Users Online > $critical Critical > Status \t Critical ErrorLev 2 | UsersOnline=$1;0;0;\n"; > } > else { > print "CRITICAL: $1 Users Online | UsersOnline=$1;0;0;\n"; > } > exit $ERRORS{'CRITICAL'}; > } > elsif ($1>$warning) { > if ($verbose) { > print "WARNING: $1 # Users Online > $warning Warning > Status \t Critical ErrorLev 1 | UsersOnline=$1;0;0;\n"; > } > else { > print "WARNING: $1 Users Online | UsersOnline=$1;0;0;\n";}; > exit $ERRORS{'WARNING'}; > } > else { > if ($verbose) { > print "OK: $1 Users Online - Status normal \t Normal > ErrorLev 0 | UsersOnline=$1;0;0;\n"; > } > else { > print "OK: $1 Users Online | UsersOnline=$1;0;0;\n"; > } > exit $ERRORS{'OK'}; > } > } > > > For e.g the output will look like: > > OK: 12 Users Online | UsersOnline=12;0;0; > > where -w is 150 and -c is 200. But nagios complains by saying "NRPE: > Unable to read output". Is the format of the output wrong or am I > missing any steps? > > --Turi > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Fri Sep 9 11:04:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 9 11:04:11 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1286235 ] check_dhcp network interface name too small Message-ID: Bugs item #1286235, was opened at 2005-09-09 18:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1286235&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: jbgorrie (jbgorrie) Assigned to: Nobody/Anonymous (nobody) Summary: check_dhcp network interface name too small Initial Comment: If you have a VLAN configuration under linux, you can have names longer than the permited 7 characters. eg: eth0.312 will fail with stock 1.4.1 line 1261 of stock 1.4.1 has char network_interface_name[8]="eth0"; I have requirements of names that are up to 11 characters. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1286235&group_id=29880 From ton.voon at altinity.com Mon Sep 12 01:06:24 2005 From: ton.voon at altinity.com (Ton Voon) Date: Mon Sep 12 01:06:24 2005 Subject: [Nagiosplug-devel] plugin help In-Reply-To: References: Message-ID: <4114CF09-F3D6-4027-8D0D-1210C6D1BD75@altinity.com> Aditya, NRPE: Unable to read output usually means that something was written to stderr and nothing to stdout when using check_nrpe. You should check that you can run your script as the nagios user on the target system, then try using check_nrpe from the nagios server as the nagios user. Only after these both work can you try from the Nagios daemon itself. I've seen situations where the #! interpreter was not executable by the nagios user on the target system would cause this problem. Ton On 9 Sep 2005, at 14:49, Aditya Ivaturi wrote: > > Well the if condition is not the problem I think, because when I > execute it on command line I get exactly the result I was > expecting. For e.g. this is one of the outputs: > > OK: 12 Users Online | UsersOnline=12;0;0; > > Where in fact there were only 12 users users using that system at > that point. As far as permissions are concerned, I checked them and > they all seem to be fine - owned by nagios and 755. > > --Turi > > Lynne.G.Lawrence at uscg.mil wrote on 09/09/2005 08:35:36 AM: > > > Perhaps your initial if statement is failing? I suggest that you > > add an else{} clause to the initial if{} regex match; put out some > > message and exit $ERRORS{UNKNOWN} for no match. Other than that, > > maybe check the file permissions to ensure that it is executable by > > the nagios user. > > > > Hope this helps, > > > > Lynne Lawrence > > QSS/USCG > > > > From: nagiosplug-devel-admin at lists.sourceforge.net [mailto: > > nagiosplug-devel-admin at lists.sourceforge.net] On Behalf Of Aditya > Ivaturi > > Sent: Thursday, September 08, 2005 5:08 PM > > To: nagiosplug-devel at lists.sourceforge.net > > Subject: [Nagiosplug-devel] plugin help > > > > > This is the first time I am trying to write a plugin for Nagios. So > > please bear with me. We have an online testing system and I am > > writing a plugin to check how many users are actually taking a test. > > It is a module that is in built in the system and exported via http. > > So all I do is call that page and dump the number out. Nothing > > complicated. The code-block (perl) which dumps out is as follows: > > > > > > if ($content =~ m/Student Cache<\/TD>(\d*)<\/TD>/) { > > if ($1>$critical) { > > if ($verbose) { > > print "CRITICAL: $1 Users Online > $critical Critical > > Status \t Critical ErrorLev 2 | UsersOnline=$1;0;0;\n"; > > } > > else { > > print "CRITICAL: $1 Users Online | UsersOnline=$1;0;0; > \n"; > > } > > exit $ERRORS{'CRITICAL'}; > > } > > elsif ($1>$warning) { > > if ($verbose) { > > print "WARNING: $1 # Users Online > $warning Warning > > Status \t Critical ErrorLev 1 | UsersOnline=$1;0;0;\n"; > > } > > else { > > print "WARNING: $1 Users Online | UsersOnline=$1;0;0; > \n";}; > > exit $ERRORS{'WARNING'}; > > } > > else { > > if ($verbose) { > > print "OK: $1 Users Online - Status normal \t Normal > > ErrorLev 0 | UsersOnline=$1;0;0;\n"; > > } > > else { > > print "OK: $1 Users Online | UsersOnline=$1;0;0;\n"; > > } > > exit $ERRORS{'OK'}; > > } > > } > > > > > > For e.g the output will look like: > > > > OK: 12 Users Online | UsersOnline=12;0;0; > > > > where -w is 150 and -c is 200. But nagios complains by saying "NRPE: > > Unable to read output". Is the format of the output wrong or am I > > missing any steps? > > > > --Turi > > > > > > > This message has been scanned for viruses by MailController. http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon The contents of this email and any files transmitted with it are confidential and intended solely for the use of the individuals to whom it is addressed. If you are not the intended recipient or have received this e-mail in error please notify the sender and destroy this e-mail immediately. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ton.voon at altinity.com Mon Sep 12 03:43:00 2005 From: ton.voon at altinity.com (Ton Voon) Date: Mon Sep 12 03:43:00 2005 Subject: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: <431C37EF.6070706@pramberger.at> References: <20050902105422.GA873@seanius.net> <20050902105619.GA919@seanius.net> <20050902112451.GA1226@seanius.net> <43184434.1010000@pramberger.at> <20050902130153.GA2211@seanius.net> <431854F0.2020406@pramberger.at> <89789F8C-9CA5-4723-9603-DAE31A680D1E@mac.com> <431C37EF.6070706@pramberger.at> Message-ID: <9561C0D6-F193-476F-A53E-28A164E3740B@altinity.com> Hi! I've had a think about this problem and regardless of Red Hat's fix (and it looks like it is something in their kernel, rather than incorrect programming on our side), we going to need to have a patch for this in the plugins. However, since it is only for the redhat kernel, I'm not convinced that popen.c should be changed globally. So I've just applied a patch where the configure script will pick up if this problem exists on red hat systems only. Peter's patch has been added to popen.c with ifdefs around it. Let me know if you agree or disagree with this method. Sascha, I'll still like to know what Red Hat say about this problem, even if it is just to amend the configure script to report their patch number to fix. I've tested this on a redhat server with the problem and on a Debian server and it appears to work fine. I'd be grateful for any other reports before releasing a 1.4.2 version. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon The contents of this email and any files transmitted with it are confidential and intended solely for the use of the individuals to whom it is addressed. If you are not the intended recipient or have received this e-mail in error please notify the sender and destroy this e-mail immediately. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly prohibited. From seanius at seanius.net Mon Sep 12 04:03:20 2005 From: seanius at seanius.net (sean finney) Date: Mon Sep 12 04:03:20 2005 Subject: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: <9561C0D6-F193-476F-A53E-28A164E3740B@altinity.com> References: <20050902105422.GA873@seanius.net> <20050902105619.GA919@seanius.net> <20050902112451.GA1226@seanius.net> <43184434.1010000@pramberger.at> <20050902130153.GA2211@seanius.net> <431854F0.2020406@pramberger.at> <89789F8C-9CA5-4723-9603-DAE31A680D1E@mac.com> <431C37EF.6070706@pramberger.at> <9561C0D6-F193-476F-A53E-28A164E3740B@altinity.com> Message-ID: <20050912110225.GA15527@seanius.net> hey ton, On Mon, Sep 12, 2005 at 11:42:06AM +0100, Ton Voon wrote: > Hi! > > I've had a think about this problem and regardless of Red Hat's fix > (and it looks like it is something in their kernel, rather than > incorrect programming on our side), we going to need to have a patch > for this in the plugins. However, since it is only for the redhat > kernel, I'm not convinced that popen.c should be changed globally. > > So I've just applied a patch where the configure script will pick up > if this problem exists on red hat systems only. Peter's patch has > been added to popen.c with ifdefs around it. that sounds like the best solution, all things considered. if/when the problem goes away, the test and ifdefs can be removed and we're right back where we are now, if we haven't gone further. > I've tested this on a redhat server with the problem and on a Debian > server and it appears to work fine. I'd be grateful for any other > reports before releasing a 1.4.2 version. before you release 1.4.2, i have a couple of simple localization-based issues i'd like to fix (i'll send a seperate email about that shortly), if possible. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From seanius at seanius.net Mon Sep 12 04:14:15 2005 From: seanius at seanius.net (sean finney) Date: Mon Sep 12 04:14:15 2005 Subject: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: <20050912110225.GA15527@seanius.net> References: <20050902105619.GA919@seanius.net> <20050902112451.GA1226@seanius.net> <43184434.1010000@pramberger.at> <20050902130153.GA2211@seanius.net> <431854F0.2020406@pramberger.at> <89789F8C-9CA5-4723-9603-DAE31A680D1E@mac.com> <431C37EF.6070706@pramberger.at> <9561C0D6-F193-476F-A53E-28A164E3740B@altinity.com> <20050912110225.GA15527@seanius.net> Message-ID: <20050912111315.GB15527@seanius.net> On Mon, Sep 12, 2005 at 07:02:25AM -0400, sean finney wrote: > before you release 1.4.2, i have a couple of simple localization-based issues > i'd like to fix (i'll send a seperate email about that shortly), if > possible. nevermind the seperate email, i'll just commit the change, it ended up being a smaller issue than i thought. just needed to re-add a call to setlocale(LC_ALL, "") check_ping. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From noreply at sourceforge.net Mon Sep 12 06:54:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 12 06:54:27 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1288725 ] changed output to match dev guidelines Message-ID: Patches item #1288725, was opened at 2005-09-12 08:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1288725&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Submitted By: monkeymanorg (monkeymanorg) Assigned to: Nobody/Anonymous (nobody) Summary: changed output to match dev guidelines Initial Comment: Trivial patch for standardization. Changed the plugin to conform to the developer guideline of "METRIC STATUS: Information text" in the one line output of the plugin. Also removed the #defines for the status codes. UNKNOWN was set to -1 instead of 3 and they are already included from common.h. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1288725&group_id=29880 From srunschke at abit.de Mon Sep 12 06:58:27 2005 From: srunschke at abit.de (srunschke at abit.de) Date: Mon Sep 12 06:58:27 2005 Subject: Antwort: Re: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: <9561C0D6-F193-476F-A53E-28A164E3740B@altinity.com> Message-ID: nagiosplug-devel-admin at lists.sourceforge.net schrieb am 12.09.2005 12:42:06: > Sascha, I'll still like to know what Red Hat say about this problem, > even if it is just to amend the configure script to report their > patch number to fix. They're working on it. I have done some debugging myself and for me it looks like an issue with the futex handling in the redhat kernel. It is currently escalated to an engineer who is looking into the issue. So it will take some more until I get another response I guess. regards sash -------------------------------------------------- Sascha Runschke Netzwerk Administration IT-Services ABIT AG Robert-Bosch-Str. 1 40668 Meerbusch Tel.:+49 (0) 2150.9153.226 Mobil:+49 (0) 173.5419665 mailto:SRunschke at abit.de http://www.abit.net http://www.abit-epos.net --------------------------------- Sicherheitshinweis zur E-Mail Kommunikation / Security note regarding email communication: http://www.abit.net/sicherheitshinweis.html From noreply at sourceforge.net Mon Sep 12 08:46:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 12 08:46:34 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1250191 ] ECHILD in waitpid (popen.c:spclose) Message-ID: Bugs item #1250191, was opened at 2005-08-02 13:39 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1250191&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: Pending >Resolution: Fixed >Priority: 7 Submitted By: Peter Pramberger (peterpramb) Assigned to: Ton Voon (tonvoon) Summary: ECHILD in waitpid (popen.c:spclose) Initial Comment: After installing Nagios 2.0b3 and plugins 1.4/1.4.1 on a CentOS 4.1 machine (a RedHat ES 4.1 clone, kernel-2.6.9, glibc-2.3.4) I found that the check_dns plugin always aborts with "DNS WARNING - nslookup returned error status" except in the first run. However running it in verbose mode always shows a successful nslookup output. After some debugging I found that the waitpid call in popen.c:spclose() returns a ECHILD, which triggers a failure return value to be passed back to check_dns. Cacthing the ECHILD always produces a reasonable output, so the child with nslookup is really working. >From the (linux) manpage: ECHILD if the process specified in pid does not exist or is not a child of the calling process. (This can happen for one's own child if the action for SIGCHLD is set to SIG_IGN. See also the LINUX NOTES section about threads.) Shouldn't waitpid be successful in reading the exit status of the child? Maybe a bug in glibc? Anyone else seen this? ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2005-09-12 16:45 Message: Logged In: YES user_id=664364 Have applied patch to CVS to fix this. Works by using Peter's patch surrounded by ifdefs. Configure checks whether this problem exists on the redhat system or not. Will release 1.4.2 after confirmed builds. Marking this item to pending closure. Ton ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-09-05 17:27 Message: Logged In: YES user_id=664364 Agreed with Sean to take over this call. Have created a testcase. Sascha Runschke is raising this to Red Hat. New patch from Peter Pramberger attached. Depending on reply from Red Hat, will apply patch next week. Ton ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-02 12:03 Message: Logged In: YES user_id=226838 ECHLD is returned in this context when the child has already exited, and shouldn't be treated as an error. i'll commit a change to cvs shortly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1250191&group_id=29880 From aivaturi2 at unlnotes.unl.edu Mon Sep 12 12:44:01 2005 From: aivaturi2 at unlnotes.unl.edu (Aditya Ivaturi) Date: Mon Sep 12 12:44:01 2005 Subject: [Nagiosplug-devel] plugin help In-Reply-To: <4114CF09-F3D6-4027-8D0D-1210C6D1BD75@altinity.com> Message-ID: > > NRPE: Unable to read output usually means that something was written > to stderr and nothing to stdout when using check_nrpe. You should > check that you can run your script as the nagios user on the target > system, then try using check_nrpe from the nagios server as the > nagios user. Only after these both work can you try from the Nagios > daemon itself. Yup the nagios user can execute the script on both ends. > > I've seen situations where the #! interpreter was not executable by > the nagios user on the target system would cause this problem. Well at least I am not having that problem. Any other suggestions? --Turi -------------- next part -------------- An HTML attachment was scrubbed... URL: From t_pascal at zennet.com Tue Sep 13 07:55:53 2005 From: t_pascal at zennet.com (T. Pascal) Date: Tue Sep 13 07:55:53 2005 Subject: [Nagiosplug-devel] FW: Check_disk long perfdata getting truncated Message-ID: <200509131551.j8DFpV3j001384@ceycal.com> I am running check_disk (nagios-plugins 1.4.1) 1.57 on RedHat ES3.0 /usr/lib/nagios/plugins/check_disk -u GB -w 20% -c 10% -p /home/oracle/arc_logs -p /home/oracle/u01 -p /home/oracle/u02 -p /home/oracle/u03 -p /home/oracle/u04 -p /home/oracle/u06 DISK OK - free space: /home/oracle/arc_logs 93 GB (71%); /home/oracle/u01 5 GB (51%); /home/oracle/u02 32 GB (98%); /home/oracle/u03 119 GB (31%); /home/oracle/u04 119 GB (31%); /home/oracle/u06 119 GB (31%);| /home/oracle/arc_logs=38GB;104;117;0;131 /home/oracle/u01=5GB;7;8;0;9 /home/oracle/u02=1GB;25;28;0;32 /home/oracle/u03=270GB;311;350;0;389 /home/oracle/u04=270GB;311;350;0;389 /home/oracle/u06=270GB;311;350;0;389 Running this via check_nrpe (2.0), the output is truncated so that this is reported by Nagios extended output (and in the $NAGIOS_SERVICEPERFDATA macro): /home/oracle/arc_logs=38GB;104;117;0;131 /home/oracle/u01=5GB;7;8;0;9 /home/oracle/u02=1GB;25;28;0;32 /home/oracle/u03=270GB;311;350;0;3 From sghosh at sghosh.org Tue Sep 13 08:01:26 2005 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Tue Sep 13 08:01:26 2005 Subject: [Nagiosplug-devel] FW: Check_disk long perfdata getting truncated In-Reply-To: <200509131551.j8DFpV3j001384@ceycal.com> References: <200509131551.j8DFpV3j001384@ceycal.com> Message-ID: On Tue, 13 Sep 2005, T. Pascal wrote: > I am running check_disk (nagios-plugins 1.4.1) 1.57 on RedHat ES3.0 > > /usr/lib/nagios/plugins/check_disk -u GB -w 20% -c 10% -p > /home/oracle/arc_logs -p /home/oracle/u01 -p /home/oracle/u02 -p > /home/oracle/u03 -p /home/oracle/u04 -p /home/oracle/u06 > DISK OK - free space: /home/oracle/arc_logs 93 GB (71%); /home/oracle/u01 5 > GB (51%); /home/oracle/u02 32 GB (98%); /home/oracle/u03 119 GB (31%); > /home/oracle/u04 119 GB (31%); /home/oracle/u06 119 GB (31%);| > /home/oracle/arc_logs=38GB;104;117;0;131 /home/oracle/u01=5GB;7;8;0;9 > /home/oracle/u02=1GB;25;28;0;32 /home/oracle/u03=270GB;311;350;0;389 > /home/oracle/u04=270GB;311;350;0;389 /home/oracle/u06=270GB;311;350;0;389 > > Running this via check_nrpe (2.0), the output is truncated so that this is > reported by Nagios extended output (and in the $NAGIOS_SERVICEPERFDATA > macro): > > /home/oracle/arc_logs=38GB;104;117;0;131 /home/oracle/u01=5GB;7;8;0;9 > /home/oracle/u02=1GB;25;28;0;32 /home/oracle/u03=270GB;311;350;0;3 > You are hitting the size limit of the $OUTPUT$ -- -sg From tonvoon at mac.com Tue Sep 13 08:05:00 2005 From: tonvoon at mac.com (Ton Voon) Date: Tue Sep 13 08:05:00 2005 Subject: [Nagiosplug-devel] FW: Check_disk long perfdata getting truncated In-Reply-To: <200509131551.j8DFpV3j001384@ceycal.com> References: <200509131551.j8DFpV3j001384@ceycal.com> Message-ID: I'm afraid this is a limitation of nrpe and/or nagios, not the check_disk plugin. IRC, there is a setting you can hack in nrpe to increase the amount of data returned, but then you'll probably hit a limit in Nagios. Best thing is to run separate check_disk calls. On 13 Sep 2005, at 15:52, T. Pascal wrote: > I am running check_disk (nagios-plugins 1.4.1) 1.57 on RedHat ES3.0 > > /usr/lib/nagios/plugins/check_disk -u GB -w 20% -c 10% -p > /home/oracle/arc_logs -p /home/oracle/u01 -p /home/oracle/u02 -p > /home/oracle/u03 -p /home/oracle/u04 -p /home/oracle/u06 > DISK OK - free space: /home/oracle/arc_logs 93 GB (71%); /home/ > oracle/u01 5 > GB (51%); /home/oracle/u02 32 GB (98%); /home/oracle/u03 119 GB (31%); > /home/oracle/u04 119 GB (31%); /home/oracle/u06 119 GB (31%);| > /home/oracle/arc_logs=38GB;104;117;0;131 /home/oracle/u01=5GB;7;8;0;9 > /home/oracle/u02=1GB;25;28;0;32 /home/oracle/u03=270GB;311;350;0;389 > /home/oracle/u04=270GB;311;350;0;389 /home/oracle/u06=270GB; > 311;350;0;389 > > Running this via check_nrpe (2.0), the output is truncated so that > this is > reported by Nagios extended output (and in the $NAGIOS_SERVICEPERFDATA > macro): > > /home/oracle/arc_logs=38GB;104;117;0;131 /home/oracle/u01=5GB;7;8;0;9 > /home/oracle/u02=1GB;25;28;0;32 /home/oracle/u03=270GB;311;350;0;3 > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * > Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/ > bsce5sf > _______________________________________________________ > 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 > > > This message has been scanned for viruses by MailController - > www.MailController.altohiway.com > From gh at 3gupload.com Tue Sep 13 08:20:01 2005 From: gh at 3gupload.com (Garrett Honeycutt) Date: Tue Sep 13 08:20:01 2005 Subject: [Nagiosplug-devel] FW: Check_disk long perfdata getting truncated In-Reply-To: <200509131551.j8DFpV3j001384@ceycal.com> References: <200509131551.j8DFpV3j001384@ceycal.com> Message-ID: <1126624716.7244.24.camel@gspot.internal.3gupload.com> On Tue, 2005-09-13 at 07:52 -0700, T. Pascal wrote: > I am running check_disk (nagios-plugins 1.4.1) 1.57 on RedHat ES3.0 > > /usr/lib/nagios/plugins/check_disk -u GB -w 20% -c 10% -p > /home/oracle/arc_logs -p /home/oracle/u01 -p /home/oracle/u02 -p > /home/oracle/u03 -p /home/oracle/u04 -p /home/oracle/u06 > DISK OK - free space: /home/oracle/arc_logs 93 GB (71%); /home/oracle/u01 5 > GB (51%); /home/oracle/u02 32 GB (98%); /home/oracle/u03 119 GB (31%); > /home/oracle/u04 119 GB (31%); /home/oracle/u06 119 GB (31%);| > /home/oracle/arc_logs=38GB;104;117;0;131 /home/oracle/u01=5GB;7;8;0;9 > /home/oracle/u02=1GB;25;28;0;32 /home/oracle/u03=270GB;311;350;0;389 > /home/oracle/u04=270GB;311;350;0;389 /home/oracle/u06=270GB;311;350;0;389 > > Running this via check_nrpe (2.0), the output is truncated so that this is > reported by Nagios extended output (and in the $NAGIOS_SERVICEPERFDATA > macro): > > /home/oracle/arc_logs=38GB;104;117;0;131 /home/oracle/u01=5GB;7;8;0;9 > /home/oracle/u02=1GB;25;28;0;32 /home/oracle/u03=270GB;311;350;0;3 > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________________ > 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 Instead of running check_disk on each host and getting back all of the data, create a command like check_disk_arc-logs and check_disk_u02 in your nrpe.cfg and check each partition individually. This way the perf data will not be too long and you can fine tune the warning and critical levels. Cheers, -g -- // Garrett Honeycutt // Sr. Systems Administrator // 3GUpload.com, Inc. // 317.472.4969 Office From bobi at netshel.net Tue Sep 13 08:54:16 2005 From: bobi at netshel.net (Bob Ingraham) Date: Tue Sep 13 08:54:16 2005 Subject: [Nagiosplug-devel] New ps utility for Solaris check_procs Message-ID: <2597.12.110.19.97.1126626806.squirrel@12.110.19.97> Hi, I'd like to help-out by contributing some of the patches I've made to our site's Nagios installation. We currently hundreds of servers under many different OSes: (AIX,Solaris,Linux,True64,VMS,OS/2,Netware,Windows) I've got a large test bed for each of these platforms and have been patching as I go along. Also, I've also ported nrpe and many of the plugins to True64 and VMS, if that helps. One of the problems that I've run into on Solaris is that the built-in ps program truncates the process argument list to 80 bytes. So, I've written a small, "alternate" ps utility that works with check_procs to get around this limit. It's been debugged and works well within our Solaris server farm. Is this something I should submit? Thanks, Bob Ingraham From ton.voon at altinity.com Tue Sep 13 09:04:31 2005 From: ton.voon at altinity.com (Ton Voon) Date: Tue Sep 13 09:04:31 2005 Subject: [Nagiosplug-devel] New ps utility for Solaris check_procs In-Reply-To: <2597.12.110.19.97.1126626806.squirrel@12.110.19.97> References: <2597.12.110.19.97.1126626806.squirrel@12.110.19.97> Message-ID: <94903582-D99B-4D8C-9145-6914163FC828@altinity.com> Bob, That sounds great. If you could supply your patches to SF's patch tracker at http://sourceforge.net/tracker/? group_id=29880&atid=397599, we'll look into it. Give me a nudge if there is no action :) We are only developing against CVS HEAD at the moment, so if you patch against that, it will increase the chances of it getting in. Re: Solaris ps command, are there any other command flags that do provide > 80 chars commands? Ton On 13 Sep 2005, at 16:53, Bob Ingraham wrote: > Hi, > > I'd like to help-out by contributing some of the patches I've made > to our > site's Nagios installation. > > We currently hundreds of servers under many different OSes: > (AIX,Solaris,Linux,True64,VMS,OS/2,Netware,Windows) > > I've got a large test bed for each of these platforms and have been > patching as I go along. > > Also, I've also ported nrpe and many of the plugins to True64 and > VMS, if > that helps. > > One of the problems that I've run into on Solaris is that the built- > in ps > program truncates the process argument list to 80 bytes. So, I've > written > a small, "alternate" ps utility that works with check_procs to get > around > this limit. > > It's been debugged and works well within our Solaris server farm. > > Is this something I should submit? > > Thanks, > Bob Ingraham > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * > Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/ > bsce5sf > _______________________________________________________ > 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 > > > This message has been scanned for viruses by MailController - > www.MailController.altohiway.com > http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon The contents of this email and any files transmitted with it are confidential and intended solely for the use of the individuals to whom it is addressed. If you are not the intended recipient or have received this e-mail in error please notify the sender and destroy this e-mail immediately. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly prohibited. From bobi at netshel.net Tue Sep 13 09:21:01 2005 From: bobi at netshel.net (Bob Ingraham) Date: Tue Sep 13 09:21:01 2005 Subject: [Nagiosplug-devel] New ps utility for Solaris check_procs In-Reply-To: <94903582-D99B-4D8C-9145-6914163FC828@altinity.com> References: <2597.12.110.19.97.1126626806.squirrel@12.110.19.97> <94903582-D99B-4D8C-9145-6914163FC828@altinity.com> Message-ID: <35744.12.110.19.97.1126628396.squirrel@12.110.19.97> The patch only applies to the configuration script, since the alternate ps utility invocation just replaces the existing one defined for Solaris as PS_COMMAND in the auto-generated config.h. As such, there are no changes needed to check_procs.c. As far as the changing the 80-char limit, I've been up,down and inside-out on Solaris and developer.sun.com. You *can* supply flags or even change the COLUMNS environment variable, but to no avail - since the 80-byte limit is hard-coded as a #define in the kernel's psinfo_t structure (see: /usr/include/sys/procfs.h). The Solaris ps utility can only get its information from /proc using the structures defined in - so that's all it sees. So, I'd be submitting a patch for the auto-generation of PS_COMMAND for Solaris and also submitting a new file (pst3.c) that would go - I don't know - in the plugins directory of the source tree, perhaps? That's where I've implemented/deployed mine. Bob > Bob, > > That sounds great. If you could supply your patches to SF's patch > tracker at http://sourceforge.net/tracker/? > group_id=29880&atid=397599, we'll look into it. Give me a nudge if > there is no action :) > > We are only developing against CVS HEAD at the moment, so if you > patch against that, it will increase the chances of it getting in. > > Re: Solaris ps command, are there any other command flags that do > provide > 80 chars commands? > > Ton > > On 13 Sep 2005, at 16:53, Bob Ingraham wrote: > >> Hi, >> >> I'd like to help-out by contributing some of the patches I've made >> to our >> site's Nagios installation. >> >> We currently hundreds of servers under many different OSes: >> (AIX,Solaris,Linux,True64,VMS,OS/2,Netware,Windows) >> >> I've got a large test bed for each of these platforms and have been >> patching as I go along. >> >> Also, I've also ported nrpe and many of the plugins to True64 and >> VMS, if >> that helps. >> >> One of the problems that I've run into on Solaris is that the built- >> in ps >> program truncates the process argument list to 80 bytes. So, I've >> written >> a small, "alternate" ps utility that works with check_procs to get >> around >> this limit. >> >> It's been debugged and works well within our Solaris server farm. >> >> Is this something I should submit? >> >> Thanks, >> Bob Ingraham >> >> >> ------------------------------------------------------- >> SF.Net email is Sponsored by the Better Software Conference & EXPO >> September 19-22, 2005 * San Francisco, CA * Development Lifecycle >> Practices >> Agile & Plan-Driven Development * Managing Projects & Teams * >> Testing & QA >> Security * Process Improvement & Measurement * http://www.sqe.com/ >> bsce5sf >> _______________________________________________________ >> 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 >> >> >> This message has been scanned for viruses by MailController - >> www.MailController.altohiway.com >> > > > > > > http://www.altinity.com > T: +44 (0)870 787 9243 > F: +44 (0)845 280 1725 > Skype: tonvoon > > The contents of this email and any files transmitted with it are > confidential and intended solely for the use of the individuals to > whom it > is addressed. If you are not the intended recipient or have received > this > e-mail in error please notify the sender and destroy this e-mail > immediately. Any unauthorised copying, disclosure or distribution of the > material in this e-mail is strictly prohibited. > > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________________ > 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 t_pascal at zennet.com Tue Sep 13 10:24:31 2005 From: t_pascal at zennet.com (T. Pascal) Date: Tue Sep 13 10:24:31 2005 Subject: [Nagiosplug-devel] FW: Check_disk long perfdata gettingtruncated In-Reply-To: <1126624716.7244.24.camel@gspot.internal.3gupload.com> Message-ID: <200509131821.j8DILC3j001761@ceycal.com> I figured that adding more specific (smaller) checks was the solution; but I wanted to see if it was a known problem or was it something that can/should be fixed, etc. Thanks, all. > -----Original Message----- > From: nagiosplug-devel-admin at lists.sourceforge.net > [mailto:nagiosplug-devel-admin at lists.sourceforge.net] On > Behalf Of Garrett Honeycutt > Sent: Tuesday, September 13, 2005 8:19 AM > To: T. Pascal > Cc: nagiosplug-devel at lists.sourceforge.net > Subject: Re: [Nagiosplug-devel] FW: Check_disk long perfdata > gettingtruncated > > On Tue, 2005-09-13 at 07:52 -0700, T. Pascal wrote: > > I am running check_disk (nagios-plugins 1.4.1) 1.57 on RedHat ES3.0 > > > > /usr/lib/nagios/plugins/check_disk -u GB -w 20% -c 10% -p > > /home/oracle/arc_logs -p /home/oracle/u01 -p /home/oracle/u02 -p > > /home/oracle/u03 -p /home/oracle/u04 -p /home/oracle/u06 > > DISK OK - free space: /home/oracle/arc_logs 93 GB (71%); > /home/oracle/u01 5 > > GB (51%); /home/oracle/u02 32 GB (98%); /home/oracle/u03 > 119 GB (31%); > > /home/oracle/u04 119 GB (31%); /home/oracle/u06 119 GB (31%);| > > /home/oracle/arc_logs=38GB;104;117;0;131 > /home/oracle/u01=5GB;7;8;0;9 > > /home/oracle/u02=1GB;25;28;0;32 /home/oracle/u03=270GB;311;350;0;389 > > /home/oracle/u04=270GB;311;350;0;389 > /home/oracle/u06=270GB;311;350;0;389 > > > > Running this via check_nrpe (2.0), the output is truncated > so that this is > > reported by Nagios extended output (and in the > $NAGIOS_SERVICEPERFDATA > > macro): > > > > /home/oracle/arc_logs=38GB;104;117;0;131 > /home/oracle/u01=5GB;7;8;0;9 > > /home/oracle/u02=1GB;25;28;0;32 /home/oracle/u03=270GB;311;350;0;3 > > > > > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development > Lifecycle Practices > > Agile & Plan-Driven Development * Managing Projects & Teams > * Testing & QA > > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > > _______________________________________________________ > > 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 > > Instead of running check_disk on each host and getting back all of the > data, create a command like check_disk_arc-logs and check_disk_u02 in > your nrpe.cfg and check each partition individually. This way the perf > data will not be too long and you can fine tune the warning > and critical > levels. > > Cheers, > -g > > -- > // Garrett Honeycutt > // Sr. Systems Administrator > // 3GUpload.com, Inc. > // 317.472.4969 Office > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development > Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * > Testing & QA > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > _______________________________________________________ > 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 seanius at seanius.net Tue Sep 13 10:55:02 2005 From: seanius at seanius.net (sean finney) Date: Tue Sep 13 10:55:02 2005 Subject: [Nagiosplug-devel] New ps utility for Solaris check_procs In-Reply-To: <2597.12.110.19.97.1126626806.squirrel@12.110.19.97> References: <2597.12.110.19.97.1126626806.squirrel@12.110.19.97> Message-ID: <20050913175407.GA7390@seanius.net> On Tue, Sep 13, 2005 at 08:53:26AM -0700, Bob Ingraham wrote: > One of the problems that I've run into on Solaris is that the built-in ps > program truncates the process argument list to 80 bytes. So, I've written > a small, "alternate" ps utility that works with check_procs to get around > this limit. > > It's been debugged and works well within our Solaris server farm. hey, cool. > Is this something I should submit? definitely. if you issue it as a bug rather than a patch it'll show up on my radar (i spend most of my in the bugs tracker), and i'll see about getting it brought in somehow. thanks, sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From noreply at sourceforge.net Wed Sep 14 02:55:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 14 02:55:40 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1254656 ] uptime result error in check_load Message-ID: Bugs item #1254656, was opened at 2005-08-09 03:36 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1254656&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ronald Tin (hokuto_su) Assigned to: M. Sean Finney (seanius) Summary: uptime result error in check_load Initial Comment: While performing sscanf, the parameter should be %lf instead of %f because the actual la[] array is double. line 140 : sscanf (input_buffer, "%*[^l]load average: %lf, %lf, %lf", &la1, &la5, &la15); Applies to nagios-plugins 1.4.1 ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2005-09-14 10:54 Message: Logged In: YES user_id=664364 Ronald, Thanks for the patch. I've applied it to CVS as check_load.c v1.30 Ton ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-08-24 23:17 Message: Logged In: YES user_id=226838 hi, thanks for finding this, i'll commit a fix to cvs shortly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1254656&group_id=29880 From tonvoon at mac.com Wed Sep 14 05:49:03 2005 From: tonvoon at mac.com (Ton Voon) Date: Wed Sep 14 05:49:03 2005 Subject: [Nagiosplug-devel] Success with minor issues: AIX 4.3, check_ldaps, Perl syntax In-Reply-To: <73BB3A1D374DA64F98E8EA9C37FB3F5F0181F2EB@exchmail1.corp.gianteagle.com> References: <73BB3A1D374DA64F98E8EA9C37FB3F5F0181F2EB@exchmail1.corp.gianteagle.com> Message-ID: Chester, I know this is terribly late, but thanks for your report. I've fixed (2). Not sure how to fix (1) - I'd be grateful for any ideas from anyone. Not sure why (3) is happening. Unfortunately, I don't know enough about (4) to sort out. For (5), I'd be interested in how coreutils does this (http:// www.gnu.org/software/coreutils/) because we use their routines to get the load average and I doubt if they insist on setuid root to allow this to happen. Can I get access to an AIX server to test on? 1 out of 5 - pretty bad showing :( Ton On 4 Aug 2005, at 15:05, Hosey, Chester wrote: > This probably doesn?t too many people, but I'm reporting it anyway > in accordance with the note at http://nagiosplug.sourceforge.net/. > > I successfully built nagios-plugins 1.4 on an AIX 4.3 machine using > gcc 3.3 from Bull Freeware (for the archives: others with similar > setups will also need gettext from Bull Freeware in order to get > gcc to work, otherwise gcc will fail with something like "dependent > module libintl.a(shr.o) could not be loaded"). > > Most of the plugins built successfully. There were some minor issues: > > 1) The generated Makefiles include -R/usr/local/lib > Workaround: vi `find . -name Makefile`, remove -R/usr/local/lib > > 2) The link check_ldaps->check_ldap was generated despite the fact > that check_ldap itself wasn't built. > > 3) The "use lib" line in many of the generated Perl scripts wasn't > syntactically correct -- it read: > > use lib "/usr/local/nagios/libexec" /libexec > > The line should probably have read: > > use lib "/usr/local/nagios/libexec", "/libexec"; > > Note the added quotes and semicolon. Since /libexec doesn't > exist on this system anyways, I just edited the line to read: > > use lib "/usr/local/nagios/libexec"; > > 4) Line 50 of check_breeze reads: > $sig = `snmpgetuser/local/bin/snmpget > > Based on the successfully built copy on my Red Hat machine, it > should read (with possible path adjustments): > > $sig = `/usr/bin/snmpget $host $opc_C . > 1.3.6.1.4.1.710.3.2.3.1.3.0`; > > Although since snmpget doesn't exist on this system the plugin > should probably not have been build/installed at all. > > 5) I had to make check_load setuid root. When run without root > permissions, it returns '0 0 0' as the load average. > > These are easy to work around with rm and vi, so please consider > this a report of success. > > Chet > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Wed Sep 14 08:48:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 14 08:48:03 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1291115 ] Wrong compile Options for openSSL Message-ID: Bugs item #1291115, was opened at 2005-09-14 17:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291115&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Michael (fichi) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong compile Options for openSSL Initial Comment: I tried to compile nagios-plugins-1.4.1.tar.gz on a debian 3.1r0a system. I installed openssl-0.9.8 successfully into /usr/local/ssl which is default for this release. I run ./configure --with-openssl=/usr/local/ssl The make aborted with the following error message. gcc -g -O2 -L. -R/usr/local/ssl/lib -L/usr/local/ssl/lib -o check_http check_http.o netutils.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -lnsl -lresolv -lssl -lcrypto -I/usr/local/ssl/include gcc: unrecognized option `-R/usr/local/ssl/lib' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x45): In function `dlfcn_load': : undefined reference to `dlopen' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0xc4): In function `dlfcn_load': : undefined reference to `dlclose' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x102): In function `dlfcn_load': : undefined reference to `dlerror' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x1ad): In function `dlfcn_bind_var': : undefined reference to `dlsym' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x1f2): In function `dlfcn_bind_var': : undefined reference to `dlerror' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x2ed): In function `dlfcn_bind_func': : undefined reference to `dlsym' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x337): In function `dlfcn_bind_func': : undefined reference to `dlerror' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x68a): In function `dlfcn_unload': : undefined reference to `dlclose' collect2: ld returned 1 exit status make[2]: *** [check_http] Error 1 make[2]: Leaving directory `/root/src/nagios-plugins-1.4.1/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/src/nagios-plugins-1.4.1' make: *** [all] Error 2 The problem is in the Makefile from the plugin directory. If you echang the following lines: LDFLAGS = -L. -R/usr/local/ssl/lib -L/usr/local/ssl/lib -> LDFLAGS = -L. -L/usr/local/ssl/lib -L/usr/local/ssl/lib SSLLIBS = -lssl -lcrypto -> SSLLIBS = -lssl -ldl -lcrypto the compile goes OK It seams that openSSL requires an additional link option -ldl for this release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291115&group_id=29880 From noreply at sourceforge.net Wed Sep 14 09:06:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 14 09:06:54 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1291126 ] Alternate ps for Solaris Message-ID: Bugs item #1291126, was opened at 2005-09-14 10:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291126&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: CVS Status: Open Resolution: None Priority: 5 Submitted By: Bob Ingraham (rwingraham) Assigned to: Nobody/Anonymous (nobody) Summary: Alternate ps for Solaris Initial Comment: Per Sean, I am uploading the source for an alternate ps utility for Solaris that will work with the existing check_procs plugin. This alternate ps gets around the 80-character limitation inherent in the native ps for Solaris. It has been extensively testing on our corporate Solaris farm. Notes: 1. I've installed this alternate ps (called pst3) in the libexec directory, along with the other plugins. 2. It needs setuid-root permissions to run, but accepts no arguments and reads no input streams and therefore isn't subject to exploitations such as buffer overflow and the like. The only reason is needs the setuid-root permission is so that it can open the running kernel image, in READ-ONLY mode, in order to access the process argument vectors. 3. It requires a patch to the configuration file which substitutes this alternate utility instead of ps for Soalris systems. Bob ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291126&group_id=29880 From noreply at sourceforge.net Thu Sep 15 06:43:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 15 06:43:39 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1291987 ] nagios-plugins 1.4.1: urlize --useragent does not work Message-ID: Bugs item #1291987, was opened at 2005-09-15 15:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291987&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Daniel Bimschas (bimschas) Assigned to: Nobody/Anonymous (nobody) Summary: nagios-plugins 1.4.1: urlize --useragent does not work Initial Comment: running ./urlize http://www.google.de "./check_http -H www.google.de --useragent='not working'" returns: Name or service not known Unable to open TCP socket while the same command without "=" works: ./urlize http://www.google.de "./check_http -H allianz.phase4.de --useragent 'not working'" returns the correct output ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291987&group_id=29880 From C.Meissner at mc-wetter.de Thu Sep 15 12:22:02 2005 From: C.Meissner at mc-wetter.de (Christian Meissner) Date: Thu Sep 15 12:22:02 2005 Subject: [Nagiosplug-devel] hi ... i'm new here Message-ID: <827F4DA483EF5F42B31E2E19E1A31127C1D695@redmond.berlin.mc-wetter.de> Hi, my name is Christian, and im new in this list 'cause i wanna publish my own plugins to contribute to the nagios project. Which i have to do to publish my developments to the project. cu chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From sghosh at sghosh.org Thu Sep 15 14:30:32 2005 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Thu Sep 15 14:30:32 2005 Subject: [Nagiosplug-devel] hi ... i'm new here In-Reply-To: <827F4DA483EF5F42B31E2E19E1A31127C1D695@redmond.berlin.mc-wetter.de> References: <827F4DA483EF5F42B31E2E19E1A31127C1D695@redmond.berlin.mc-wetter.de> Message-ID: On Thu, 15 Sep 2005, Christian Meissner wrote: > Hi, > > my name is Christian, and im new in this list 'cause i wanna publish my own plugins to contribute to the nagios project. > > Which i have to do to publish my developments to the project. > > cu chris > Willkommen -- -sg From noreply at sourceforge.net Thu Sep 15 15:26:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 15 15:26:40 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1292404 ] Can't send newline with check_tcp Message-ID: Bugs item #1292404, was opened at 2005-09-16 00:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1292404&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Wiesinger (swiesinger) Assigned to: Nobody/Anonymous (nobody) Summary: Can't send newline with check_tcp Initial Comment: In v1.4.1 check_tcp doesn't send \r\n at the end of the -s string. that breaks many checks. I didn't see a way to send a newline, so I made the following patch which parses \(n,r,t) in the -s string. I don't know if that should be added to the expect string, too, I'm a C novice and didn't find an easy way to add that functionality. Regards, Sebastian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1292404&group_id=29880 From psingh at inforelay.com Fri Sep 16 12:43:31 2005 From: psingh at inforelay.com (Paul Singh) Date: Fri Sep 16 12:43:31 2005 Subject: [Nagiosplug-devel] Problem compiling plugins on Gentoo Message-ID: I've got Nagios installed just fine, but now I'm trying to install the plugins. As I try to compile the plugins, it seems to get stuck on "checking for ICMP ping syntax..." forever. Using plugin version 1.4.1, I think I just need to figure out the proper ping syntax and insert it into the ebuild. What is everyone using the "--with-ping-command=" option when configuring the plugins? Paul Singh From srunschke at abit.de Mon Sep 19 03:31:25 2005 From: srunschke at abit.de (srunschke at abit.de) Date: Mon Sep 19 03:31:25 2005 Subject: Antwort: [Nagiosplug-devel] Problem compiling plugins on Gentoo In-Reply-To: Message-ID: nagiosplug-devel-admin at lists.sourceforge.net schrieb am 16.09.2005 21:42:35: > I've got Nagios installed just fine, but now I'm trying to install > the plugins. As I try to compile the plugins, it seems to get stuck > on "checking for ICMP ping syntax..." forever. > > Using plugin version 1.4.1, I think I just need to figure out the > proper ping syntax and insert it into the ebuild. What is everyone > using the "--with-ping-command=" option when configuring the plugins? It's kinda hard to know the answer as you do not provide enough information, especially essential one like which system you are trying to compile on. Nevertheless I'm going to check my crystalball, hold the line... ... ... ... My crystalball says you are most likely using HP-UX 10+. Check the archive of the mailinglist, this issue has been discussed lately. regards sash -------------------------------------------------- Sascha Runschke Netzwerk Administration IT-Services ABIT AG Robert-Bosch-Str. 1 40668 Meerbusch Tel.:+49 (0) 2150.9153.226 Mobil:+49 (0) 173.5419665 mailto:SRunschke at abit.de http://www.abit.net http://www.abit-epos.net --------------------------------- Sicherheitshinweis zur E-Mail Kommunikation / Security note regarding email communication: http://www.abit.net/sicherheitshinweis.html From seanius at seanius.net Mon Sep 19 03:35:10 2005 From: seanius at seanius.net (sean finney) Date: Mon Sep 19 03:35:10 2005 Subject: [Nagiosplug-devel] Problem compiling plugins on Gentoo In-Reply-To: References: Message-ID: <20050919103406.GA14525@seanius.net> hi paul, On Fri, Sep 16, 2005 at 03:42:35PM -0400, Paul Singh wrote: > Using plugin version 1.4.1, I think I just need to figure out the > proper ping syntax and insert it into the ebuild. What is everyone > using the "--with-ping-command=" option when configuring the plugins? could you give us the command it is running while hanging? my guess is that the gentoo version of ping is doing some kind of continuous ping where the configure script thinks it is only supposed to do a certain number of pings. i can't comment too much more on it not being a gentoo user, so perhaps you should talk to the maintainer of the gentoo ebuild. whatever they find we'd be interested to know though, and we could fix our configure script to work around the problem if it is a bug on our end. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From srunschke at abit.de Mon Sep 19 03:48:10 2005 From: srunschke at abit.de (srunschke at abit.de) Date: Mon Sep 19 03:48:10 2005 Subject: [Nagiosplug-devel] dig/nslookup wait() problems - RedHat support responses # Part 2 In-Reply-To: Message-ID: Ok, RedHat engineering finally came back to me. "It seems a patch to fix this may already exist. Engineering would like to know if you would like a test kernel with the patch included. If it appears to work for you we can later provide a supportable hotfix kernel until such a time as an official errata (currently scheduled for Red Hat Enterprise Linux 4, Update 3) with this patch becomes available." So I'm waiting for them to send that patched kernel to me and see if it fixes the problem. Sadly I will most likely only receive a binary kernel at first, so I cannot check what they actually changed. But if the approved hotfix comes through I can take a glimpse at the source. regards sash -------------------------------------------------- Sascha Runschke Netzwerk Administration IT-Services ABIT AG Robert-Bosch-Str. 1 40668 Meerbusch Tel.:+49 (0) 2150.9153.226 Mobil:+49 (0) 173.5419665 mailto:SRunschke at abit.de http://www.abit.net http://www.abit-epos.net --------------------------------- Sicherheitshinweis zur E-Mail Kommunikation / Security note regarding email communication: http://www.abit.net/sicherheitshinweis.html From noreply at sourceforge.net Mon Sep 19 07:59:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 19 07:59:16 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1181554 ] 1.4-3: Bug in check_tcp Message-ID: Bugs item #1181554, was opened at 2005-04-12 11:27 Message generated for change (Comment added) made by seanius You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1181554&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 Submitted By: Simon Bellwood (sb-netman) Assigned to: M. Sean Finney (seanius) Summary: 1.4-3: Bug in check_tcp Initial Comment: I'm using check_imap with perfparse, and it's returning critical for all values. It seems the problem is that when no critical or warning value is passed to it on the command line, it defaults to use 0.000 and 0.000 respectively. Perfparse then sees that the check time (say 0.002 seconds) is above 0 and flags a CRITICAL warning. I've had a look at the code, and the return happens at check_tcp.c:389, where fperfdata is called. fperfdata is provided by utils.h which sets both types to a double, so I suspect it's not as simple as changing check_tcp.c to return nulls if the -w and -c flags aren't given :/ ---------------------------------------------------------------------- >Comment By: M. Sean Finney (seanius) Date: 2005-09-19 10:58 Message: Logged In: YES user_id=226838 hi, are you still interested in resolving this bug? if so, i still need to know what the perfparse system will need to represent and "undefined" number, or whether no perfparse data should be output at all in such a case. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-05-02 09:07 Message: Logged In: YES user_id=226838 sorry, i should be a little more clear on this: is perfparse capable of parsing an "unknown" or "undefined" value? if so, how should it look? otherwise, would it make sense to just not pass the information to perfparse at all? if so how should that look? you're right that there's no way to pass such values in the current code, but it wouldn't be too hard to add this functionality, as long as i knew what i was doing :) ---------------------------------------------------------------------- Comment By: Simon Bellwood (sb-netman) Date: 2005-05-02 03:14 Message: Logged In: YES user_id=1156501 > i don't believe arbitrarily setting the warn/critical > values is the appropriate response. But this is what utils.h does (used by check_tcp.c), not perfparse. There seems to be no way of returning an unknown value, so it uses 0.000 instead. perfparse sees the "unknown" warning and critical values as 0.000, so uses them. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-05-01 16:26 Message: Logged In: YES user_id=226838 hi, i'm still not sure what the solution to this should be. i don't believe arbitrarily setting the warn/critical values is the appropriate response. is there an undef value in perfparse? ---------------------------------------------------------------------- Comment By: Simon Bellwood (sb-netman) Date: 2005-04-19 02:52 Message: Logged In: YES user_id=1156501 But the plugin returns "0" and "0" for its warning and critical values, even though they are undefined - isn't that a bug? ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-04-18 19:50 Message: Logged In: YES user_id=226838 perhaps there's an "undef" value that could be used in such a case? i really don't know much about the whole perfparse thing since i use a seperate system from nagios for monitoring performance data. otherwise, i think the system is doing exactly what it's supposed to be doing, and would need some convincing why the answer isn't to just pass the warning and critical arguments to check_tcp. ---------------------------------------------------------------------- Comment By: Simon Bellwood (sb-netman) Date: 2005-04-18 03:01 Message: Logged In: YES user_id=1156501 I was hoping that one of the developers would either say: i) Oh no wait, there's an easy fix for this ii) Tell perfparse to treat 0.0 as "no value" Although ii) might be wrong in some cases, i.e. when 0 was considered a good value (perhaps for items where a measure from the normal was taken - can' think of any examples atm) ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-04-17 18:14 Message: Logged In: YES user_id=226838 hi, what exactly are you suggesting as a fix? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1181554&group_id=29880 From noreply at sourceforge.net Mon Sep 19 08:02:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 19 08:02:19 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1117037 ] rpmbuild for 1.4 fails Message-ID: Bugs item #1117037, was opened at 2005-02-05 17:08 Message generated for change (Settings changed) made by seanius You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1117037&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Martijn Lievaart (mappie) Assigned to: M. Sean Finney (seanius) Summary: rpmbuild for 1.4 fails Initial Comment: Trying to build an rpm (rpmbuild -tb nagios-plugins-1.4.tar.gz) I get: RPM build errors: File not found: /var/tmp/nagios-plugins-1.4-1-root-martijn/usr/lib/nagios/plugins/check_fping File not found: /var/tmp/nagios-plugins-1.4-1-root-martijn/usr/lib/nagios/plugins/check_game File not found: /var/tmp/nagios-plugins-1.4-1-root-martijn/usr/lib/nagios/plugins/check_radius Any clues? TIA, M4 ---------------------------------------------------------------------- >Comment By: M. Sean Finney (seanius) Date: 2005-09-19 11:01 Message: Logged In: YES user_id=226838 hi, i believe this problem is now fixed in 1.4.2, so i will close this bug. if you still have a problem building rpms from the latest source, we can re-open this bug or start another report ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-05-23 00:58 Message: Logged In: YES user_id=226838 hi, this problem is probably because the stuff needed to build those plugins do not exist on your system, but the plugins are listed in the files list of the spec file. i'll commit a fix in CVS, though i don't know what we'll do about the version in 1.4. i'll post a comment to the devel mailing list and see what the other folks think. ---------------------------------------------------------------------- Comment By: Martijn Lievaart (mappie) Date: 2005-02-06 08:59 Message: Logged In: YES user_id=984925 BTW, this is on FC1, although I don't think it matters. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1117037&group_id=29880 From noreply at sourceforge.net Mon Sep 19 08:37:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 19 08:37:26 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1189636 ] check_procs can't handle longer command names Message-ID: Bugs item #1189636, was opened at 2005-04-25 13:00 Message generated for change (Comment added) made by seanius You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1189636&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Disbrow (mdisbrow) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs can't handle longer command names Initial Comment: When using the -C parameter, process command names longer than 15 characters are not found. Since ps only outputs the first 15 characters of a process command name, checking a process with a name longer than 15 characters results in check_procs not finding any instances of the process and incorrectly returning 0 process instances. ---------------------------------------------------------------------- >Comment By: M. Sean Finney (seanius) Date: 2005-09-19 11:36 Message: Logged In: YES user_id=226838 hi mike, what operating system are you running on? also, could you give us the contents of your config.h? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1189636&group_id=29880 From noreply at sourceforge.net Mon Sep 19 09:22:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 19 09:22:26 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1291126 ] Alternate ps for Solaris Message-ID: Bugs item #1291126, was opened at 2005-09-14 12:04 Message generated for change (Comment added) made by seanius You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291126&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: CVS Status: Open Resolution: None Priority: 5 Submitted By: Bob Ingraham (rwingraham) Assigned to: Nobody/Anonymous (nobody) Summary: Alternate ps for Solaris Initial Comment: Per Sean, I am uploading the source for an alternate ps utility for Solaris that will work with the existing check_procs plugin. This alternate ps gets around the 80-character limitation inherent in the native ps for Solaris. It has been extensively testing on our corporate Solaris farm. Notes: 1. I've installed this alternate ps (called pst3) in the libexec directory, along with the other plugins. 2. It needs setuid-root permissions to run, but accepts no arguments and reads no input streams and therefore isn't subject to exploitations such as buffer overflow and the like. The only reason is needs the setuid-root permission is so that it can open the running kernel image, in READ-ONLY mode, in order to access the process argument vectors. 3. It requires a patch to the configuration file which substitutes this alternate utility instead of ps for Soalris systems. Bob ---------------------------------------------------------------------- >Comment By: M. Sean Finney (seanius) Date: 2005-09-19 11:27 Message: Logged In: YES user_id=226838 hi bob, thanks for this, i've just taken a look over it. if this program has to run setuid root to open the kmem structure, would it be possible to drop priviliges immediately after having done so? ton: what are your thoughts about dropping this utility in the libexec dir? i could throw together a pretty quick configure patch to decide whether or not the ps utility was needed. not sure how we're handling the other setuid programs, but i could follow suit with whatever we're doing for the others ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291126&group_id=29880 From C.Meissner at mc-wetter.de Tue Sep 20 00:05:01 2005 From: C.Meissner at mc-wetter.de (Christian Meissner) Date: Tue Sep 20 00:05:01 2005 Subject: [Nagiosplug-devel] supply new plugins Message-ID: <827F4DA483EF5F42B31E2E19E1A3112701089FC7@redmond.berlin.mc-wetter.de> how can i do this Chris From noreply at sourceforge.net Tue Sep 20 00:56:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 20 00:56:37 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1291126 ] Alternate ps for Solaris Message-ID: Bugs item #1291126, was opened at 2005-09-14 17:04 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291126&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: CVS Status: Open Resolution: None Priority: 5 Submitted By: Bob Ingraham (rwingraham) >Assigned to: M. Sean Finney (seanius) Summary: Alternate ps for Solaris Initial Comment: Per Sean, I am uploading the source for an alternate ps utility for Solaris that will work with the existing check_procs plugin. This alternate ps gets around the 80-character limitation inherent in the native ps for Solaris. It has been extensively testing on our corporate Solaris farm. Notes: 1. I've installed this alternate ps (called pst3) in the libexec directory, along with the other plugins. 2. It needs setuid-root permissions to run, but accepts no arguments and reads no input streams and therefore isn't subject to exploitations such as buffer overflow and the like. The only reason is needs the setuid-root permission is so that it can open the running kernel image, in READ-ONLY mode, in order to access the process argument vectors. 3. It requires a patch to the configuration file which substitutes this alternate utility instead of ps for Soalris systems. Bob ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2005-09-20 08:55 Message: Logged In: YES user_id=664364 Sean, I have no problem with setuid scripts since we already have check_icmp and check_dhcp, but they don't install as root at the moment (it is manually done). I am trying to separate setuid scripts out to plugins- root/ so then the installer can be configured to install with the correct permissions, but haven't fully tested my local copy yet. Give me another day to sort this out. Ton ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-19 16:27 Message: Logged In: YES user_id=226838 hi bob, thanks for this, i've just taken a look over it. if this program has to run setuid root to open the kmem structure, would it be possible to drop priviliges immediately after having done so? ton: what are your thoughts about dropping this utility in the libexec dir? i could throw together a pretty quick configure patch to decide whether or not the ps utility was needed. not sure how we're handling the other setuid programs, but i could follow suit with whatever we're doing for the others ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291126&group_id=29880 From noreply at sourceforge.net Tue Sep 20 03:21:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 20 03:21:17 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1296242 ] check_nagios 1.26 (plugins 1.4.2) not working with Nagios 2 Message-ID: Bugs item #1296242, was opened at 2005-09-20 12:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1296242&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Bimschas (bimschas) Assigned to: Nobody/Anonymous (nobody) Summary: check_nagios 1.26 (plugins 1.4.2) not working with Nagios 2 Initial Comment: Hi, the check_nagios plugin always gets the last_entry_time wrong when doing checks on NAGIOSHOME/var/status.dat. I made a little fix, my diff: 65,67c65 < char tag[] = "created="; < char *dummy = NULL; < --- > 92,97c90,94 < temp_ptr = strtok (input_buffer, tag); < temp_ptr = strtok (NULL,tag); < if (temp_ptr != NULL) { < latest_entry_time = strtoul (temp_ptr,NULL,10); < break; < } --- > temp_ptr = strtok (input_buffer, "]"); > temp_entry_time = > (temp_ptr == NULL) ? 0L : strtoul (temp_ptr + 1, NULL, 10); > if (temp_entry_time > latest_entry_time) > latest_entry_time = temp_entry_time; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1296242&group_id=29880 From noreply at sourceforge.net Tue Sep 20 03:37:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 20 03:37:17 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1296242 ] check_nagios 1.26 (plugins 1.4.2) not working with Nagios 2 Message-ID: Bugs item #1296242, was opened at 2005-09-20 11:20 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1296242&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Bimschas (bimschas) >Assigned to: Ton Voon (tonvoon) Summary: check_nagios 1.26 (plugins 1.4.2) not working with Nagios 2 Initial Comment: Hi, the check_nagios plugin always gets the last_entry_time wrong when doing checks on NAGIOSHOME/var/status.dat. I made a little fix, my diff: 65,67c65 < char tag[] = "created="; < char *dummy = NULL; < --- > 92,97c90,94 < temp_ptr = strtok (input_buffer, tag); < temp_ptr = strtok (NULL,tag); < if (temp_ptr != NULL) { < latest_entry_time = strtoul (temp_ptr,NULL,10); < break; < } --- > temp_ptr = strtok (input_buffer, "]"); > temp_entry_time = > (temp_ptr == NULL) ? 0L : strtoul (temp_ptr + 1, NULL, 10); > if (temp_entry_time > latest_entry_time) > latest_entry_time = temp_entry_time; ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2005-09-20 11:36 Message: Logged In: YES user_id=664364 Daniel, Thanks for the patch. Can you attach a diff -u output please as these are easier to parse. Also, could you attach an extract of status.dat please (I don't have access to a Nagios 2 version). Ideally, we want a check_nagios which can read either nagios1 or nagios2 format, so if you can provide a patch that can handle both, it will definitely go in. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1296242&group_id=29880 From noreply at sourceforge.net Tue Sep 20 04:22:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 20 04:22:24 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1296296 ] check_nwstat does not return correct values since 1.4 Message-ID: Bugs item #1296296, was opened at 2005-09-20 12:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1296296&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: David Sullivan (sullivand) Assigned to: Nobody/Anonymous (nobody) Summary: check_nwstat does not return correct values since 1.4 Initial Comment: check_nwstat seems to be majorly broken since 1.4 returning only the default initialised value of the variable requested instead of the actual value. The plugin with version 1.3.1 works correctly. I've tried the most recent version (1.4.2) and it still exhibits the same behaviour: support:~# /usr/local/src/nagios-plugins-1.4.2/plugins/check_nwstat -p 9999 -o -H server -v "ABENDS" -c 1 -o NetWare 5.60.5: 0 abended threads support:~# /usr/local/src/nagios-plugins-1.3.1/plugins/check_nwstat -p 9999 -o -H server -v "ABENDS" -c 1 -o NetWare 5.60.5: 1 abended threads support:~# /usr/local/src/nagios-plugins-1.4.2/plugins/check_nwstat -p 9999 -o -H server -v "LOAD5" -w 70 -c 90 NetWare 5.60.5: Load OK - Up , 5-min load average = 0% support:~# /usr/local/src/nagios-plugins-1.3.1/plugins/check_nwstat -p 9999 -o -H server -v "LOAD5" -w 70 -c 90 NetWare 5.60.5: Load problem - Up 48 days 1 hours 49 minutes, 5-min load average = 74% A packet trace is attached showing that the plugin connects to the service and requests the Netware Version, then when it re-uses the same socket for the variable requested it sends the request but immediately closes the connection without waiting for a response from mrtgext. I might be able to set up an accessable netware server to test this plugin if this is necessary but that would take a day or two to setup. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1296296&group_id=29880 From noreply at sourceforge.net Tue Sep 20 04:32:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 20 04:32:33 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1296296 ] check_nwstat does not return correct values since 1.4 Message-ID: Bugs item #1296296, was opened at 2005-09-20 12:21 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1296296&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None >Priority: 7 Submitted By: David Sullivan (sullivand) >Assigned to: Ton Voon (tonvoon) Summary: check_nwstat does not return correct values since 1.4 Initial Comment: check_nwstat seems to be majorly broken since 1.4 returning only the default initialised value of the variable requested instead of the actual value. The plugin with version 1.3.1 works correctly. I've tried the most recent version (1.4.2) and it still exhibits the same behaviour: support:~# /usr/local/src/nagios-plugins-1.4.2/plugins/check_nwstat -p 9999 -o -H server -v "ABENDS" -c 1 -o NetWare 5.60.5: 0 abended threads support:~# /usr/local/src/nagios-plugins-1.3.1/plugins/check_nwstat -p 9999 -o -H server -v "ABENDS" -c 1 -o NetWare 5.60.5: 1 abended threads support:~# /usr/local/src/nagios-plugins-1.4.2/plugins/check_nwstat -p 9999 -o -H server -v "LOAD5" -w 70 -c 90 NetWare 5.60.5: Load OK - Up , 5-min load average = 0% support:~# /usr/local/src/nagios-plugins-1.3.1/plugins/check_nwstat -p 9999 -o -H server -v "LOAD5" -w 70 -c 90 NetWare 5.60.5: Load problem - Up 48 days 1 hours 49 minutes, 5-min load average = 74% A packet trace is attached showing that the plugin connects to the service and requests the Netware Version, then when it re-uses the same socket for the variable requested it sends the request but immediately closes the connection without waiting for a response from mrtgext. I might be able to set up an accessable netware server to test this plugin if this is necessary but that would take a day or two to setup. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2005-09-20 12:31 Message: Logged In: YES user_id=664364 David, Thanks for your report. Unfortunately, I don't think anyone on the team has access to a Netware server. If you create a patch, I'll visually inspect it and will apply to the latest plugins. It would be great if you could create a test case as well for it (see the other test cases in plugins/t). Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1296296&group_id=29880 From ton.voon at altinity.com Tue Sep 20 04:51:16 2005 From: ton.voon at altinity.com (Ton Voon) Date: Tue Sep 20 04:51:16 2005 Subject: [Nagiosplug-devel] Undeliverable email Message-ID: <369A019C-C115-4C0B-9376-75E5ABC123FE@altinity.com> Just a little warning - I'm going to start unsubscribing addresses from this list if email is not deliverable. This is because I'm getting loads of Undeliverable messages whenever something gets sent. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From noreply at sourceforge.net Tue Sep 20 06:25:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 20 06:25:04 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1296296 ] check_nwstat does not return correct values since 1.4 Message-ID: Bugs item #1296296, was opened at 2005-09-20 12:21 Message generated for change (Comment added) made by sullivand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1296296&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 7 Submitted By: David Sullivan (sullivand) Assigned to: Ton Voon (tonvoon) Summary: check_nwstat does not return correct values since 1.4 Initial Comment: check_nwstat seems to be majorly broken since 1.4 returning only the default initialised value of the variable requested instead of the actual value. The plugin with version 1.3.1 works correctly. I've tried the most recent version (1.4.2) and it still exhibits the same behaviour: support:~# /usr/local/src/nagios-plugins-1.4.2/plugins/check_nwstat -p 9999 -o -H server -v "ABENDS" -c 1 -o NetWare 5.60.5: 0 abended threads support:~# /usr/local/src/nagios-plugins-1.3.1/plugins/check_nwstat -p 9999 -o -H server -v "ABENDS" -c 1 -o NetWare 5.60.5: 1 abended threads support:~# /usr/local/src/nagios-plugins-1.4.2/plugins/check_nwstat -p 9999 -o -H server -v "LOAD5" -w 70 -c 90 NetWare 5.60.5: Load OK - Up , 5-min load average = 0% support:~# /usr/local/src/nagios-plugins-1.3.1/plugins/check_nwstat -p 9999 -o -H server -v "LOAD5" -w 70 -c 90 NetWare 5.60.5: Load problem - Up 48 days 1 hours 49 minutes, 5-min load average = 74% A packet trace is attached showing that the plugin connects to the service and requests the Netware Version, then when it re-uses the same socket for the variable requested it sends the request but immediately closes the connection without waiting for a response from mrtgext. I might be able to set up an accessable netware server to test this plugin if this is necessary but that would take a day or two to setup. ---------------------------------------------------------------------- >Comment By: David Sullivan (sullivand) Date: 2005-09-20 14:24 Message: Logged In: YES user_id=1348152 Ah, a bit more digging on my part through the mrtgext code indicates that the assumption that the connection can be re-used ( as 1.4 was modified to do ) is just wrong. From the comments in the sourcecode for mrtgext.c (http://shrunk.net/7a5dea59-forge.novell.com) : // read in the tcp stream until we get a \n, a line length of // 1024 or a TCP Timeout. After mrtgext sees the first command and \n it will do no more. Adding: close(sd); my_tcp_connect (server_address, server_port, &sd); liberally all over the code confirms this and essentially takes it back to how it behaved in 1.3, this seems like an easy fix though I only know a little C I can create a patch if you want. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-09-20 12:31 Message: Logged In: YES user_id=664364 David, Thanks for your report. Unfortunately, I don't think anyone on the team has access to a Netware server. If you create a patch, I'll visually inspect it and will apply to the latest plugins. It would be great if you could create a test case as well for it (see the other test cases in plugins/t). Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1296296&group_id=29880 From noreply at sourceforge.net Tue Sep 20 08:15:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 20 08:15:12 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1296497 ] problem with check_procs in configure.in Message-ID: Bugs item #1296497, was opened at 2005-09-20 17:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1296497&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 Submitted By: Pascal (larisch_p) Assigned to: Nobody/Anonymous (nobody) Summary: problem with check_procs in configure.in Initial Comment: #> grep '&procpid,&procpid' configure.in ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid, &procvsz,&procrss,&procpcpu,procprog,&pos]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid, &procvsz,&procpcpu,procprog,&pos]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid, &procvsz,&procrss,&procpcpu,procprog,&pos]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid, &procvsz,&procrss,&procpcpu,procprog,&pos]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid, &procvsz,&procrss,&procpcpu,procprog,&pos]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid, &procvsz,&procrss,&procpcpu,procprog,&pos]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid, &procvsz,&procrss,&pos,procprog]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid,&pos, procprog]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid,&pos, procprog]" ac_cv_ps_varlist="[&procuid,&procpid,&procpid,&procvsz, &procrss,procstat,&pos,procprog]" ac_cv_ps_varlist="[procstat,&procvsz,&procrss,&procuid, &procpid,&procpid,&procpcpu,procprog,&pos]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid,&pos, procprog]" I think this should be '&procpid,&procppid' Version: 1.4.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1296497&group_id=29880 From noreply at sourceforge.net Tue Sep 20 09:08:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 20 09:08:19 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1296497 ] problem with check_procs in configure.in Message-ID: Bugs item #1296497, was opened at 2005-09-20 16:14 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1296497&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 Submitted By: Pascal (larisch_p) >Assigned to: Ton Voon (tonvoon) Summary: problem with check_procs in configure.in Initial Comment: #> grep '&procpid,&procpid' configure.in ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid, &procvsz,&procrss,&procpcpu,procprog,&pos]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid, &procvsz,&procpcpu,procprog,&pos]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid, &procvsz,&procrss,&procpcpu,procprog,&pos]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid, &procvsz,&procrss,&procpcpu,procprog,&pos]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid, &procvsz,&procrss,&procpcpu,procprog,&pos]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid, &procvsz,&procrss,&procpcpu,procprog,&pos]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid, &procvsz,&procrss,&pos,procprog]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid,&pos, procprog]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid,&pos, procprog]" ac_cv_ps_varlist="[&procuid,&procpid,&procpid,&procvsz, &procrss,procstat,&pos,procprog]" ac_cv_ps_varlist="[procstat,&procvsz,&procrss,&procuid, &procpid,&procpid,&procpcpu,procprog,&pos]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid,&pos, procprog]" I think this should be '&procpid,&procppid' Version: 1.4.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1296497&group_id=29880 From noreply at sourceforge.net Tue Sep 20 09:13:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 20 09:13:11 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1296497 ] problem with check_procs in configure.in Message-ID: Bugs item #1296497, was opened at 2005-09-20 16:14 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1296497&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Pascal (larisch_p) Assigned to: Ton Voon (tonvoon) Summary: problem with check_procs in configure.in Initial Comment: #> grep '&procpid,&procpid' configure.in ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid, &procvsz,&procrss,&procpcpu,procprog,&pos]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid, &procvsz,&procpcpu,procprog,&pos]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid, &procvsz,&procrss,&procpcpu,procprog,&pos]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid, &procvsz,&procrss,&procpcpu,procprog,&pos]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid, &procvsz,&procrss,&procpcpu,procprog,&pos]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid, &procvsz,&procrss,&procpcpu,procprog,&pos]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid, &procvsz,&procrss,&pos,procprog]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid,&pos, procprog]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid,&pos, procprog]" ac_cv_ps_varlist="[&procuid,&procpid,&procpid,&procvsz, &procrss,procstat,&pos,procprog]" ac_cv_ps_varlist="[procstat,&procvsz,&procrss,&procuid, &procpid,&procpid,&procpcpu,procprog,&pos]" ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procpid,&pos, procprog]" I think this should be '&procpid,&procppid' Version: 1.4.2 ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2005-09-20 17:12 Message: Logged In: YES user_id=664364 Pascal, Thanks for the report. You are correct, the ppid is missing. Applied to CVS now. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1296497&group_id=29880 From benoit.mortier at opensides.be Tue Sep 20 09:55:20 2005 From: benoit.mortier at opensides.be (Benoit Mortier) Date: Tue Sep 20 09:55:20 2005 Subject: [Nagiosplug-devel] include Andreas Ericsson patch in the nagios plugins Message-ID: <200509201854.06931.benoit.mortier@opensides.be> Hello, i was looking at andreas Ericsson fork of the plugins and i wanted to put most of it's changed in the official nagios plugins. Could i do that, does someone disagree ? Cheers -- Benoit Mortier CEO www.opensides.be From ton.voon at altinity.com Tue Sep 20 13:41:26 2005 From: ton.voon at altinity.com (Ton Voon) Date: Tue Sep 20 13:41:26 2005 Subject: [Nagiosplug-devel] include Andreas Ericsson patch in the nagios plugins In-Reply-To: <200509201854.06931.benoit.mortier@opensides.be> References: <200509201854.06931.benoit.mortier@opensides.be> Message-ID: <305AB8E0-1924-452D-BC01-35919ECE9D15@altinity.com> On 20 Sep 2005, at 17:54, Benoit Mortier wrote: > i was looking at andreas Ericsson fork of the plugins and i wanted > to put > most of it's changed in the official nagios plugins. > > Could i do that, does someone disagree ? Benoit, As long as any particular patch does not go against the aims of the project, I'm happy for you to apply. I leave the decision to you. If you are unsure, we can discuss in this mailing list. My preference would be for fixes first - before any enhancements - especially if there is an outstanding bug listed in SF. Make sure Andreas' changes are credited in the change log. In terms of code breakage, I've been chatting offline with Peter Bray about setting up a Tinderbox server to run weekly builds and tests of the plugins. I think we need something like that, especially since the plugins are using such a diverse set of libraries, on a large set of OSes. This should give a confidence factor when major changes are made that we haven't broken anything. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From seanius at seanius.net Tue Sep 20 14:29:10 2005 From: seanius at seanius.net (sean finney) Date: Tue Sep 20 14:29:10 2005 Subject: [Nagiosplug-devel] include Andreas Ericsson patch in the nagios plugins In-Reply-To: <200509201854.06931.benoit.mortier@opensides.be> References: <200509201854.06931.benoit.mortier@opensides.be> Message-ID: <20050920212817.GA726@seanius.net> hi benoit, On Tue, Sep 20, 2005 at 06:54:06PM +0200, Benoit Mortier wrote: > i was looking at andreas Ericsson fork of the plugins and i wanted to put > most of it's changed in the official nagios plugins. > > Could i do that, does someone disagree ? andreas and i were supposed to manage brining in this code (primarily the runcmd framework), but i haven't heard from him in some time. granted i haven't exactly been banging down his door either :) andreas: what do you say we get things moving on this? sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From noreply at sourceforge.net Tue Sep 20 18:42:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 20 18:42:11 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1297134 ] postfix addition for check_mailq Message-ID: Patches item #1297134, was opened at 2005-09-21 01:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1297134&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Submitted By: mrnetops (mrnetops) Assigned to: Nobody/Anonymous (nobody) Summary: postfix addition for check_mailq Initial Comment: patch allows check_mailq to grok both sendmail & postfix version of mailq ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1297134&group_id=29880 From ton.voon at altinity.com Wed Sep 21 03:14:26 2005 From: ton.voon at altinity.com (Ton Voon) Date: Wed Sep 21 03:14:26 2005 Subject: [Nagiosplug-devel] Root setuid plugins Message-ID: Just to let you know that I have created a plugins-root/ at the top level. The idea is that root setuid executables are compiled here. If make install is run as root, then the correct permissions should be set. I think you have to run "cvs update -d" to pull in the new subdirectory. Something I've noticed is that the plugins don't appear to be installed as nagios user and group anymore. Does anyone know what the best way of fixing this is? Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From noreply at sourceforge.net Wed Sep 21 03:16:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 21 03:16:12 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1291126 ] Alternate ps for Solaris Message-ID: Bugs item #1291126, was opened at 2005-09-14 17:04 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291126&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: CVS Status: Open Resolution: None Priority: 5 Submitted By: Bob Ingraham (rwingraham) Assigned to: M. Sean Finney (seanius) Summary: Alternate ps for Solaris Initial Comment: Per Sean, I am uploading the source for an alternate ps utility for Solaris that will work with the existing check_procs plugin. This alternate ps gets around the 80-character limitation inherent in the native ps for Solaris. It has been extensively testing on our corporate Solaris farm. Notes: 1. I've installed this alternate ps (called pst3) in the libexec directory, along with the other plugins. 2. It needs setuid-root permissions to run, but accepts no arguments and reads no input streams and therefore isn't subject to exploitations such as buffer overflow and the like. The only reason is needs the setuid-root permission is so that it can open the running kernel image, in READ-ONLY mode, in order to access the process argument vectors. 3. It requires a patch to the configuration file which substitutes this alternate utility instead of ps for Soalris systems. Bob ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2005-09-21 11:14 Message: Logged In: YES user_id=664364 Sean, plugins-root/ is created now. This would be the best place to put pst3. Ton ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-09-20 08:55 Message: Logged In: YES user_id=664364 Sean, I have no problem with setuid scripts since we already have check_icmp and check_dhcp, but they don't install as root at the moment (it is manually done). I am trying to separate setuid scripts out to plugins- root/ so then the installer can be configured to install with the correct permissions, but haven't fully tested my local copy yet. Give me another day to sort this out. Ton ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-19 16:27 Message: Logged In: YES user_id=226838 hi bob, thanks for this, i've just taken a look over it. if this program has to run setuid root to open the kmem structure, would it be possible to drop priviliges immediately after having done so? ton: what are your thoughts about dropping this utility in the libexec dir? i could throw together a pretty quick configure patch to decide whether or not the ps utility was needed. not sure how we're handling the other setuid programs, but i could follow suit with whatever we're doing for the others ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291126&group_id=29880 From noreply at sourceforge.net Wed Sep 21 03:31:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 21 03:31:04 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1296296 ] check_nwstat does not return correct values since 1.4 Message-ID: Bugs item #1296296, was opened at 2005-09-20 12:21 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1296296&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 7 Submitted By: David Sullivan (sullivand) Assigned to: Ton Voon (tonvoon) Summary: check_nwstat does not return correct values since 1.4 Initial Comment: check_nwstat seems to be majorly broken since 1.4 returning only the default initialised value of the variable requested instead of the actual value. The plugin with version 1.3.1 works correctly. I've tried the most recent version (1.4.2) and it still exhibits the same behaviour: support:~# /usr/local/src/nagios-plugins-1.4.2/plugins/check_nwstat -p 9999 -o -H server -v "ABENDS" -c 1 -o NetWare 5.60.5: 0 abended threads support:~# /usr/local/src/nagios-plugins-1.3.1/plugins/check_nwstat -p 9999 -o -H server -v "ABENDS" -c 1 -o NetWare 5.60.5: 1 abended threads support:~# /usr/local/src/nagios-plugins-1.4.2/plugins/check_nwstat -p 9999 -o -H server -v "LOAD5" -w 70 -c 90 NetWare 5.60.5: Load OK - Up , 5-min load average = 0% support:~# /usr/local/src/nagios-plugins-1.3.1/plugins/check_nwstat -p 9999 -o -H server -v "LOAD5" -w 70 -c 90 NetWare 5.60.5: Load problem - Up 48 days 1 hours 49 minutes, 5-min load average = 74% A packet trace is attached showing that the plugin connects to the service and requests the Netware Version, then when it re-uses the same socket for the variable requested it sends the request but immediately closes the connection without waiting for a response from mrtgext. I might be able to set up an accessable netware server to test this plugin if this is necessary but that would take a day or two to setup. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2005-09-21 11:29 Message: Logged In: YES user_id=664364 David, It looks like check_nwstat.c was changed from 1.13 to 1.14 to reuse the connection (see http://cvs.sourceforge.net/viewcvs.py/nagiosplug/ nagiosplug/plugins/check_nwstat.c?rev=1.30&view=log and the diff between 1.14 and 1.13). Unfortunately, there's not much information on why it was changed. Gerd Mueller supplied a patch (1235879) that includes lots of close(sd) and my_tcp_connect, so it sounds like that could be right line to go down. As I'm working in the dark on this, I would prefer to receive a diff -u patch that you have verified will work so I can apply to CVS. I'm happy to discuss how to do this offline with you. Ton ---------------------------------------------------------------------- Comment By: David Sullivan (sullivand) Date: 2005-09-20 14:24 Message: Logged In: YES user_id=1348152 Ah, a bit more digging on my part through the mrtgext code indicates that the assumption that the connection can be re-used ( as 1.4 was modified to do ) is just wrong. From the comments in the sourcecode for mrtgext.c (http://shrunk.net/7a5dea59-forge.novell.com) : // read in the tcp stream until we get a \n, a line length of // 1024 or a TCP Timeout. After mrtgext sees the first command and \n it will do no more. Adding: close(sd); my_tcp_connect (server_address, server_port, &sd); liberally all over the code confirms this and essentially takes it back to how it behaved in 1.3, this seems like an easy fix though I only know a little C I can create a patch if you want. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-09-20 12:31 Message: Logged In: YES user_id=664364 David, Thanks for your report. Unfortunately, I don't think anyone on the team has access to a Netware server. If you create a patch, I'll visually inspect it and will apply to the latest plugins. It would be great if you could create a test case as well for it (see the other test cases in plugins/t). Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1296296&group_id=29880 From noreply at sourceforge.net Wed Sep 21 03:34:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 21 03:34:55 2005 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-1297523 ] checks state of drbd devices Message-ID: New Plugins item #1297523, was opened at 2005-09-21 10:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=1297523&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: Perl plugin Group: None Status: Open Resolution: None Priority: 5 Submitted By: MC-Wetter GmbH (mcw-edv) Assigned to: Nobody/Anonymous (nobody) Summary: checks state of drbd devices Initial Comment: analyse the strings which `cat /proc/drbd` print out ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=1297523&group_id=29880 From noreply at sourceforge.net Wed Sep 21 03:36:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 21 03:36:27 2005 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-1297525 ] check_heartbeat Message-ID: New Plugins item #1297525, was opened at 2005-09-21 10:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=1297525&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: Perl plugin Group: None Status: Open Resolution: None Priority: 5 Submitted By: MC-Wetter GmbH (mcw-edv) Assigned to: Nobody/Anonymous (nobody) Summary: check_heartbeat Initial Comment: counts the running heartbeat processes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=1297525&group_id=29880 From noreply at sourceforge.net Wed Sep 21 04:26:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 21 04:26:01 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1296296 ] check_nwstat does not return correct values since 1.4 Message-ID: Bugs item #1296296, was opened at 2005-09-20 12:21 Message generated for change (Comment added) made by sullivand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1296296&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 7 Submitted By: David Sullivan (sullivand) Assigned to: Ton Voon (tonvoon) Summary: check_nwstat does not return correct values since 1.4 Initial Comment: check_nwstat seems to be majorly broken since 1.4 returning only the default initialised value of the variable requested instead of the actual value. The plugin with version 1.3.1 works correctly. I've tried the most recent version (1.4.2) and it still exhibits the same behaviour: support:~# /usr/local/src/nagios-plugins-1.4.2/plugins/check_nwstat -p 9999 -o -H server -v "ABENDS" -c 1 -o NetWare 5.60.5: 0 abended threads support:~# /usr/local/src/nagios-plugins-1.3.1/plugins/check_nwstat -p 9999 -o -H server -v "ABENDS" -c 1 -o NetWare 5.60.5: 1 abended threads support:~# /usr/local/src/nagios-plugins-1.4.2/plugins/check_nwstat -p 9999 -o -H server -v "LOAD5" -w 70 -c 90 NetWare 5.60.5: Load OK - Up , 5-min load average = 0% support:~# /usr/local/src/nagios-plugins-1.3.1/plugins/check_nwstat -p 9999 -o -H server -v "LOAD5" -w 70 -c 90 NetWare 5.60.5: Load problem - Up 48 days 1 hours 49 minutes, 5-min load average = 74% A packet trace is attached showing that the plugin connects to the service and requests the Netware Version, then when it re-uses the same socket for the variable requested it sends the request but immediately closes the connection without waiting for a response from mrtgext. I might be able to set up an accessable netware server to test this plugin if this is necessary but that would take a day or two to setup. ---------------------------------------------------------------------- >Comment By: David Sullivan (sullivand) Date: 2005-09-21 12:23 Message: Logged In: YES user_id=1348152 I've added code closing the socket before each use which has done the trick. I've tested that it works for the variables ABENDS, LOAD5, CBUFF and VPF and they all produce correct output. The diff is attached to this bug David ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-09-21 11:29 Message: Logged In: YES user_id=664364 David, It looks like check_nwstat.c was changed from 1.13 to 1.14 to reuse the connection (see http://cvs.sourceforge.net/viewcvs.py/nagiosplug/ nagiosplug/plugins/check_nwstat.c?rev=1.30&view=log and the diff between 1.14 and 1.13). Unfortunately, there's not much information on why it was changed. Gerd Mueller supplied a patch (1235879) that includes lots of close(sd) and my_tcp_connect, so it sounds like that could be right line to go down. As I'm working in the dark on this, I would prefer to receive a diff -u patch that you have verified will work so I can apply to CVS. I'm happy to discuss how to do this offline with you. Ton ---------------------------------------------------------------------- Comment By: David Sullivan (sullivand) Date: 2005-09-20 14:24 Message: Logged In: YES user_id=1348152 Ah, a bit more digging on my part through the mrtgext code indicates that the assumption that the connection can be re-used ( as 1.4 was modified to do ) is just wrong. From the comments in the sourcecode for mrtgext.c (http://shrunk.net/7a5dea59-forge.novell.com) : // read in the tcp stream until we get a \n, a line length of // 1024 or a TCP Timeout. After mrtgext sees the first command and \n it will do no more. Adding: close(sd); my_tcp_connect (server_address, server_port, &sd); liberally all over the code confirms this and essentially takes it back to how it behaved in 1.3, this seems like an easy fix though I only know a little C I can create a patch if you want. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-09-20 12:31 Message: Logged In: YES user_id=664364 David, Thanks for your report. Unfortunately, I don't think anyone on the team has access to a Netware server. If you create a patch, I'll visually inspect it and will apply to the latest plugins. It would be great if you could create a test case as well for it (see the other test cases in plugins/t). Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1296296&group_id=29880 From noreply at sourceforge.net Wed Sep 21 05:06:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 21 05:06:33 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1297601 ] add check_snmp_mgeups.pl Message-ID: Patches item #1297601, was opened at 2005-09-21 04:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1297601&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Submitted By: arnaud quette (uzuul) Assigned to: Nobody/Anonymous (nobody) Summary: add check_snmp_mgeups.pl Initial Comment: the attached (unified format) patch adds check_snmp_mgeups.pl to the plugins-scripts/ directory. The plugins-scripts/Makefile.am has been updated accordingly. The upstream author (Ignacio Barrientos) has also been added to the THANKS.in file. Thanks to apply for the next release. Arnaud Quette -- Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt OpenSource Developer - http://arnaud.quette.free.fr/ Debian Developer - http://people.debian.org/~aquette/ ... and much more ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1297601&group_id=29880 From noreply at sourceforge.net Wed Sep 21 06:06:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 21 06:06:46 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1296296 ] check_nwstat does not return correct values since 1.4 Message-ID: Bugs item #1296296, was opened at 2005-09-20 12:21 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1296296&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: Fixed Priority: 7 Submitted By: David Sullivan (sullivand) Assigned to: Ton Voon (tonvoon) Summary: check_nwstat does not return correct values since 1.4 Initial Comment: check_nwstat seems to be majorly broken since 1.4 returning only the default initialised value of the variable requested instead of the actual value. The plugin with version 1.3.1 works correctly. I've tried the most recent version (1.4.2) and it still exhibits the same behaviour: support:~# /usr/local/src/nagios-plugins-1.4.2/plugins/check_nwstat -p 9999 -o -H server -v "ABENDS" -c 1 -o NetWare 5.60.5: 0 abended threads support:~# /usr/local/src/nagios-plugins-1.3.1/plugins/check_nwstat -p 9999 -o -H server -v "ABENDS" -c 1 -o NetWare 5.60.5: 1 abended threads support:~# /usr/local/src/nagios-plugins-1.4.2/plugins/check_nwstat -p 9999 -o -H server -v "LOAD5" -w 70 -c 90 NetWare 5.60.5: Load OK - Up , 5-min load average = 0% support:~# /usr/local/src/nagios-plugins-1.3.1/plugins/check_nwstat -p 9999 -o -H server -v "LOAD5" -w 70 -c 90 NetWare 5.60.5: Load problem - Up 48 days 1 hours 49 minutes, 5-min load average = 74% A packet trace is attached showing that the plugin connects to the service and requests the Netware Version, then when it re-uses the same socket for the variable requested it sends the request but immediately closes the connection without waiting for a response from mrtgext. I might be able to set up an accessable netware server to test this plugin if this is necessary but that would take a day or two to setup. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2005-09-21 14:05 Message: Logged In: YES user_id=664364 David, Thanks. Applied to CVS now. Ton ---------------------------------------------------------------------- Comment By: David Sullivan (sullivand) Date: 2005-09-21 12:23 Message: Logged In: YES user_id=1348152 I've added code closing the socket before each use which has done the trick. I've tested that it works for the variables ABENDS, LOAD5, CBUFF and VPF and they all produce correct output. The diff is attached to this bug David ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-09-21 11:29 Message: Logged In: YES user_id=664364 David, It looks like check_nwstat.c was changed from 1.13 to 1.14 to reuse the connection (see http://cvs.sourceforge.net/viewcvs.py/nagiosplug/ nagiosplug/plugins/check_nwstat.c?rev=1.30&view=log and the diff between 1.14 and 1.13). Unfortunately, there's not much information on why it was changed. Gerd Mueller supplied a patch (1235879) that includes lots of close(sd) and my_tcp_connect, so it sounds like that could be right line to go down. As I'm working in the dark on this, I would prefer to receive a diff -u patch that you have verified will work so I can apply to CVS. I'm happy to discuss how to do this offline with you. Ton ---------------------------------------------------------------------- Comment By: David Sullivan (sullivand) Date: 2005-09-20 14:24 Message: Logged In: YES user_id=1348152 Ah, a bit more digging on my part through the mrtgext code indicates that the assumption that the connection can be re-used ( as 1.4 was modified to do ) is just wrong. From the comments in the sourcecode for mrtgext.c (http://shrunk.net/7a5dea59-forge.novell.com) : // read in the tcp stream until we get a \n, a line length of // 1024 or a TCP Timeout. After mrtgext sees the first command and \n it will do no more. Adding: close(sd); my_tcp_connect (server_address, server_port, &sd); liberally all over the code confirms this and essentially takes it back to how it behaved in 1.3, this seems like an easy fix though I only know a little C I can create a patch if you want. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-09-20 12:31 Message: Logged In: YES user_id=664364 David, Thanks for your report. Unfortunately, I don't think anyone on the team has access to a Netware server. If you create a patch, I'll visually inspect it and will apply to the latest plugins. It would be great if you could create a test case as well for it (see the other test cases in plugins/t). Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1296296&group_id=29880 From noreply at sourceforge.net Wed Sep 21 11:48:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 21 11:48:27 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1218438 ] check_radius.c: In function `main': Message-ID: Bugs item #1218438, was opened at 2005-06-10 14:34 Message generated for change (Comment added) made by coder7 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1218438&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 Submitted By: S?bastien Guay (sebasguay) Assigned to: M. Sean Finney (seanius) Summary: check_radius.c: In function `main': Initial Comment: When trying to compile on slackware I got the following check_radius.c: In function `main': check_radius.c:126: error: too few arguments to function `rc_avpair_add' check_radius.c:127: error: too few arguments to function `rc_avpair_add' check_radius.c:128: error: too few arguments to function `rc_avpair_add' check_radius.c:129: error: too few arguments to function `rc_avpair_add' check_radius.c:139: error: too few arguments to function `rc_avpair_add' check_radius.c:145: error: too few arguments to function `rc_send_server' make[2]: *** [check_radius.o] Error 1 make[2]: Leaving directory `/usr/local/src/nagios-plugins-1.4/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/nagios-plugins-1.4' make: *** [all] Error 2 I uninstalled the package ppp-2.4.2-i486-2 and redo a make and all was fine. After I reinstalled ppp-2.4.2-i486-2. ppp-2.4.2-i486-2 has a file radiusclient.h. S?bas ---------------------------------------------------------------------- Comment By: Bradley Hook (coder7) Date: 2005-09-21 13:47 Message: Logged In: YES user_id=903812 Can we get a small note added to the README until a more permanent solution is found? I will submit this to the Slackware people to see if the radiusclient.h is even needed in the ppp package, they might be able to remove it or move it. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-07-14 06:25 Message: Logged In: YES user_id=226838 hi, thanks for the extra info. i'll try and look more into this in the next couple of weeks, and see if i can do some voodoo in autoconf to determine the correct prototypes and version of radiusclient. ---------------------------------------------------------------------- Comment By: John Warburton (johnwarburton) Date: 2005-07-13 20:05 Message: Logged In: YES user_id=1192023 Hi Guys The problem isn't specific to Slackware. It is anyone that runs with newer versions of the radiusclient library. The REQUIREMENTS file says they can be found at http://www.cityline.net/~lf/radius/ versions radiusclient-0.3.1-1 That website no longer exists, but I have tracked down the developer to http://developer.berlios.de/projects/radiusclient-ng/ I was getting the same compile time errors on Solaris 8 with radiusclient-0.4.9 as S?bastien. I downloaded an earlier client library - radiusclient-0.3.3, which compiled, but I have no idea on configuring, so doesn't seem to work. It seems to me the radius client library has moved on, but the Nagios plugin hasn't. Since my site has moved to openradius, I will just use a very simple shell script as a plugin to attempt login using the openradius "radclient" program. Regards John ---------------------------------------------------------------------- Comment By: S?bastien Guay (sebasguay) Date: 2005-07-05 13:11 Message: Logged In: YES user_id=265586 Hi Sean, > this looks like a problem with slackware or the slackware > package of ppp then. where is the radiusclient.h provided > by your libradius package (or whatever the slackware > equivalent is that provides radiusclient.h)? The file radiusclient.h is part of the package ppp (or I misunderstood your question?). > i'm not sure why installing ppp would plop an include file > used to build ppp in a compiler accessible directory in the > first place, Not sure either :) > but unless you can provide a convincing reason > why this is a problem with the nagios plugins, i'm going to > close out the bug in a week's time. My goal was not to convince anybody, it was just to let you know that any Slackware user may have a problem to compile nagios plugins if they have the ppp package installed. As I said, the problem was easily solved on my side by uninstalling ppp and re-installing it after. Here's the definition of rc_avpair_add() function in the radiusclient.h file in the ppp package VALUE_PAIR *rc_avpair_add __P((VALUE_PAIR **, int, void *, int, int)); and here's the call of rc_avpair_add in check_radius.c rc_avpair_add (&data.send_pairs, PW_SERVICE_TYPE, &service, 0) I don't know anything about libradius. Do you know what is the *supposed* arguments number for rc_avpair_add()? If it's 4, I can send a bug report to Patrick. The radiusclient.h file is in attach. S?bas ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-06-27 21:06 Message: Logged In: YES user_id=226838 hi sebastien, this looks like a problem with slackware or the slackware package of ppp then. where is the radiusclient.h provided by your libradius package (or whatever the slackware equivalent is that provides radiusclient.h)? i'm not sure why installing ppp would plop an include file used to build ppp in a compiler accessible directory in the first place, but unless you can provide a convincing reason why this is a problem with the nagios plugins, i'm going to close out the bug in a week's time. thanks, sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1218438&group_id=29880 From ae at op5.se Wed Sep 21 12:14:11 2005 From: ae at op5.se (Andreas Ericsson) Date: Wed Sep 21 12:14:11 2005 Subject: [Nagiosplug-devel] Root setuid plugins In-Reply-To: References: Message-ID: <4331B0BF.3050904@op5.se> Ton Voon wrote: > Just to let you know that I have created a plugins-root/ at the top > level. The idea is that root setuid executables are compiled here. > > If make install is run as root, then the correct permissions should be > set. > > I think you have to run "cvs update -d" to pull in the new subdirectory. > > Something I've noticed is that the plugins don't appear to be installed > as nagios user and group anymore. Does anyone know what the best way of > fixing this is? > Don't. Installing them as 755 is perfectly sane. If the install is done as root, the plugins-root (or plugins/suid, as we use for target - exchange plugins for libexec in the official package) should have the mode 4711 and be owned by root. The paranoid should set chattr +a on that directory. The plugins-root makefile should barf on install if id -u != 0. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Lead Developer From ae at op5.se Wed Sep 21 12:24:11 2005 From: ae at op5.se (Andreas Ericsson) Date: Wed Sep 21 12:24:11 2005 Subject: [Nagiosplug-devel] include Andreas Ericsson patch in the nagios plugins In-Reply-To: <20050920212817.GA726@seanius.net> References: <200509201854.06931.benoit.mortier@opensides.be> <20050920212817.GA726@seanius.net> Message-ID: <4331B31D.7040907@op5.se> sean finney wrote: > hi benoit, > > On Tue, Sep 20, 2005 at 06:54:06PM +0200, Benoit Mortier wrote: > >>i was looking at andreas Ericsson fork of the plugins and i wanted to put >>most of it's changed in the official nagios plugins. >> >>Could i do that, does someone disagree ? > > > andreas and i were supposed to manage brining in this code (primarily > the runcmd framework), but i haven't heard from him in some time. granted > i haven't exactly been banging down his door either :) > > andreas: what do you say we get things moving on this? > I'm all for it, but I haven't quite managed to get rid of all the asprintf()'s and stuff like that yet, and I'm currently implementing an argument evaluation thingie which will make translations a lot easier and the code a lot leaner. Also, I'm facing a rather nasty build-bug with some older systems (AIX, notably) which fails because rpl_realloc() isn't built in the library but required in some files. The current official distro has that last problem too, btw, although 1.3.1 doesn't. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Lead Developer From seanius at seanius.net Thu Sep 22 02:00:39 2005 From: seanius at seanius.net (sean finney) Date: Thu Sep 22 02:00:39 2005 Subject: [Nagiosplug-devel] include Andreas Ericsson patch in the nagios plugins In-Reply-To: <4331B31D.7040907@op5.se> References: <200509201854.06931.benoit.mortier@opensides.be> <20050920212817.GA726@seanius.net> <4331B31D.7040907@op5.se> Message-ID: <20050922085806.GA19377@seanius.net> On Wed, Sep 21, 2005 at 09:23:09PM +0200, Andreas Ericsson wrote: > I'm all for it, but I haven't quite managed to get rid of all the > asprintf()'s and stuff like that yet, and I'm currently implementing an > argument evaluation thingie which will make translations a lot easier > and the code a lot leaner. cool. do you think you could throw me a tarball with the most recent revsion to the np_runcmd stuff? sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From noreply at sourceforge.net Thu Sep 22 02:17:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 22 02:17:25 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1291126 ] Alternate ps for Solaris Message-ID: Bugs item #1291126, was opened at 2005-09-14 12:04 Message generated for change (Comment added) made by seanius You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291126&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: CVS Status: Open Resolution: None Priority: 5 Submitted By: Bob Ingraham (rwingraham) Assigned to: M. Sean Finney (seanius) Summary: Alternate ps for Solaris Initial Comment: Per Sean, I am uploading the source for an alternate ps utility for Solaris that will work with the existing check_procs plugin. This alternate ps gets around the 80-character limitation inherent in the native ps for Solaris. It has been extensively testing on our corporate Solaris farm. Notes: 1. I've installed this alternate ps (called pst3) in the libexec directory, along with the other plugins. 2. It needs setuid-root permissions to run, but accepts no arguments and reads no input streams and therefore isn't subject to exploitations such as buffer overflow and the like. The only reason is needs the setuid-root permission is so that it can open the running kernel image, in READ-ONLY mode, in order to access the process argument vectors. 3. It requires a patch to the configuration file which substitutes this alternate utility instead of ps for Soalris systems. Bob ---------------------------------------------------------------------- >Comment By: M. Sean Finney (seanius) Date: 2005-09-22 05:16 Message: Logged In: YES user_id=226838 hi bob, ton, i just finished looking over the script, and it looks good. unfortunately i no longer have root access to a solaris server, so i can't install the plugin setuid root. i can still throw together everything else (the configure patch, etc), but the final test will need to be conducted by someone else. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-09-21 06:14 Message: Logged In: YES user_id=664364 Sean, plugins-root/ is created now. This would be the best place to put pst3. Ton ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-09-20 03:55 Message: Logged In: YES user_id=664364 Sean, I have no problem with setuid scripts since we already have check_icmp and check_dhcp, but they don't install as root at the moment (it is manually done). I am trying to separate setuid scripts out to plugins- root/ so then the installer can be configured to install with the correct permissions, but haven't fully tested my local copy yet. Give me another day to sort this out. Ton ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-19 11:27 Message: Logged In: YES user_id=226838 hi bob, thanks for this, i've just taken a look over it. if this program has to run setuid root to open the kmem structure, would it be possible to drop priviliges immediately after having done so? ton: what are your thoughts about dropping this utility in the libexec dir? i could throw together a pretty quick configure patch to decide whether or not the ps utility was needed. not sure how we're handling the other setuid programs, but i could follow suit with whatever we're doing for the others ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291126&group_id=29880 From ae at op5.se Thu Sep 22 02:21:36 2005 From: ae at op5.se (Andreas Ericsson) Date: Thu Sep 22 02:21:36 2005 Subject: [Nagiosplug-devel] include Andreas Ericsson patch in the nagios plugins In-Reply-To: <20050922085806.GA19377@seanius.net> References: <200509201854.06931.benoit.mortier@opensides.be> <20050920212817.GA726@seanius.net> <4331B31D.7040907@op5.se> <20050922085806.GA19377@seanius.net> Message-ID: <4332776C.7020705@op5.se> sean finney wrote: > On Wed, Sep 21, 2005 at 09:23:09PM +0200, Andreas Ericsson wrote: > >>I'm all for it, but I haven't quite managed to get rid of all the >>asprintf()'s and stuff like that yet, and I'm currently implementing an >>argument evaluation thingie which will make translations a lot easier >>and the code a lot leaner. > > > cool. do you think you could throw me a tarball with the most recent > revsion to the np_runcmd stuff? > That would be the one at http://oss.op5.se/nagios For the eval_arg_* stuff, I haven't gotten far enough yet, so it'll have to wait for a bit. I'll be working on it today though, so tonight I'll most likely have at least something ready for a bit of peer review, and implemented in one plugin for demonstration purposes. For the current multiplexing (daemon-mode) runcmd stuff, I haven't had time to post it anywhere yet, and my ISP is kind enough to block incoming ssh-connections to me (stupid, stupid, stupid). -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Lead Developer From noreply at sourceforge.net Thu Sep 22 02:33:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 22 02:33:47 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1291126 ] Alternate ps for Solaris Message-ID: Bugs item #1291126, was opened at 2005-09-14 12:04 Message generated for change (Comment added) made by seanius You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291126&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: CVS Status: Open Resolution: None Priority: 5 Submitted By: Bob Ingraham (rwingraham) Assigned to: M. Sean Finney (seanius) Summary: Alternate ps for Solaris Initial Comment: Per Sean, I am uploading the source for an alternate ps utility for Solaris that will work with the existing check_procs plugin. This alternate ps gets around the 80-character limitation inherent in the native ps for Solaris. It has been extensively testing on our corporate Solaris farm. Notes: 1. I've installed this alternate ps (called pst3) in the libexec directory, along with the other plugins. 2. It needs setuid-root permissions to run, but accepts no arguments and reads no input streams and therefore isn't subject to exploitations such as buffer overflow and the like. The only reason is needs the setuid-root permission is so that it can open the running kernel image, in READ-ONLY mode, in order to access the process argument vectors. 3. It requires a patch to the configuration file which substitutes this alternate utility instead of ps for Soalris systems. Bob ---------------------------------------------------------------------- >Comment By: M. Sean Finney (seanius) Date: 2005-09-22 05:32 Message: Logged In: YES user_id=226838 btw: why isn't pPsInfo->pr_pid included in the output? ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-22 05:16 Message: Logged In: YES user_id=226838 hi bob, ton, i just finished looking over the script, and it looks good. unfortunately i no longer have root access to a solaris server, so i can't install the plugin setuid root. i can still throw together everything else (the configure patch, etc), but the final test will need to be conducted by someone else. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-09-21 06:14 Message: Logged In: YES user_id=664364 Sean, plugins-root/ is created now. This would be the best place to put pst3. Ton ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-09-20 03:55 Message: Logged In: YES user_id=664364 Sean, I have no problem with setuid scripts since we already have check_icmp and check_dhcp, but they don't install as root at the moment (it is manually done). I am trying to separate setuid scripts out to plugins- root/ so then the installer can be configured to install with the correct permissions, but haven't fully tested my local copy yet. Give me another day to sort this out. Ton ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-19 11:27 Message: Logged In: YES user_id=226838 hi bob, thanks for this, i've just taken a look over it. if this program has to run setuid root to open the kmem structure, would it be possible to drop priviliges immediately after having done so? ton: what are your thoughts about dropping this utility in the libexec dir? i could throw together a pretty quick configure patch to decide whether or not the ps utility was needed. not sure how we're handling the other setuid programs, but i could follow suit with whatever we're doing for the others ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291126&group_id=29880 From seanius at seanius.net Thu Sep 22 03:31:31 2005 From: seanius at seanius.net (sean finney) Date: Thu Sep 22 03:31:31 2005 Subject: [Nagiosplug-devel] include Andreas Ericsson patch in the nagios plugins In-Reply-To: <4332776C.7020705@op5.se> References: <200509201854.06931.benoit.mortier@opensides.be> <20050920212817.GA726@seanius.net> <4331B31D.7040907@op5.se> <20050922085806.GA19377@seanius.net> <4332776C.7020705@op5.se> Message-ID: <20050922103017.GA20349@seanius.net> On Thu, Sep 22, 2005 at 11:20:44AM +0200, Andreas Ericsson wrote: > >cool. do you think you could throw me a tarball with the most recent > >revsion to the np_runcmd stuff? > > > > That would be the one at http://oss.op5.se/nagios yes, well this morning connections to that host were timing out :) anyway, i'll check it out, thanks. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From noreply at sourceforge.net Thu Sep 22 04:42:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 22 04:42:46 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1291126 ] Alternate ps for Solaris Message-ID: Bugs item #1291126, was opened at 2005-09-14 12:04 Message generated for change (Comment added) made by seanius You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291126&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: CVS Status: Open Resolution: None Priority: 5 Submitted By: Bob Ingraham (rwingraham) Assigned to: M. Sean Finney (seanius) Summary: Alternate ps for Solaris Initial Comment: Per Sean, I am uploading the source for an alternate ps utility for Solaris that will work with the existing check_procs plugin. This alternate ps gets around the 80-character limitation inherent in the native ps for Solaris. It has been extensively testing on our corporate Solaris farm. Notes: 1. I've installed this alternate ps (called pst3) in the libexec directory, along with the other plugins. 2. It needs setuid-root permissions to run, but accepts no arguments and reads no input streams and therefore isn't subject to exploitations such as buffer overflow and the like. The only reason is needs the setuid-root permission is so that it can open the running kernel image, in READ-ONLY mode, in order to access the process argument vectors. 3. It requires a patch to the configuration file which substitutes this alternate utility instead of ps for Soalris systems. Bob ---------------------------------------------------------------------- >Comment By: M. Sean Finney (seanius) Date: 2005-09-22 07:40 Message: Logged In: YES user_id=226838 slight complication, i'll email the list with details... ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-22 05:32 Message: Logged In: YES user_id=226838 btw: why isn't pPsInfo->pr_pid included in the output? ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-22 05:16 Message: Logged In: YES user_id=226838 hi bob, ton, i just finished looking over the script, and it looks good. unfortunately i no longer have root access to a solaris server, so i can't install the plugin setuid root. i can still throw together everything else (the configure patch, etc), but the final test will need to be conducted by someone else. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-09-21 06:14 Message: Logged In: YES user_id=664364 Sean, plugins-root/ is created now. This would be the best place to put pst3. Ton ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-09-20 03:55 Message: Logged In: YES user_id=664364 Sean, I have no problem with setuid scripts since we already have check_icmp and check_dhcp, but they don't install as root at the moment (it is manually done). I am trying to separate setuid scripts out to plugins- root/ so then the installer can be configured to install with the correct permissions, but haven't fully tested my local copy yet. Give me another day to sort this out. Ton ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-19 11:27 Message: Logged In: YES user_id=226838 hi bob, thanks for this, i've just taken a look over it. if this program has to run setuid root to open the kmem structure, would it be possible to drop priviliges immediately after having done so? ton: what are your thoughts about dropping this utility in the libexec dir? i could throw together a pretty quick configure patch to decide whether or not the ps utility was needed. not sure how we're handling the other setuid programs, but i could follow suit with whatever we're doing for the others ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291126&group_id=29880 From seanius at seanius.net Thu Sep 22 05:10:58 2005 From: seanius at seanius.net (sean finney) Date: Thu Sep 22 05:10:58 2005 Subject: [Nagiosplug-devel] complication executing one plugin by another Message-ID: <20050922120854.GA21452@seanius.net> if you've read the subject, you may be thinking "why the hell would you want to do that?" one example is the latest modification i've made (or half-made, hence the email) to check_procs, to call the pst3 program submitted by bob ingraham, which will also reside in the plugin installation dir. the problem is that to execute pst3, one has to either supply the full path or assume that it is in the path. the problem with the latter is that it probably will not be in the system path, and the problem with the former is that i can't figure out a good way to supply the path to the plugin. so, i see a couple iof options here: - modify configure.in, config.h and/or Makefile.am's to pass the information at compile-time - modify check_procs to include the pst3 code natively, making this a moot issue. comments? in the meantime, i'll leave the CVS HEAD configure.in script with ac_cv_ps_command="pst3" (no path), so if someone cares they can copy the binary into their paths. if i don't hear back, i think i'll try and work with option 2. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From noreply at sourceforge.net Thu Sep 22 10:16:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 22 10:16:46 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1218438 ] check_radius.c: In function `main': Message-ID: Bugs item #1218438, was opened at 2005-06-10 14:34 Message generated for change (Comment added) made by coder7 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1218438&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 Submitted By: S?bastien Guay (sebasguay) Assigned to: M. Sean Finney (seanius) Summary: check_radius.c: In function `main': Initial Comment: When trying to compile on slackware I got the following check_radius.c: In function `main': check_radius.c:126: error: too few arguments to function `rc_avpair_add' check_radius.c:127: error: too few arguments to function `rc_avpair_add' check_radius.c:128: error: too few arguments to function `rc_avpair_add' check_radius.c:129: error: too few arguments to function `rc_avpair_add' check_radius.c:139: error: too few arguments to function `rc_avpair_add' check_radius.c:145: error: too few arguments to function `rc_send_server' make[2]: *** [check_radius.o] Error 1 make[2]: Leaving directory `/usr/local/src/nagios-plugins-1.4/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/nagios-plugins-1.4' make: *** [all] Error 2 I uninstalled the package ppp-2.4.2-i486-2 and redo a make and all was fine. After I reinstalled ppp-2.4.2-i486-2. ppp-2.4.2-i486-2 has a file radiusclient.h. S?bas ---------------------------------------------------------------------- Comment By: Bradley Hook (coder7) Date: 2005-09-22 12:13 Message: Logged In: YES user_id=903812 Just an update to my previous post. I emailed the distribution maintainer for Slackware, Patrick Volkerding. Here is his response: ---begin quote--- Generally I won't move header files since their location should be up to the upstream maintainer(s), not me. In this case the version of radiusclient is rather old though, and perhaps it's useless to everyone anyway and should simply be removed. You might try writing to them to see if they have an opinion about it, though. Also, even if I were to keep the functional parts of the included radiusclient I could remove the header, .a library, and .so symlink if everyone is using radiusclient-ng to compile against now anyway. Anyway, thanks for the info. I'll ponder a bit whether radiusclient is useless on Slackware. (it is to me, but... :) ---end quote--- ---------------------------------------------------------------------- Comment By: Bradley Hook (coder7) Date: 2005-09-21 13:47 Message: Logged In: YES user_id=903812 Can we get a small note added to the README until a more permanent solution is found? I will submit this to the Slackware people to see if the radiusclient.h is even needed in the ppp package, they might be able to remove it or move it. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-07-14 06:25 Message: Logged In: YES user_id=226838 hi, thanks for the extra info. i'll try and look more into this in the next couple of weeks, and see if i can do some voodoo in autoconf to determine the correct prototypes and version of radiusclient. ---------------------------------------------------------------------- Comment By: John Warburton (johnwarburton) Date: 2005-07-13 20:05 Message: Logged In: YES user_id=1192023 Hi Guys The problem isn't specific to Slackware. It is anyone that runs with newer versions of the radiusclient library. The REQUIREMENTS file says they can be found at http://www.cityline.net/~lf/radius/ versions radiusclient-0.3.1-1 That website no longer exists, but I have tracked down the developer to http://developer.berlios.de/projects/radiusclient-ng/ I was getting the same compile time errors on Solaris 8 with radiusclient-0.4.9 as S?bastien. I downloaded an earlier client library - radiusclient-0.3.3, which compiled, but I have no idea on configuring, so doesn't seem to work. It seems to me the radius client library has moved on, but the Nagios plugin hasn't. Since my site has moved to openradius, I will just use a very simple shell script as a plugin to attempt login using the openradius "radclient" program. Regards John ---------------------------------------------------------------------- Comment By: S?bastien Guay (sebasguay) Date: 2005-07-05 13:11 Message: Logged In: YES user_id=265586 Hi Sean, > this looks like a problem with slackware or the slackware > package of ppp then. where is the radiusclient.h provided > by your libradius package (or whatever the slackware > equivalent is that provides radiusclient.h)? The file radiusclient.h is part of the package ppp (or I misunderstood your question?). > i'm not sure why installing ppp would plop an include file > used to build ppp in a compiler accessible directory in the > first place, Not sure either :) > but unless you can provide a convincing reason > why this is a problem with the nagios plugins, i'm going to > close out the bug in a week's time. My goal was not to convince anybody, it was just to let you know that any Slackware user may have a problem to compile nagios plugins if they have the ppp package installed. As I said, the problem was easily solved on my side by uninstalling ppp and re-installing it after. Here's the definition of rc_avpair_add() function in the radiusclient.h file in the ppp package VALUE_PAIR *rc_avpair_add __P((VALUE_PAIR **, int, void *, int, int)); and here's the call of rc_avpair_add in check_radius.c rc_avpair_add (&data.send_pairs, PW_SERVICE_TYPE, &service, 0) I don't know anything about libradius. Do you know what is the *supposed* arguments number for rc_avpair_add()? If it's 4, I can send a bug report to Patrick. The radiusclient.h file is in attach. S?bas ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-06-27 21:06 Message: Logged In: YES user_id=226838 hi sebastien, this looks like a problem with slackware or the slackware package of ppp then. where is the radiusclient.h provided by your libradius package (or whatever the slackware equivalent is that provides radiusclient.h)? i'm not sure why installing ppp would plop an include file used to build ppp in a compiler accessible directory in the first place, but unless you can provide a convincing reason why this is a problem with the nagios plugins, i'm going to close out the bug in a week's time. thanks, sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1218438&group_id=29880 From noreply at sourceforge.net Thu Sep 22 12:21:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 22 12:21:07 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1291126 ] Alternate ps for Solaris Message-ID: Bugs item #1291126, was opened at 2005-09-14 10:04 Message generated for change (Comment added) made by rwingraham You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291126&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: CVS Status: Open Resolution: None Priority: 5 Submitted By: Bob Ingraham (rwingraham) Assigned to: M. Sean Finney (seanius) Summary: Alternate ps for Solaris Initial Comment: Per Sean, I am uploading the source for an alternate ps utility for Solaris that will work with the existing check_procs plugin. This alternate ps gets around the 80-character limitation inherent in the native ps for Solaris. It has been extensively testing on our corporate Solaris farm. Notes: 1. I've installed this alternate ps (called pst3) in the libexec directory, along with the other plugins. 2. It needs setuid-root permissions to run, but accepts no arguments and reads no input streams and therefore isn't subject to exploitations such as buffer overflow and the like. The only reason is needs the setuid-root permission is so that it can open the running kernel image, in READ-ONLY mode, in order to access the process argument vectors. 3. It requires a patch to the configuration file which substitutes this alternate utility instead of ps for Soalris systems. Bob ---------------------------------------------------------------------- >Comment By: Bob Ingraham (rwingraham) Date: 2005-09-22 13:20 Message: Logged In: YES user_id=1086870 Sean, To answer your previous posts (sorry for the delay - I've been slammed at work,): 1. why isn't pPsInfo->pr_pid included in the output? I designed pst3 to exactly duplicate the output columns produced by the output produced by the original Solaris ps command: /usr/bin/ps -Ao 's uid ppid vsz rss pcpu comm args' You'll notice that Parent-PID is requested (ppid) but not the current process PID (pid). According to the source for check_procs, you can search for children of a parent PID (hence the ppid,) or you can search for a username/uid (hence the uid). But apparetnly, the option is not provided to search for just a PID. 2. You need root access on a Solaris server. I have a Solaris box I can test you config changes on. 3. Can I drop privileges after opening the kernel image? I don't know if it will work. That would depend upon whether the subsequent kvm_* calls also check the effective UID of the caller or not. Do you still want me to try this? Bob ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-22 05:40 Message: Logged In: YES user_id=226838 slight complication, i'll email the list with details... ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-22 03:32 Message: Logged In: YES user_id=226838 btw: why isn't pPsInfo->pr_pid included in the output? ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-22 03:16 Message: Logged In: YES user_id=226838 hi bob, ton, i just finished looking over the script, and it looks good. unfortunately i no longer have root access to a solaris server, so i can't install the plugin setuid root. i can still throw together everything else (the configure patch, etc), but the final test will need to be conducted by someone else. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-09-21 04:14 Message: Logged In: YES user_id=664364 Sean, plugins-root/ is created now. This would be the best place to put pst3. Ton ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-09-20 01:55 Message: Logged In: YES user_id=664364 Sean, I have no problem with setuid scripts since we already have check_icmp and check_dhcp, but they don't install as root at the moment (it is manually done). I am trying to separate setuid scripts out to plugins- root/ so then the installer can be configured to install with the correct permissions, but haven't fully tested my local copy yet. Give me another day to sort this out. Ton ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-19 09:27 Message: Logged In: YES user_id=226838 hi bob, thanks for this, i've just taken a look over it. if this program has to run setuid root to open the kmem structure, would it be possible to drop priviliges immediately after having done so? ton: what are your thoughts about dropping this utility in the libexec dir? i could throw together a pretty quick configure patch to decide whether or not the ps utility was needed. not sure how we're handling the other setuid programs, but i could follow suit with whatever we're doing for the others ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291126&group_id=29880 From noreply at sourceforge.net Thu Sep 22 12:37:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 22 12:37:11 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1218438 ] check_radius.c: In function `main': Message-ID: Bugs item #1218438, was opened at 2005-06-10 13:34 Message generated for change (Comment added) made by rwingraham You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1218438&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 Submitted By: S?bastien Guay (sebasguay) Assigned to: M. Sean Finney (seanius) Summary: check_radius.c: In function `main': Initial Comment: When trying to compile on slackware I got the following check_radius.c: In function `main': check_radius.c:126: error: too few arguments to function `rc_avpair_add' check_radius.c:127: error: too few arguments to function `rc_avpair_add' check_radius.c:128: error: too few arguments to function `rc_avpair_add' check_radius.c:129: error: too few arguments to function `rc_avpair_add' check_radius.c:139: error: too few arguments to function `rc_avpair_add' check_radius.c:145: error: too few arguments to function `rc_send_server' make[2]: *** [check_radius.o] Error 1 make[2]: Leaving directory `/usr/local/src/nagios-plugins-1.4/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/nagios-plugins-1.4' make: *** [all] Error 2 I uninstalled the package ppp-2.4.2-i486-2 and redo a make and all was fine. After I reinstalled ppp-2.4.2-i486-2. ppp-2.4.2-i486-2 has a file radiusclient.h. S?bas ---------------------------------------------------------------------- Comment By: Bob Ingraham (rwingraham) Date: 2005-09-22 13:36 Message: Logged In: YES user_id=1086870 I ran into this same problem. The current radiusclient library (radiusclient-ng) has an updated API which requires a "config-file-handle" first argument to most of the API entry points. I've updated check_radius.c to adhere to the new radiusclient- ng API conventions. Assuming that you have this current library installed, then check_radius.c compiles and link cleanly now. I don't see where I can attach the updated check_radius.c file as an upload with this comment... Let me know how I can send it in without opening a new case. Note also that the configure script needs to be updated to check for libradisclient-ng (instead of libradiusclient). Bob ---------------------------------------------------------------------- Comment By: Bradley Hook (coder7) Date: 2005-09-22 11:13 Message: Logged In: YES user_id=903812 Just an update to my previous post. I emailed the distribution maintainer for Slackware, Patrick Volkerding. Here is his response: ---begin quote--- Generally I won't move header files since their location should be up to the upstream maintainer(s), not me. In this case the version of radiusclient is rather old though, and perhaps it's useless to everyone anyway and should simply be removed. You might try writing to them to see if they have an opinion about it, though. Also, even if I were to keep the functional parts of the included radiusclient I could remove the header, .a library, and .so symlink if everyone is using radiusclient-ng to compile against now anyway. Anyway, thanks for the info. I'll ponder a bit whether radiusclient is useless on Slackware. (it is to me, but... :) ---end quote--- ---------------------------------------------------------------------- Comment By: Bradley Hook (coder7) Date: 2005-09-21 12:47 Message: Logged In: YES user_id=903812 Can we get a small note added to the README until a more permanent solution is found? I will submit this to the Slackware people to see if the radiusclient.h is even needed in the ppp package, they might be able to remove it or move it. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-07-14 05:25 Message: Logged In: YES user_id=226838 hi, thanks for the extra info. i'll try and look more into this in the next couple of weeks, and see if i can do some voodoo in autoconf to determine the correct prototypes and version of radiusclient. ---------------------------------------------------------------------- Comment By: John Warburton (johnwarburton) Date: 2005-07-13 19:05 Message: Logged In: YES user_id=1192023 Hi Guys The problem isn't specific to Slackware. It is anyone that runs with newer versions of the radiusclient library. The REQUIREMENTS file says they can be found at http://www.cityline.net/~lf/radius/ versions radiusclient-0.3.1-1 That website no longer exists, but I have tracked down the developer to http://developer.berlios.de/projects/radiusclient-ng/ I was getting the same compile time errors on Solaris 8 with radiusclient-0.4.9 as S?bastien. I downloaded an earlier client library - radiusclient-0.3.3, which compiled, but I have no idea on configuring, so doesn't seem to work. It seems to me the radius client library has moved on, but the Nagios plugin hasn't. Since my site has moved to openradius, I will just use a very simple shell script as a plugin to attempt login using the openradius "radclient" program. Regards John ---------------------------------------------------------------------- Comment By: S?bastien Guay (sebasguay) Date: 2005-07-05 12:11 Message: Logged In: YES user_id=265586 Hi Sean, > this looks like a problem with slackware or the slackware > package of ppp then. where is the radiusclient.h provided > by your libradius package (or whatever the slackware > equivalent is that provides radiusclient.h)? The file radiusclient.h is part of the package ppp (or I misunderstood your question?). > i'm not sure why installing ppp would plop an include file > used to build ppp in a compiler accessible directory in the > first place, Not sure either :) > but unless you can provide a convincing reason > why this is a problem with the nagios plugins, i'm going to > close out the bug in a week's time. My goal was not to convince anybody, it was just to let you know that any Slackware user may have a problem to compile nagios plugins if they have the ppp package installed. As I said, the problem was easily solved on my side by uninstalling ppp and re-installing it after. Here's the definition of rc_avpair_add() function in the radiusclient.h file in the ppp package VALUE_PAIR *rc_avpair_add __P((VALUE_PAIR **, int, void *, int, int)); and here's the call of rc_avpair_add in check_radius.c rc_avpair_add (&data.send_pairs, PW_SERVICE_TYPE, &service, 0) I don't know anything about libradius. Do you know what is the *supposed* arguments number for rc_avpair_add()? If it's 4, I can send a bug report to Patrick. The radiusclient.h file is in attach. S?bas ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-06-27 20:06 Message: Logged In: YES user_id=226838 hi sebastien, this looks like a problem with slackware or the slackware package of ppp then. where is the radiusclient.h provided by your libradius package (or whatever the slackware equivalent is that provides radiusclient.h)? i'm not sure why installing ppp would plop an include file used to build ppp in a compiler accessible directory in the first place, but unless you can provide a convincing reason why this is a problem with the nagios plugins, i'm going to close out the bug in a week's time. thanks, sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1218438&group_id=29880 From noreply at sourceforge.net Thu Sep 22 12:44:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 22 12:44:02 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1218438 ] check_radius.c: In function `main': Message-ID: Bugs item #1218438, was opened at 2005-06-10 13:34 Message generated for change (Comment added) made by rwingraham You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1218438&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 Submitted By: S?bastien Guay (sebasguay) Assigned to: M. Sean Finney (seanius) Summary: check_radius.c: In function `main': Initial Comment: When trying to compile on slackware I got the following check_radius.c: In function `main': check_radius.c:126: error: too few arguments to function `rc_avpair_add' check_radius.c:127: error: too few arguments to function `rc_avpair_add' check_radius.c:128: error: too few arguments to function `rc_avpair_add' check_radius.c:129: error: too few arguments to function `rc_avpair_add' check_radius.c:139: error: too few arguments to function `rc_avpair_add' check_radius.c:145: error: too few arguments to function `rc_send_server' make[2]: *** [check_radius.o] Error 1 make[2]: Leaving directory `/usr/local/src/nagios-plugins-1.4/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/nagios-plugins-1.4' make: *** [all] Error 2 I uninstalled the package ppp-2.4.2-i486-2 and redo a make and all was fine. After I reinstalled ppp-2.4.2-i486-2. ppp-2.4.2-i486-2 has a file radiusclient.h. S?bas ---------------------------------------------------------------------- Comment By: Bob Ingraham (rwingraham) Date: 2005-09-22 13:42 Message: Logged In: YES user_id=1086870 Here's the patch to check_radius.c in 'diff -u' format: --- check_radius.c.ORIGINAL 2004-12-25 16:17:44.000000000 -0700 +++ check_radius.c 2005-09-19 16:03:49.000000000 - 0600 @@ -27,7 +27,7 @@ #include "utils.h" #include "netutils.h" -#include +#include int process_arguments (int, char **); void print_help (void); @@ -108,6 +108,7 @@ int result = STATE_UNKNOWN; UINT4 client_id; char *str; + rc_handle *rch = NULL; setlocale (LC_ALL, ""); bindtextdomain (PACKAGE, LOCALEDIR); @@ -117,32 +118,32 @@ usage4 (_("Could not parse arguments")); str = strdup ("dictionary"); - if ((config_file && rc_read_config (config_file)) || - rc_read_dictionary (rc_conf_str (str))) + if ((config_file && (rch = rc_read_config (config_file))) || + rc_read_dictionary (rch, rc_conf_str (rch, str))) die (STATE_UNKNOWN, _("Config file error")); service = PW_AUTHENTICATE_ONLY; - if (!(rc_avpair_add (&data.send_pairs, PW_SERVICE_TYPE, &service, 0) && - rc_avpair_add (&data.send_pairs, PW_USER_NAME, username, 0) && - rc_avpair_add (&data.send_pairs, PW_USER_PASSWORD, password, 0) && - (nasid==NULL || rc_avpair_add (&data.send_pairs, PW_NAS_IDENTIFIER, nasid, 0)))) + if (!(rc_avpair_add (rch, &data.send_pairs, PW_SERVICE_TYPE, &service, -1, 0) && + rc_avpair_add (rch, &data.send_pairs, PW_USER_NAME, username, -1, 0) && + rc_avpair_add (rch, &data.send_pairs, PW_USER_PASSWORD, password, -1, 0) && + (nasid==NULL || rc_avpair_add (rch, &data.send_pairs, PW_NAS_IDENTIFIER, nasid, -1, 0)))) die (STATE_UNKNOWN, _("Out of Memory?")); /* * Fill in NAS-IP-Address */ - if ((client_id = rc_own_ipaddress ()) == 0) + if ((client_id = rc_own_ipaddress (rch)) == 0) return (ERROR_RC); - if (rc_avpair_add (&(data.send_pairs), PW_NAS_IP_ADDRESS, &client_id, 0) == + if (rc_avpair_add (rch, &(data.send_pairs), PW_NAS_IP_ADDRESS, &client_id, -1, 0) == NULL) return (ERROR_RC); - rc_buildreq (&data, PW_ACCESS_REQUEST, server, port, (int)timeout_interval, + rc_buildreq (rch, &data, PW_ACCESS_REQUEST, server, port, (int)timeout_interval, retries); - result = rc_send_server (&data, msg); + result = rc_send_server (rch, &data, msg); rc_avpair_free (data.send_pairs); if (data.receive_pairs) rc_avpair_free (data.receive_pairs); ---------------------------------------------------------------------- Comment By: Bob Ingraham (rwingraham) Date: 2005-09-22 13:36 Message: Logged In: YES user_id=1086870 I ran into this same problem. The current radiusclient library (radiusclient-ng) has an updated API which requires a "config-file-handle" first argument to most of the API entry points. I've updated check_radius.c to adhere to the new radiusclient- ng API conventions. Assuming that you have this current library installed, then check_radius.c compiles and link cleanly now. I don't see where I can attach the updated check_radius.c file as an upload with this comment... Let me know how I can send it in without opening a new case. Note also that the configure script needs to be updated to check for libradisclient-ng (instead of libradiusclient). Bob ---------------------------------------------------------------------- Comment By: Bradley Hook (coder7) Date: 2005-09-22 11:13 Message: Logged In: YES user_id=903812 Just an update to my previous post. I emailed the distribution maintainer for Slackware, Patrick Volkerding. Here is his response: ---begin quote--- Generally I won't move header files since their location should be up to the upstream maintainer(s), not me. In this case the version of radiusclient is rather old though, and perhaps it's useless to everyone anyway and should simply be removed. You might try writing to them to see if they have an opinion about it, though. Also, even if I were to keep the functional parts of the included radiusclient I could remove the header, .a library, and .so symlink if everyone is using radiusclient-ng to compile against now anyway. Anyway, thanks for the info. I'll ponder a bit whether radiusclient is useless on Slackware. (it is to me, but... :) ---end quote--- ---------------------------------------------------------------------- Comment By: Bradley Hook (coder7) Date: 2005-09-21 12:47 Message: Logged In: YES user_id=903812 Can we get a small note added to the README until a more permanent solution is found? I will submit this to the Slackware people to see if the radiusclient.h is even needed in the ppp package, they might be able to remove it or move it. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-07-14 05:25 Message: Logged In: YES user_id=226838 hi, thanks for the extra info. i'll try and look more into this in the next couple of weeks, and see if i can do some voodoo in autoconf to determine the correct prototypes and version of radiusclient. ---------------------------------------------------------------------- Comment By: John Warburton (johnwarburton) Date: 2005-07-13 19:05 Message: Logged In: YES user_id=1192023 Hi Guys The problem isn't specific to Slackware. It is anyone that runs with newer versions of the radiusclient library. The REQUIREMENTS file says they can be found at http://www.cityline.net/~lf/radius/ versions radiusclient-0.3.1-1 That website no longer exists, but I have tracked down the developer to http://developer.berlios.de/projects/radiusclient-ng/ I was getting the same compile time errors on Solaris 8 with radiusclient-0.4.9 as S?bastien. I downloaded an earlier client library - radiusclient-0.3.3, which compiled, but I have no idea on configuring, so doesn't seem to work. It seems to me the radius client library has moved on, but the Nagios plugin hasn't. Since my site has moved to openradius, I will just use a very simple shell script as a plugin to attempt login using the openradius "radclient" program. Regards John ---------------------------------------------------------------------- Comment By: S?bastien Guay (sebasguay) Date: 2005-07-05 12:11 Message: Logged In: YES user_id=265586 Hi Sean, > this looks like a problem with slackware or the slackware > package of ppp then. where is the radiusclient.h provided > by your libradius package (or whatever the slackware > equivalent is that provides radiusclient.h)? The file radiusclient.h is part of the package ppp (or I misunderstood your question?). > i'm not sure why installing ppp would plop an include file > used to build ppp in a compiler accessible directory in the > first place, Not sure either :) > but unless you can provide a convincing reason > why this is a problem with the nagios plugins, i'm going to > close out the bug in a week's time. My goal was not to convince anybody, it was just to let you know that any Slackware user may have a problem to compile nagios plugins if they have the ppp package installed. As I said, the problem was easily solved on my side by uninstalling ppp and re-installing it after. Here's the definition of rc_avpair_add() function in the radiusclient.h file in the ppp package VALUE_PAIR *rc_avpair_add __P((VALUE_PAIR **, int, void *, int, int)); and here's the call of rc_avpair_add in check_radius.c rc_avpair_add (&data.send_pairs, PW_SERVICE_TYPE, &service, 0) I don't know anything about libradius. Do you know what is the *supposed* arguments number for rc_avpair_add()? If it's 4, I can send a bug report to Patrick. The radiusclient.h file is in attach. S?bas ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-06-27 20:06 Message: Logged In: YES user_id=226838 hi sebastien, this looks like a problem with slackware or the slackware package of ppp then. where is the radiusclient.h provided by your libradius package (or whatever the slackware equivalent is that provides radiusclient.h)? i'm not sure why installing ppp would plop an include file used to build ppp in a compiler accessible directory in the first place, but unless you can provide a convincing reason why this is a problem with the nagios plugins, i'm going to close out the bug in a week's time. thanks, sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1218438&group_id=29880 From bobi at netshel.net Thu Sep 22 13:33:22 2005 From: bobi at netshel.net (Bob Ingraham) Date: Thu Sep 22 13:33:22 2005 Subject: [Nagiosplug-devel] complication executing one plugin by another In-Reply-To: <20050922120854.GA21452@seanius.net> References: <20050922120854.GA21452@seanius.net> Message-ID: <28770.12.110.19.97.1127421015.squirrel@12.110.19.97> I have an idea... :-) It seems to me that the plugins are always executed with full path information contained in argv[0], since the nrpe.cfg file usually contains the full path information and this is what nrpe use to exec() these plugins. Therefore, if you know that you want to execute a fellow plugin (why does that not sound right? ;-) ), then all you need do is extract the full path info from main's argv[0] vector, and use that to construct the path the "peer" plugin. Something like: #define PS_COMMAND "pst3" /* From config.h */ #ifdef WINDOZE #define PATH_DELIMITER '\\' #else #define PATH_DELIMITER '/' #endif int main (int argc, char **argv) { char PluginPath[MAX_PATH+1], *cp; /* ... snip ... */ /* Build the path to our co-plugin */ strcpy(PluginPath, argv[0]); if ((cp = strrchr(PluginPath, PATH_DELIMITER)) != NULL) strcpy(cp+1, PS_COMMAND); else /* No path prefix found - assume that the system path works */ strcpy(PluginPath, PS_COMMAND); /* Now use the spopen() command to exec our co-plugin */ child_process = spopen (PS_COMMAND); /* ... snip ... */ } Hope this is helpful... Bob > if you've read the subject, you may be thinking "why the hell would > you want to do that?" > > one example is the latest modification i've made (or half-made, > hence the email) to check_procs, to call the pst3 program submitted > by bob ingraham, which will also reside in the plugin installation > dir. > > the problem is that to execute pst3, one has to either supply the > full path or assume that it is in the path. the problem with the > latter is that it probably will not be in the system path, and > the problem with the former is that i can't figure out a good way > to supply the path to the plugin. > > so, i see a couple iof options here: > > - modify configure.in, config.h and/or Makefile.am's to pass the > information at compile-time > - modify check_procs to include the pst3 code natively, making this > a moot issue. > > comments? in the meantime, i'll leave the CVS HEAD configure.in script > with ac_cv_ps_command="pst3" (no path), so if someone cares they > can copy the binary into their paths. if i don't hear back, i think > i'll try and work with option 2. > > > sean > From bobi at netshel.net Thu Sep 22 13:49:09 2005 From: bobi at netshel.net (Bob Ingraham) Date: Thu Sep 22 13:49:09 2005 Subject: [Nagiosplug-devel] complication executing one plugin by another In-Reply-To: <28770.12.110.19.97.1127421015.squirrel@12.110.19.97> References: <20050922120854.GA21452@seanius.net> <28770.12.110.19.97.1127421015.squirrel@12.110.19.97> Message-ID: <37396.12.110.19.97.1127422089.squirrel@12.110.19.97> Sorry, here's a correction to the sample code snippet in my prior e-mail below. The call to spopen() should read: /* Now use the spopen() command to exec our co-plugin */ child_process = spopen (PluginPath); ^^^^^^^^^^ Bob > I have an idea... :-) > > It seems to me that the plugins are always executed with full path > information contained in argv[0], since the nrpe.cfg file usually contains > the full path information and this is what nrpe use to exec() these > plugins. > > Therefore, if you know that you want to execute a fellow plugin (why does > that not sound right? ;-) ), then all you need do is extract the full path > info from main's argv[0] vector, and use that to construct the path the > "peer" plugin. > > Something like: > > #define PS_COMMAND "pst3" /* From config.h */ > > #ifdef WINDOZE > #define PATH_DELIMITER '\\' > #else > #define PATH_DELIMITER '/' > #endif > > int main (int argc, char **argv) > { > char PluginPath[MAX_PATH+1], *cp; > > /* ... snip ... */ > > /* Build the path to our co-plugin */ > strcpy(PluginPath, argv[0]); > if ((cp = strrchr(PluginPath, PATH_DELIMITER)) != NULL) > strcpy(cp+1, PS_COMMAND); > else /* No path prefix found - assume that the system path works */ > strcpy(PluginPath, PS_COMMAND); > > /* Now use the spopen() command to exec our co-plugin */ > child_process = spopen (PS_COMMAND); > > /* ... snip ... */ > } > > Hope this is helpful... > > Bob > >> if you've read the subject, you may be thinking "why the hell would >> you want to do that?" >> >> one example is the latest modification i've made (or half-made, >> hence the email) to check_procs, to call the pst3 program submitted >> by bob ingraham, which will also reside in the plugin installation >> dir. >> >> the problem is that to execute pst3, one has to either supply the >> full path or assume that it is in the path. the problem with the >> latter is that it probably will not be in the system path, and >> the problem with the former is that i can't figure out a good way >> to supply the path to the plugin. >> >> so, i see a couple iof options here: >> >> - modify configure.in, config.h and/or Makefile.am's to pass the >> information at compile-time >> - modify check_procs to include the pst3 code natively, making this >> a moot issue. >> >> comments? in the meantime, i'll leave the CVS HEAD configure.in script >> with ac_cv_ps_command="pst3" (no path), so if someone cares they >> can copy the binary into their paths. if i don't hear back, i think >> i'll try and work with option 2. >> >> >> sean >> > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download it for free - -and be entered to win a 42" plasma tv or your very > own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________________ > Nagios Plugin Development Mailing List > Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > From bobi at netshel.net Thu Sep 22 14:09:55 2005 From: bobi at netshel.net (Bob Ingraham) Date: Thu Sep 22 14:09:55 2005 Subject: [Nagiosplug-devel] complication executing one plugin by another In-Reply-To: <37396.12.110.19.97.1127422089.squirrel@12.110.19.97> References: <20050922120854.GA21452@seanius.net> <28770.12.110.19.97.1127421015.squirrel@12.110.19.97> <37396.12.110.19.97.1127422089.squirrel@12.110.19.97> Message-ID: <46851.12.110.19.97.1127423288.squirrel@12.110.19.97> Of course, it occurs to me that this solution works well for check_procs under Solaris, but screws things up for other platforms (AIX, Linux, etc.) that use their native ps programs. I suppose that if you bracket the Solaris-specific code with: #ifdef SOLARIS /* Build the path to our co-plugin */ strcpy(PluginPath, argv[0]); if ((cp = strrchr(PluginPath, PATH_DELIMITER)) != NULL) strcpy(cp+1, PS_COMMAND); else /* No path prefix found - assume that the system path works */ strcpy(PluginPath, PS_COMMAND); /* Now use the spopen() command to exec our co-plugin */ child_process = spopen (PluginPath); #else child_process = spopen (PS_COMMAND); #endif Other than that, the cleanest solution (one that requires no modifications to check_procs.c) appears to be: Have configure create the "#define PS_COMMAND" string in config.h with the path specified by --prefix. For example: #define PS_COMMAND "${prefix}/libexec/pst3" Again, though, this requires Solaris-specific detection logic in configure. This is the solution that I implemented in our environment. Bob > Sorry, here's a correction to the sample code snippet in my prior e-mail > below. > > The call to spopen() should read: > > /* Now use the spopen() command to exec our co-plugin */ > child_process = spopen (PluginPath); > ^^^^^^^^^^ > > Bob > >> I have an idea... :-) >> >> It seems to me that the plugins are always executed with full path >> information contained in argv[0], since the nrpe.cfg file usually >> contains >> the full path information and this is what nrpe use to exec() these >> plugins. >> >> Therefore, if you know that you want to execute a fellow plugin (why >> does >> that not sound right? ;-) ), then all you need do is extract the full >> path >> info from main's argv[0] vector, and use that to construct the path the >> "peer" plugin. >> >> Something like: >> >> #define PS_COMMAND "pst3" /* From config.h */ >> >> #ifdef WINDOZE >> #define PATH_DELIMITER '\\' >> #else >> #define PATH_DELIMITER '/' >> #endif >> >> int main (int argc, char **argv) >> { >> char PluginPath[MAX_PATH+1], *cp; >> >> /* ... snip ... */ >> >> /* Build the path to our co-plugin */ >> strcpy(PluginPath, argv[0]); >> if ((cp = strrchr(PluginPath, PATH_DELIMITER)) != NULL) >> strcpy(cp+1, PS_COMMAND); >> else /* No path prefix found - assume that the system path works */ >> strcpy(PluginPath, PS_COMMAND); >> >> /* Now use the spopen() command to exec our co-plugin */ >> child_process = spopen (PS_COMMAND); >> >> /* ... snip ... */ >> } >> >> Hope this is helpful... >> >> Bob >> >>> if you've read the subject, you may be thinking "why the hell would >>> you want to do that?" >>> >>> one example is the latest modification i've made (or half-made, >>> hence the email) to check_procs, to call the pst3 program submitted >>> by bob ingraham, which will also reside in the plugin installation >>> dir. >>> >>> the problem is that to execute pst3, one has to either supply the >>> full path or assume that it is in the path. the problem with the >>> latter is that it probably will not be in the system path, and >>> the problem with the former is that i can't figure out a good way >>> to supply the path to the plugin. >>> >>> so, i see a couple iof options here: >>> >>> - modify configure.in, config.h and/or Makefile.am's to pass the >>> information at compile-time >>> - modify check_procs to include the pst3 code natively, making this >>> a moot issue. >>> >>> comments? in the meantime, i'll leave the CVS HEAD configure.in script >>> with ac_cv_ps_command="pst3" (no path), so if someone cares they >>> can copy the binary into their paths. if i don't hear back, i think >>> i'll try and work with option 2. >>> >>> >>> sean >>> >> >> >> >> ------------------------------------------------------- >> SF.Net email is sponsored by: >> Tame your development challenges with Apache's Geronimo App Server. >> Download it for free - -and be entered to win a 42" plasma tv or your >> very >> own Sony(tm)PSP. Click here to play: >> http://sourceforge.net/geronimo.php >> _______________________________________________________ >> Nagios Plugin Development Mailing List >> Nagiosplug-devel at lists.sourceforge.net >> Unsubscribe at >> https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel >> ::: Please include plugins version (-v) and OS when reporting any issue. >> ::: Messages without supporting info will risk being sent to /dev/null >> > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download it for free - -and be entered to win a 42" plasma tv or your very > own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________________ > Nagios Plugin Development Mailing List > Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > From noreply at sourceforge.net Fri Sep 23 03:45:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 23 03:45:10 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1210958 ] Issue with check_nwstat in Release 1.4 Message-ID: Bugs item #1210958, was opened at 2005-05-29 22:42 Message generated for change (Comment added) made by sullivand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1210958&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: mick81 (mick81) Assigned to: Nobody/Anonymous (nobody) Summary: Issue with check_nwstat in Release 1.4 Initial Comment: I have found a issue with check_nwstat incorrectly reporting free disk space. Using the variable VPF returns Available Entries within Directory Entries of the Volume instead of Free Space in Disk Usage. ---------------------------------------------------------------------- Comment By: David Sullivan (sullivand) Date: 2005-09-23 11:44 Message: Logged In: YES user_id=1348152 Fixed in 1.4.1 onwards. See Bug 1235879. Test: sully at support:~$ /usr/local/src/nagios-plugins-1.4/plugins/check_nwstat -p 9999 -H server -v "VPFSYS" -w 10 -c 5 10470 MB (2147483648%) free on volume SYS sully at support:~$ /usr/local/src/nagios-plugins-1.4.2/plugins/check_nwstat -p 9999 -H server -v "VPFSYS" -w 10 -c 5 10470 MB (61%) free on volume SYS - total 16933 MB ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1210958&group_id=29880 From noreply at sourceforge.net Sun Sep 25 08:24:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 25 08:24:15 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1291126 ] Alternate ps for Solaris Message-ID: Bugs item #1291126, was opened at 2005-09-14 12:04 Message generated for change (Comment added) made by seanius You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291126&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: CVS Status: Open Resolution: None Priority: 5 Submitted By: Bob Ingraham (rwingraham) Assigned to: M. Sean Finney (seanius) Summary: Alternate ps for Solaris Initial Comment: Per Sean, I am uploading the source for an alternate ps utility for Solaris that will work with the existing check_procs plugin. This alternate ps gets around the 80-character limitation inherent in the native ps for Solaris. It has been extensively testing on our corporate Solaris farm. Notes: 1. I've installed this alternate ps (called pst3) in the libexec directory, along with the other plugins. 2. It needs setuid-root permissions to run, but accepts no arguments and reads no input streams and therefore isn't subject to exploitations such as buffer overflow and the like. The only reason is needs the setuid-root permission is so that it can open the running kernel image, in READ-ONLY mode, in order to access the process argument vectors. 3. It requires a patch to the configuration file which substitutes this alternate utility instead of ps for Soalris systems. Bob ---------------------------------------------------------------------- >Comment By: M. Sean Finney (seanius) Date: 2005-09-25 11:23 Message: Logged In: YES user_id=226838 hi bob, i've now included your code in cvs head, and mangled the configure script appropriately, so pst3 should now be the default for all SunOS systems. could you try the latest copy of what's in cvs and verify that it works for you? as i previously stated, i don't have r00t on a solaris machine, unfortunately :( likewise, to any others who have r00t access on a solaris bug, i'd appreciate hearing back. ---------------------------------------------------------------------- Comment By: Bob Ingraham (rwingraham) Date: 2005-09-22 15:20 Message: Logged In: YES user_id=1086870 Sean, To answer your previous posts (sorry for the delay - I've been slammed at work,): 1. why isn't pPsInfo->pr_pid included in the output? I designed pst3 to exactly duplicate the output columns produced by the output produced by the original Solaris ps command: /usr/bin/ps -Ao 's uid ppid vsz rss pcpu comm args' You'll notice that Parent-PID is requested (ppid) but not the current process PID (pid). According to the source for check_procs, you can search for children of a parent PID (hence the ppid,) or you can search for a username/uid (hence the uid). But apparetnly, the option is not provided to search for just a PID. 2. You need root access on a Solaris server. I have a Solaris box I can test you config changes on. 3. Can I drop privileges after opening the kernel image? I don't know if it will work. That would depend upon whether the subsequent kvm_* calls also check the effective UID of the caller or not. Do you still want me to try this? Bob ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-22 07:40 Message: Logged In: YES user_id=226838 slight complication, i'll email the list with details... ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-22 05:32 Message: Logged In: YES user_id=226838 btw: why isn't pPsInfo->pr_pid included in the output? ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-22 05:16 Message: Logged In: YES user_id=226838 hi bob, ton, i just finished looking over the script, and it looks good. unfortunately i no longer have root access to a solaris server, so i can't install the plugin setuid root. i can still throw together everything else (the configure patch, etc), but the final test will need to be conducted by someone else. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-09-21 06:14 Message: Logged In: YES user_id=664364 Sean, plugins-root/ is created now. This would be the best place to put pst3. Ton ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-09-20 03:55 Message: Logged In: YES user_id=664364 Sean, I have no problem with setuid scripts since we already have check_icmp and check_dhcp, but they don't install as root at the moment (it is manually done). I am trying to separate setuid scripts out to plugins- root/ so then the installer can be configured to install with the correct permissions, but haven't fully tested my local copy yet. Give me another day to sort this out. Ton ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-19 11:27 Message: Logged In: YES user_id=226838 hi bob, thanks for this, i've just taken a look over it. if this program has to run setuid root to open the kmem structure, would it be possible to drop priviliges immediately after having done so? ton: what are your thoughts about dropping this utility in the libexec dir? i could throw together a pretty quick configure patch to decide whether or not the ps utility was needed. not sure how we're handling the other setuid programs, but i could follow suit with whatever we're doing for the others ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291126&group_id=29880 From noreply at sourceforge.net Sun Sep 25 08:29:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 25 08:29:06 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-903461 ] check_nwstat generates ipv6 calls (error) Message-ID: Bugs item #903461, was opened at 2004-02-24 09:14 Message generated for change (Comment added) made by seanius You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=903461&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Alex (faucon) Assigned to: Nobody/Anonymous (nobody) Summary: check_nwstat generates ipv6 calls (error) Initial Comment: Short story : check_nwstat is doing 2 X AAAA request and 1 X A request to my DNS server since version 1.3.99 (1.13). Details and tests : Linux server RedHat9. DNS server Netware With check_nwstat v1.3.99 or more recent, my DNS server is showing that my Nagios server is doing 2 X AAAA request (ip6) and 1 X A request (ip4). I tested with version 1.3.1 of the plugins, and there is no problem there. (but features in latest release are needed). I tested with other plugins and with ping, and everything is fine. Here is a peace of the logs. ---------------------- ***** QH_Proc: query received from 10.1.0.137 QH_ns_req: Query for (srv-ndps1.cslaval.qc.ca) of type aaaa Domain Name "srv-ndps1.cslaval.qc.ca" found in authoritative cache zone "cslaval.qc.ca" Send a UDP Reply to 10.1.0.137 ***** QH_Proc: query received from 10.1.0.137 QH_ns_req: Query for (srv-educ1.cslaval.qc.ca) of type aaaa Domain Name "srv-educ1.cslaval.qc.ca" found in authoritative cache zone "cslaval.qc.ca" Send a UDP Reply to 10.1.0.137 ***** QH_Proc: query received from 10.1.0.137 QH_ns_req: Query for (srv-sec1.cslaval.qc.ca) of type aaaa Domain Name "srv-sec1.cslaval.qc.ca" found in authoritative cache zone "cslaval.qc.ca" Send a UDP Reply to 10.1.0.137 ***** QH_Proc: query received from 10.1.0.137 QH_ns_req: Query for (srv-ndps1.cslaval.qc.ca) of type aaaa Domain Name "srv-ndps1.cslaval.qc.ca" found in authoritative cache zone "cslaval.qc.ca" Send a UDP Reply to 10.1.0.137 ***** QH_Proc: query received from 10.1.0.137 QH_ns_req: Query for (srv-educ1.cslaval.qc.ca) of type a Domain Name "srv-educ1.cslaval.qc.ca" found in authoritative cache zone "cslaval.qc.ca" Send a UDP Reply to 10.1.0.137 ***** QH_Proc: query received from 10.1.0.137 QH_ns_req: Query for (srv-sec1.cslaval.qc.ca) of type aaaa Domain Name "srv-sec1.cslaval.qc.ca" found in authoritative cache zone "cslaval.qc.ca" Send a UDP Reply to 10.1.0.137 ***** QH_Proc: query received from 10.1.0.137 QH_ns_req: Query for (srv-ndps1.cslaval.qc.ca) of type a Domain Name "srv-ndps1.cslaval.qc.ca" found in authoritative cache zone "cslaval.qc.ca" Send a UDP Reply to 10.1.0.137 ***** QH_Proc: query received from 10.1.0.137 QH_ns_req: Query for (srv-sec1.cslaval.qc.ca) of type a Domain Name "srv-sec1.cslaval.qc.ca" found in authoritative cache zone "cslaval.qc.ca" Send a UDP Reply to 10.1.0.137 --------------------------------- ---------------------------------------------------------------------- >Comment By: M. Sean Finney (seanius) Date: 2005-09-25 11:28 Message: Logged In: YES user_id=226838 hi faucon, it's just been brought to my attention (in another bug report) that there were some patches done recently (around july or september) to check_nwstat. as none of the developers have any access to netware systems, could you take a try with the latest version in cvs head? ---------------------------------------------------------------------- Comment By: Alex (faucon) Date: 2005-05-02 10:54 Message: Logged In: YES user_id=706397 Hi seanius. Nop, still does. With the latest 1.4 package of plugins. Just tested 5 minutes ago :) check_ping (nagios-plugins 1.3.99) 1.25 check_nwstat (nagios-plugins 1.3.99) 1.13 At the end of this message, you can see the logs of ethereal. I made 3 pass for each tests. One with check_ping and one with check_nwstat. Since all 3 pass are the same, I just posted one of each. The thing is, with ping, everything is fine, it sends A request to the DNS and then ping. But with nwstat, it sends AAAA requests to the DNS before the A request and then check_nwstat. In practice, this means more stress for the DNS server. So the current workaround for here, is that I use the "secondary" DNS server as the first server, insted of the primary. If not, the primary is overload. -ethereal capture (edited)- (check_ping) 1.260597 10.200.60.160 -> 10.1.0.80 DNS Standard query A server.domain.qc.ca 1.260921 10.1.0.80 -> 10.200.60.160 DNS Standard query response A 10.200.1.20 1.264812 10.200.60.160 -> 10.1.0.80 DNS Standard query A server.domain.qc.ca 1.266082 10.1.0.80 -> 10.200.60.160 DNS Standard query response A 10.200.1.20 1.265547 10.200.60.160 -> 10.200.1.20 ICMP Echo (ping) request 1.265723 10.200.1.20 -> 10.200.60.160 ICMP Echo (ping) reply 2.264552 10.200.60.160 -> 10.200.1.20 ICMP Echo (ping) request 2.264726 10.200.1.20 -> 10.200.60.160 ICMP Echo (ping) reply 3.263560 10.200.60.160 -> 10.200.1.20 ICMP Echo (ping) request 3.263707 10.200.1.20 -> 10.200.60.160 ICMP Echo (ping) reply 4.262556 10.200.60.160 -> 10.200.1.20 ICMP Echo (ping) request 4.262723 10.200.1.20 -> 10.200.60.160 ICMP Echo (ping) reply 5.261575 10.200.60.160 -> 10.200.1.20 ICMP Echo (ping) request 5.261735 10.200.1.20 -> 10.200.60.160 ICMP Echo (ping) reply (check nwstat) 23.476463 10.200.60.160 -> 10.1.0.80 DNS Standard query AAAA server.domain.qc.ca 23.476734 10.1.0.80 -> 10.200.60.160 DNS Standard query response 23.477294 10.200.60.160 -> 10.1.0.80 DNS Standard query AAAA server.domain.qc.ca.domain.qc.ca 23.477576 10.1.0.80 -> 10.200.60.160 DNS Standard query response, No such name 23.477911 10.200.60.160 -> 10.1.0.80 DNS Standard query A srv-adm1.cslaval.qc.ca 23.478212 10.1.0.80 -> 10.200.60.160 DNS Standard query response A 10.200.1.20 23.478799 10.200.60.160 -> 10.200.1.20 TCP 39763 > 9999 [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=219178857 TSER=0 WS=0 23.478971 10.200.1.20 -> 10.200.60.160 TCP 9999 > 39763 [SYN, ACK] Seq=0 Ack=1 Win=6144 Len=0 MSS=1460 WS=0 23.479029 10.200.60.160 -> 10.200.1.20 TCP 39763 > 9999 [ACK] Seq=1 Ack=1 Win=5840 Len=0 23.540094 10.200.60.160 -> 10.200.1.20 TCP 39763 > 9999 [FIN, ACK] Seq=1 Ack=1 Win=5840 Len=0 23.540252 10.200.1.20 -> 10.200.60.160 TCP 9999 > 39763 [ACK] Seq=1 Ack=2 Win=6143 Len=0 23.540270 10.200.1.20 -> 10.200.60.160 TCP 9999 > 39763 [FIN, PSH, ACK] Seq=1 Ack=2 Win=6143 Len=0 23.540360 10.200.60.160 -> 10.200.1.20 TCP 39763 > 9999 [ACK] Seq=2 Ack=2 Win=5840 Len=0 ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-05-01 15:56 Message: Logged In: YES user_id=226838 any progress on this one? it's the oldest bug in the tracker and i'm just trying to help keep a clean house :) ---------------------------------------------------------------------- Comment By: Alex (faucon) Date: 2005-01-11 10:39 Message: Logged In: YES user_id=706397 Hi tonvoon, Let me check it out. I'll download the latest cve and test it. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-01-01 11:35 Message: Logged In: YES user_id=664364 Unassigning from Karl, but not sure of current status of this bug. Is it still an issue with the latest release? ---------------------------------------------------------------------- Comment By: Alex (faucon) Date: 2004-03-01 11:42 Message: Logged In: YES user_id=706397 Hi kdebisschop, I have tryed your check_nwstat of 2004-02-29. I can compile it, I can run it, but there is no output. And, on my dns, there is no dns request been made. And here is the command call that I use. Any other variable could be used. The output is working with 1.3.1 or 1.4.1alpha. ./check_nwstat -H srv-ndps1.cslaval.qc.ca -v ABENDS The answer to this command is usually: "0 abended threads" srv-ndps1 is an internal server. So you can't access it. But I can make any tests you require. Thanks. ---------------------------------------------------------------------- Comment By: Karl DeBisschop (kdebisschop) Date: 2004-02-28 23:18 Message: Logged In: YES user_id=1671 I may have found the cause - we were opening a new connection for each attribute requested. I have rewritten the code to open one connection and send repeatedly on tha one connection. But I do not have any way to test it and I do not know if the NW protocols allow it. Please test and provide feedback. ---------------------------------------------------------------------- Comment By: Karl DeBisschop (kdebisschop) Date: 2004-02-28 22:37 Message: Logged In: YES user_id=1671 Can you provide the service and command definitions that create these multiple requests? I don't have access to a test environment, but I'll be glad to look at the code and see if I can find anything. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=903461&group_id=29880 From noreply at sourceforge.net Mon Sep 26 00:46:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 26 00:46:10 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1210958 ] Issue with check_nwstat in Release 1.4 Message-ID: Bugs item #1210958, was opened at 2005-05-29 22:42 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1210958&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: Release (specify) >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: mick81 (mick81) >Assigned to: Ton Voon (tonvoon) Summary: Issue with check_nwstat in Release 1.4 Initial Comment: I have found a issue with check_nwstat incorrectly reporting free disk space. Using the variable VPF returns Available Entries within Directory Entries of the Volume instead of Free Space in Disk Usage. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2005-09-26 08:45 Message: Logged In: YES user_id=664364 Mick, Thanks for the report. Since David says this is fixed, I've closed this call. Please reopen if it is still an issue. Ton ---------------------------------------------------------------------- Comment By: David Sullivan (sullivand) Date: 2005-09-23 11:44 Message: Logged In: YES user_id=1348152 Fixed in 1.4.1 onwards. See Bug 1235879. Test: sully at support:~$ /usr/local/src/nagios-plugins-1.4/plugins/check_nwstat -p 9999 -H server -v "VPFSYS" -w 10 -c 5 10470 MB (2147483648%) free on volume SYS sully at support:~$ /usr/local/src/nagios-plugins-1.4.2/plugins/check_nwstat -p 9999 -H server -v "VPFSYS" -w 10 -c 5 10470 MB (61%) free on volume SYS - total 16933 MB ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1210958&group_id=29880 From noreply at sourceforge.net Mon Sep 26 02:30:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 26 02:30:02 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-903461 ] check_nwstat generates ipv6 calls (error) Message-ID: Bugs item #903461, was opened at 2004-02-24 14:14 Message generated for change (Comment added) made by sullivand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=903461&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Alex (faucon) Assigned to: Nobody/Anonymous (nobody) Summary: check_nwstat generates ipv6 calls (error) Initial Comment: Short story : check_nwstat is doing 2 X AAAA request and 1 X A request to my DNS server since version 1.3.99 (1.13). Details and tests : Linux server RedHat9. DNS server Netware With check_nwstat v1.3.99 or more recent, my DNS server is showing that my Nagios server is doing 2 X AAAA request (ip6) and 1 X A request (ip4). I tested with version 1.3.1 of the plugins, and there is no problem there. (but features in latest release are needed). I tested with other plugins and with ping, and everything is fine. Here is a peace of the logs. ---------------------- ***** QH_Proc: query received from 10.1.0.137 QH_ns_req: Query for (srv-ndps1.cslaval.qc.ca) of type aaaa Domain Name "srv-ndps1.cslaval.qc.ca" found in authoritative cache zone "cslaval.qc.ca" Send a UDP Reply to 10.1.0.137 ***** QH_Proc: query received from 10.1.0.137 QH_ns_req: Query for (srv-educ1.cslaval.qc.ca) of type aaaa Domain Name "srv-educ1.cslaval.qc.ca" found in authoritative cache zone "cslaval.qc.ca" Send a UDP Reply to 10.1.0.137 ***** QH_Proc: query received from 10.1.0.137 QH_ns_req: Query for (srv-sec1.cslaval.qc.ca) of type aaaa Domain Name "srv-sec1.cslaval.qc.ca" found in authoritative cache zone "cslaval.qc.ca" Send a UDP Reply to 10.1.0.137 ***** QH_Proc: query received from 10.1.0.137 QH_ns_req: Query for (srv-ndps1.cslaval.qc.ca) of type aaaa Domain Name "srv-ndps1.cslaval.qc.ca" found in authoritative cache zone "cslaval.qc.ca" Send a UDP Reply to 10.1.0.137 ***** QH_Proc: query received from 10.1.0.137 QH_ns_req: Query for (srv-educ1.cslaval.qc.ca) of type a Domain Name "srv-educ1.cslaval.qc.ca" found in authoritative cache zone "cslaval.qc.ca" Send a UDP Reply to 10.1.0.137 ***** QH_Proc: query received from 10.1.0.137 QH_ns_req: Query for (srv-sec1.cslaval.qc.ca) of type aaaa Domain Name "srv-sec1.cslaval.qc.ca" found in authoritative cache zone "cslaval.qc.ca" Send a UDP Reply to 10.1.0.137 ***** QH_Proc: query received from 10.1.0.137 QH_ns_req: Query for (srv-ndps1.cslaval.qc.ca) of type a Domain Name "srv-ndps1.cslaval.qc.ca" found in authoritative cache zone "cslaval.qc.ca" Send a UDP Reply to 10.1.0.137 ***** QH_Proc: query received from 10.1.0.137 QH_ns_req: Query for (srv-sec1.cslaval.qc.ca) of type a Domain Name "srv-sec1.cslaval.qc.ca" found in authoritative cache zone "cslaval.qc.ca" Send a UDP Reply to 10.1.0.137 --------------------------------- ---------------------------------------------------------------------- Comment By: David Sullivan (sullivand) Date: 2005-09-26 10:29 Message: Logged In: YES user_id=1348152 I've reproduced this with the latest CVS version of check_nwstat. A number of the plugins that connect to TCP services directly without spawning another programme have this "problem" though. I can demonstrate the same behaviour of generating AAAA queries with check_smtp, check_imap and check_ssh. check_ping probably wasn't the best plugin to compare against since it executes another programme which itself might not have IPV6 support. The problem is an artifact of IPV6 support that it will try and resolve both AAAA and A records for a hostname. The possible fix is to modify check_nwstat to also have the -4 and -6 options as these other TCP plugins do. With the other plugins listed above adding the -4 option when executing the plugin eliminates these AAAA queries. David. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-25 16:28 Message: Logged In: YES user_id=226838 hi faucon, it's just been brought to my attention (in another bug report) that there were some patches done recently (around july or september) to check_nwstat. as none of the developers have any access to netware systems, could you take a try with the latest version in cvs head? ---------------------------------------------------------------------- Comment By: Alex (faucon) Date: 2005-05-02 15:54 Message: Logged In: YES user_id=706397 Hi seanius. Nop, still does. With the latest 1.4 package of plugins. Just tested 5 minutes ago :) check_ping (nagios-plugins 1.3.99) 1.25 check_nwstat (nagios-plugins 1.3.99) 1.13 At the end of this message, you can see the logs of ethereal. I made 3 pass for each tests. One with check_ping and one with check_nwstat. Since all 3 pass are the same, I just posted one of each. The thing is, with ping, everything is fine, it sends A request to the DNS and then ping. But with nwstat, it sends AAAA requests to the DNS before the A request and then check_nwstat. In practice, this means more stress for the DNS server. So the current workaround for here, is that I use the "secondary" DNS server as the first server, insted of the primary. If not, the primary is overload. -ethereal capture (edited)- (check_ping) 1.260597 10.200.60.160 -> 10.1.0.80 DNS Standard query A server.domain.qc.ca 1.260921 10.1.0.80 -> 10.200.60.160 DNS Standard query response A 10.200.1.20 1.264812 10.200.60.160 -> 10.1.0.80 DNS Standard query A server.domain.qc.ca 1.266082 10.1.0.80 -> 10.200.60.160 DNS Standard query response A 10.200.1.20 1.265547 10.200.60.160 -> 10.200.1.20 ICMP Echo (ping) request 1.265723 10.200.1.20 -> 10.200.60.160 ICMP Echo (ping) reply 2.264552 10.200.60.160 -> 10.200.1.20 ICMP Echo (ping) request 2.264726 10.200.1.20 -> 10.200.60.160 ICMP Echo (ping) reply 3.263560 10.200.60.160 -> 10.200.1.20 ICMP Echo (ping) request 3.263707 10.200.1.20 -> 10.200.60.160 ICMP Echo (ping) reply 4.262556 10.200.60.160 -> 10.200.1.20 ICMP Echo (ping) request 4.262723 10.200.1.20 -> 10.200.60.160 ICMP Echo (ping) reply 5.261575 10.200.60.160 -> 10.200.1.20 ICMP Echo (ping) request 5.261735 10.200.1.20 -> 10.200.60.160 ICMP Echo (ping) reply (check nwstat) 23.476463 10.200.60.160 -> 10.1.0.80 DNS Standard query AAAA server.domain.qc.ca 23.476734 10.1.0.80 -> 10.200.60.160 DNS Standard query response 23.477294 10.200.60.160 -> 10.1.0.80 DNS Standard query AAAA server.domain.qc.ca.domain.qc.ca 23.477576 10.1.0.80 -> 10.200.60.160 DNS Standard query response, No such name 23.477911 10.200.60.160 -> 10.1.0.80 DNS Standard query A srv-adm1.cslaval.qc.ca 23.478212 10.1.0.80 -> 10.200.60.160 DNS Standard query response A 10.200.1.20 23.478799 10.200.60.160 -> 10.200.1.20 TCP 39763 > 9999 [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=219178857 TSER=0 WS=0 23.478971 10.200.1.20 -> 10.200.60.160 TCP 9999 > 39763 [SYN, ACK] Seq=0 Ack=1 Win=6144 Len=0 MSS=1460 WS=0 23.479029 10.200.60.160 -> 10.200.1.20 TCP 39763 > 9999 [ACK] Seq=1 Ack=1 Win=5840 Len=0 23.540094 10.200.60.160 -> 10.200.1.20 TCP 39763 > 9999 [FIN, ACK] Seq=1 Ack=1 Win=5840 Len=0 23.540252 10.200.1.20 -> 10.200.60.160 TCP 9999 > 39763 [ACK] Seq=1 Ack=2 Win=6143 Len=0 23.540270 10.200.1.20 -> 10.200.60.160 TCP 9999 > 39763 [FIN, PSH, ACK] Seq=1 Ack=2 Win=6143 Len=0 23.540360 10.200.60.160 -> 10.200.1.20 TCP 39763 > 9999 [ACK] Seq=2 Ack=2 Win=5840 Len=0 ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-05-01 20:56 Message: Logged In: YES user_id=226838 any progress on this one? it's the oldest bug in the tracker and i'm just trying to help keep a clean house :) ---------------------------------------------------------------------- Comment By: Alex (faucon) Date: 2005-01-11 15:39 Message: Logged In: YES user_id=706397 Hi tonvoon, Let me check it out. I'll download the latest cve and test it. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-01-01 16:35 Message: Logged In: YES user_id=664364 Unassigning from Karl, but not sure of current status of this bug. Is it still an issue with the latest release? ---------------------------------------------------------------------- Comment By: Alex (faucon) Date: 2004-03-01 16:42 Message: Logged In: YES user_id=706397 Hi kdebisschop, I have tryed your check_nwstat of 2004-02-29. I can compile it, I can run it, but there is no output. And, on my dns, there is no dns request been made. And here is the command call that I use. Any other variable could be used. The output is working with 1.3.1 or 1.4.1alpha. ./check_nwstat -H srv-ndps1.cslaval.qc.ca -v ABENDS The answer to this command is usually: "0 abended threads" srv-ndps1 is an internal server. So you can't access it. But I can make any tests you require. Thanks. ---------------------------------------------------------------------- Comment By: Karl DeBisschop (kdebisschop) Date: 2004-02-29 04:18 Message: Logged In: YES user_id=1671 I may have found the cause - we were opening a new connection for each attribute requested. I have rewritten the code to open one connection and send repeatedly on tha one connection. But I do not have any way to test it and I do not know if the NW protocols allow it. Please test and provide feedback. ---------------------------------------------------------------------- Comment By: Karl DeBisschop (kdebisschop) Date: 2004-02-29 03:37 Message: Logged In: YES user_id=1671 Can you provide the service and command definitions that create these multiple requests? I don't have access to a test environment, but I'll be glad to look at the code and see if I can find anything. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=903461&group_id=29880 From noreply at sourceforge.net Mon Sep 26 19:21:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 26 19:21:04 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1250191 ] ECHILD in waitpid (popen.c:spclose) Message-ID: <200509270220.j8R2KGMC020340@projects.sourceforge.net> Bugs item #1250191, was opened at 08/02/05 05:39 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1250191&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: Fixed Priority: 7 Submitted By: Peter Pramberger (peterpramb) Assigned to: Ton Voon (tonvoon) Summary: ECHILD in waitpid (popen.c:spclose) Initial Comment: After installing Nagios 2.0b3 and plugins 1.4/1.4.1 on a CentOS 4.1 machine (a RedHat ES 4.1 clone, kernel-2.6.9, glibc-2.3.4) I found that the check_dns plugin always aborts with "DNS WARNING - nslookup returned error status" except in the first run. However running it in verbose mode always shows a successful nslookup output. After some debugging I found that the waitpid call in popen.c:spclose() returns a ECHILD, which triggers a failure return value to be passed back to check_dns. Cacthing the ECHILD always produces a reasonable output, so the child with nslookup is really working. >From the (linux) manpage: ECHILD if the process specified in pid does not exist or is not a child of the calling process. (This can happen for one's own child if the action for SIGCHLD is set to SIG_IGN. See also the LINUX NOTES section about threads.) Shouldn't waitpid be successful in reading the exit status of the child? Maybe a bug in glibc? Anyone else seen this? ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 09/26/05 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 09/12/05 08:45 Message: Logged In: YES user_id=664364 Have applied patch to CVS to fix this. Works by using Peter's patch surrounded by ifdefs. Configure checks whether this problem exists on the redhat system or not. Will release 1.4.2 after confirmed builds. Marking this item to pending closure. Ton ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 09/05/05 09:27 Message: Logged In: YES user_id=664364 Agreed with Sean to take over this call. Have created a testcase. Sascha Runschke is raising this to Red Hat. New patch from Peter Pramberger attached. Depending on reply from Red Hat, will apply patch next week. Ton ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 09/02/05 04:03 Message: Logged In: YES user_id=226838 ECHLD is returned in this context when the child has already exited, and shouldn't be treated as an error. i'll commit a change to cvs shortly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1250191&group_id=29880 From antony at asharris.com Fri Sep 30 02:31:11 2005 From: antony at asharris.com (Antony Harris) Date: Fri Sep 30 02:31:11 2005 Subject: [Nagiosplug-devel] check_http Message-ID: <433D0379.70208@asharris.com> Using the check_http plugin to check for a certificate, I could not get it to work. Looking at the source I realised that instead of using: check_http www.verisign.com -C10 I needed to use check_http www.verisign.com -S -C 10 This was not shown in the example in the --help. I have modified the source code to force -S if the -C option is specified and accepted. However, how do I go about contributing the change to the group? Thanks for your help Antony Harris From noreply at sourceforge.net Fri Sep 30 03:17:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 30 03:17:11 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1309349 ] check_http doesn't work with -C Message-ID: Patches item #1309349, was opened at 2005-09-30 11:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1309349&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None Status: Open Resolution: None Priority: 5 Submitted By: asharris (asharris) Assigned to: Nobody/Anonymous (nobody) Summary: check_http doesn't work with -C Initial Comment: check_http help suggests: check_http www.verisign.com -C 14 but this does not check the certificate as the -S options is also required. However, to conform to the help, the following patch can be applied: 313c313,315 < check_cert = TRUE; --- > use_ssl = check_cert = TRUE; > if (specify_port == FALSE) > server_port = HTTPS_PORT; This ensures that SSL is enabled for certificate checking. Antony ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1309349&group_id=29880 From seanius at seanius.net Fri Sep 30 03:17:59 2005 From: seanius at seanius.net (sean finney) Date: Fri Sep 30 03:17:59 2005 Subject: [Nagiosplug-devel] check_http In-Reply-To: <433D0379.70208@asharris.com> References: <433D0379.70208@asharris.com> Message-ID: <20050930101617.GA762@seanius.net> hi antony, your best bet is to post your patch (diff -u, ideally) here to this list as well as in the bugs or patches tracker. personally i'd see this as a bug; either the plugin should issue a warning and/or die, or -C should imply -S. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From noreply at sourceforge.net Fri Sep 30 03:23:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 30 03:23:07 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1309349 ] check_http doesn't work with -C (nneds -S too) Message-ID: Patches item #1309349, was opened at 2005-09-30 11:16 Message generated for change (Comment added) made by asharris You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1309349&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None Status: Open Resolution: None Priority: 5 Submitted By: asharris (asharris) Assigned to: Nobody/Anonymous (nobody) >Summary: check_http doesn't work with -C (nneds -S too) Initial Comment: check_http help suggests: check_http www.verisign.com -C 14 but this does not check the certificate as the -S options is also required. However, to conform to the help, the following patch can be applied: 313c313,315 < check_cert = TRUE; --- > use_ssl = check_cert = TRUE; > if (specify_port == FALSE) > server_port = HTTPS_PORT; This ensures that SSL is enabled for certificate checking. Antony ---------------------------------------------------------------------- >Comment By: asharris (asharris) Date: 2005-09-30 11:21 Message: Logged In: YES user_id=1354360 Sorry, didn't realise I needed to use "diff -u". --- check_http.org 2005-09-30 11:14:40.000000000 +0100 +++ check_http.c 2005-09-30 10:44:07.000000000 +0100 @@ -310,7 +310,9 @@ usage2 (_("Invalid certificate expiration period"), optarg); else { days_till_exp = atoi (optarg); - check_cert = TRUE; + use_ssl = check_cert = TRUE; + if (specify_port == FALSE) + server_port = HTTPS_PORT; } #else usage4 (_("Invalid option - SSL is not available")); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1309349&group_id=29880 From noreply at sourceforge.net Fri Sep 30 03:24:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 30 03:24:21 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1309349 ] check_http doesn't work with -C (needs -S too) Message-ID: Patches item #1309349, was opened at 2005-09-30 11:16 Message generated for change (Settings changed) made by asharris You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1309349&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None Status: Open Resolution: None Priority: 5 Submitted By: asharris (asharris) Assigned to: Nobody/Anonymous (nobody) >Summary: check_http doesn't work with -C (needs -S too) Initial Comment: check_http help suggests: check_http www.verisign.com -C 14 but this does not check the certificate as the -S options is also required. However, to conform to the help, the following patch can be applied: 313c313,315 < check_cert = TRUE; --- > use_ssl = check_cert = TRUE; > if (specify_port == FALSE) > server_port = HTTPS_PORT; This ensures that SSL is enabled for certificate checking. Antony ---------------------------------------------------------------------- Comment By: asharris (asharris) Date: 2005-09-30 11:21 Message: Logged In: YES user_id=1354360 Sorry, didn't realise I needed to use "diff -u". --- check_http.org 2005-09-30 11:14:40.000000000 +0100 +++ check_http.c 2005-09-30 10:44:07.000000000 +0100 @@ -310,7 +310,9 @@ usage2 (_("Invalid certificate expiration period"), optarg); else { days_till_exp = atoi (optarg); - check_cert = TRUE; + use_ssl = check_cert = TRUE; + if (specify_port == FALSE) + server_port = HTTPS_PORT; } #else usage4 (_("Invalid option - SSL is not available")); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1309349&group_id=29880 From seanius at seanius.net Fri Sep 30 06:30:40 2005 From: seanius at seanius.net (sean finney) Date: Fri Sep 30 06:30:40 2005 Subject: [Nagiosplug-devel] CVS directories in release tarball? Message-ID: <20050930132839.GA2302@seanius.net> hi, just realized that there are cvs directories in parts of the tarball, just fyi... sean -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: