From matthias.eble at mailing.kaufland-informationssysteme.com Sun Apr 1 17:06:49 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Sun, 01 Apr 2007 17:06:49 +0200 Subject: [Nagiosplug-devel] Flight 1.4.8, ready for boarding In-Reply-To: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> Message-ID: <460FCA89.8030901@mailing.kaufland-informationssysteme.com> Hi! > Matthias is working on a bug in check_disk. Is there any other work > planned before take off? I'm ready with all my work on check_disk, now. So from my side, we're clear for takeoff. But: The regexes in test_disk.c seem to have caused problems on ton's mac-mini buildhost. "opsviewdev1 Linux 2.6.8-2-386" is the only system except the mac-mini that has libtap installed - and test_disk went fine here. The log says: /bin/sh ../../libtool --tag=CC --mode=link gcc -g -O2 -L. -o test_disk -L/usr/local/lib -ltap test_disk-test_disk.o ../utils_disk.o gcc -g -O2 -o test_disk test_disk-test_disk.o ../utils_disk.o -L/tmp/np_build.13145/nagios-plugins-HEAD-200704011200/lib/tests -L/usr/local/lib /usr/local/lib/libtap.dylib -lpthread /usr/bin/ld: Undefined symbols: _rpl_regcomp _rpl_regexec collect2: ld returned 1 exit status I cannot imagine what this could be. Everythiny worked fine on my Suse 10.0 and my Ubuntu 6.06LTS boxes. Ton, could you please take a closer look what's going on there? I also saw at the tb status page, that the mac has never sent buildlogs before my commit. Is that true? regards matthias From noreply at sourceforge.net Mon Apr 2 00:06:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 01 Apr 2007 15:06:14 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1494629 ] 1.4.6 (& .3 & .5) - check_icmp fails after a time on FreeBSD Message-ID: Bugs item #1494629, was opened at 2006-05-25 06:41 Message generated for change (Comment added) made by mfavas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1494629&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Favas (mfavas) Assigned to: Thomas Guyot (dermoth) Summary: 1.4.6 (& .3 & .5) - check_icmp fails after a time on FreeBSD Initial Comment: Current release (1.4.3) check_icmp on FreeBSD 6.1 works fine for some hours, then reports 100% packet loss. This is due to the plugin not allowing for the fact that PIDs can be greater than 65535 (i.e. more than 16 bits) on systems such as FreeBSD. Further details are given in http://article.gmane.org/gmane.network.nagios.plugins/1945 . A version of check_icmp available from Andreas fixes this issue. This version has an earlier date associated with it than the version distributed in nagios-plugins, but a higher revsion number. Quote: """ If the fix isn't available in a recent package from the official nagiosplug package you should be able to use the one found at http://oss.op5.se/nagios/check_icmp-2005-06-01.tar.gz You can notice if the fix is available from the nagiosplug project by doing $ grep -q 'pid & 0xffff' check_icmp.c && echo "Fix available" """ ---------------------------------------------------------------------- >Comment By: Mark Favas (mfavas) Date: 2007-04-02 06:06 Message: Logged In: YES user_id=44979 Originator: YES Thanks for the quick response - I've tested the patch over the last week and everything looks good. ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-03-27 14:55 Message: Logged In: YES user_id=375623 Originator: NO Sorry, last comment was sent too early in error. The code have just been committed and the patch is attached. File Added: check_icmp.32bit-pid_t.patch ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-03-27 14:32 Message: Logged In: YES user_id=375623 Originator: NO Thanks for reporting. I fixed it in CVS so you can either pull the HEAD revision (Or wait for the next snapshot) or use the attached patch. ---------------------------------------------------------------------- Comment By: Mark Favas (mfavas) Date: 2007-03-25 07:31 Message: Logged In: YES user_id=44979 Originator: YES This bug still exists in 1.4.6, with FreeBSD 6.2 - would really appreciate a fix in the officially-released plugin code. ---------------------------------------------------------------------- Comment By: Mark Favas (mfavas) Date: 2006-12-02 18:29 Message: Logged In: YES user_id=44979 Originator: YES This bug still exists in version 1.4.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1494629&group_id=29880 From holger at CIS.FU-Berlin.DE Mon Apr 2 04:50:10 2007 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Mon, 2 Apr 2007 04:50:10 +0200 Subject: [Nagiosplug-devel] Flight 1.4.8, ready for boarding In-Reply-To: <20070331185328.GB44795887@CIS.FU-Berlin.DE> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> <804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com> <20070331185328.GB44795887@CIS.FU-Berlin.DE> Message-ID: <20070402025010.GA49868894@CIS.FU-Berlin.DE> * Holger Weiss [2007-03-31 20:53]: > However, with all servers I tried, the plugin returns a WARNING state > _without_ explaining the problem: > > | $ ./check_ntp -H time.fu-berlin.de -j 2 -k 3 > | NTP WARNING: Offset 0.05885159969 secs|offset=0.05885159969 jitter=0.001171 > > This WARNING is issued in jitter_request(): > > | if(! syncsource_found) *status = STATE_WARNING; > > I'm not familiar with NTP and haven't tracked down whether the plugin > does something wrong while checking for the synchronization source Just to let you know, this problem is specific to big-endian platforms. I don't have a clean fix yet, but I guess it's not a showstopper for a new plugins release. Holger -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE From dermoth at aei.ca Mon Apr 2 07:10:22 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Mon, 02 Apr 2007 01:10:22 -0400 Subject: [Nagiosplug-devel] Flight 1.4.8, ready for boarding In-Reply-To: <20070331185328.GB44795887@CIS.FU-Berlin.DE> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> <804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com> <20070331185328.GB44795887@CIS.FU-Berlin.DE> Message-ID: <4610903E.9070407@aei.ca> On 31/03/07 02:53 PM, Holger Weiss wrote: > Your patch should be committed in any case. I'll do. > What is the exact message you get? The message "warning: unable to read > server jitter response" indicates that the server simply doesn't support > jitter control packets. However, with all servers I tried, the plugin > returns a WARNING state _without_ explaining the problem: > > | $ ./check_ntp -H time.fu-berlin.de -j 2 -k 3 > | NTP WARNING: Offset 0.05885159969 secs|offset=0.05885159969 jitter=0.001171 > > This WARNING is issued in jitter_request(): > > | if(! syncsource_found) *status = STATE_WARNING; > > I'm not familiar with NTP and haven't tracked down whether the plugin > does something wrong while checking for the synchronization source; and > if not, whether it should really return a WARNING state here. If so, > the reason for the WARNING should certainly be mentioned in the plugin > output. For the moment, I committed patch which at least adds a line > explaining the WARNING to the verbose output. With your patch and mine, I get a bunch of "warning: unable to read server jitter response." message (I guess one per valid time source on the remote end) instead of segfault. What's very strange is that on your server in Berlin this doesn't happen all the time. It never happens on my localhost and always does on a Sun (Solaris 10) box I just set up (solaris.beaubien.net, you can try if you like). I'm under the impression that the problem is related to what is sent to the server, as either all or no request work. I'm gonna have a deeper look now... > The memcpy(3) following the realloc(3) call writes out of bounds as soon > as peer_offset is >0. I committed the following patch: > > ---------- 8< ---------------------------------------------------------- > --- check_ntp.c 31 Mar 2007 17:35:08 -0000 1.17 > +++ check_ntp.c 31 Mar 2007 18:40:46 -0000 > @@ -506,6 +506,7 @@ > ntp_control_message req; > double rval = 0.0, jitter = -1.0; > char *startofvalue=NULL, *nptr=NULL; > + void *tmp; > > /* Long-winded explanation: > * Getting the jitter requires a number of steps: > @@ -539,8 +540,10 @@ > * we represent as a ntp_assoc_status_pair datatype. > */ > npeers+=(ntohs(req.count)/sizeof(ntp_assoc_status_pair)); > - peers=(ntp_assoc_status_pair*)realloc(peers, sizeof(ntp_assoc_status_pair)*npeers); > - memcpy((void*)((ptrdiff_t)peers+peer_offset), (void*)req.data, sizeof(ntp_assoc_status_pair)*npeers); > + if((tmp=realloc(peers, sizeof(ntp_assoc_status_pair)*npeers)) == NULL) > + free(peers), die(STATE_UNKNOWN, "can not (re)allocate 'peers' buffer\n"); > + peers=tmp; > + memcpy((void*)((ptrdiff_t)peers+peer_offset), (void*)req.data, ntohs(req.count)); > peer_offset+=ntohs(req.count); > } while(req.op&REM_MORE); > ---------- 8< ---------------------------------------------------------- > > Could you test whether this fixes the problem for you? Well, strangely I couldn't reproduce the problem. What's even stranger is that I haven't recompiled anything since then. Thanks for fixing whatever was wrong there though :) Thomas From dermoth at aei.ca Mon Apr 2 07:15:04 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Mon, 02 Apr 2007 01:15:04 -0400 Subject: [Nagiosplug-devel] Flight 1.4.8, ready for boarding In-Reply-To: <20070402025010.GA49868894@CIS.FU-Berlin.DE> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> <804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com> <20070331185328.GB44795887@CIS.FU-Berlin.DE> <20070402025010.GA49868894@CIS.FU-Berlin.DE> Message-ID: <46109158.3090502@aei.ca> On 01/04/07 10:50 PM, Holger Weiss wrote: > * Holger Weiss [2007-03-31 20:53]: >> However, with all servers I tried, the plugin returns a WARNING state >> _without_ explaining the problem: >> >> | $ ./check_ntp -H time.fu-berlin.de -j 2 -k 3 >> | NTP WARNING: Offset 0.05885159969 secs|offset=0.05885159969 jitter=0.001171 >> >> This WARNING is issued in jitter_request(): >> >> | if(! syncsource_found) *status = STATE_WARNING; >> >> I'm not familiar with NTP and haven't tracked down whether the plugin >> does something wrong while checking for the synchronization source > > Just to let you know, this problem is specific to big-endian platforms. > I don't have a clean fix yet, but I guess it's not a showstopper for a > new plugins release. Yup, but this one might be one... Since in only happened once for a dozen runs at least I guess it's time to learn using core files ;) $ plugins/check_ntp -H time.fu-berlin.de -j 2 -k 3 warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. *** glibc detected *** plugins/check_ntp: double free or corruption (out): 0x0000000000508270 *** ======= Backtrace: ========= /lib/libc.so.6[0x2b61afcd1733] /lib/libc.so.6(__libc_free+0x84)[0x2b61afcd18b4] plugins/check_ntp[0x401f3c] plugins/check_ntp[0x402df6] /lib/libc.so.6(__libc_start_main+0xf4)[0x2b61afc800c4] plugins/check_ntp[0x401339] ======= Memory map: ======== 00400000-00407000 r-xp 00000000 08:02 1696134 /home/dermoth/DEV/src/nagios-plugins/nagiosplug/plugins/check_ntp 00506000-00507000 rw-p 00006000 08:02 1696134 /home/dermoth/DEV/src/nagios-plugins/nagiosplug/plugins/check_ntp 00507000-00528000 rw-p 00507000 00:00 0 [heap] 2b61af799000-2b61af7b5000 r-xp 00000000 08:02 21045 /lib/ld-2.4.so 2b61af7b5000-2b61af7b9000 rw-p 2b61af7b5000 00:00 0 2b61af8b4000-2b61af8b6000 rw-p 0001b000 08:02 21045 /lib/ld-2.4.so 2b61af8b6000-2b61af8c9000 r-xp 00000000 08:02 34268 /lib/libnsl-2.4.so 2b61af8c9000-2b61af9c9000 ---p 00013000 08:02 34268 /lib/libnsl-2.4.so 2b61af9c9000-2b61af9cb000 rw-p 00013000 08:02 34268 /lib/libnsl-2.4.so 2b61af9cb000-2b61af9cd000 rw-p 2b61af9cb000 00:00 0 2b61af9cd000-2b61af9de000 r-xp 00000000 08:02 111584 /lib/libresolv-2.4.so 2b61af9de000-2b61afade000 ---p 00011000 08:02 111584 /lib/libresolv-2.4.so 2b61afade000-2b61afae0000 rw-p 00011000 08:02 111584 /lib/libresolv-2.4.so 2b61afae0000-2b61afae2000 rw-p 2b61afae0000 00:00 0 2b61afae2000-2b61afb62000 r-xp 00000000 08:02 30271 /lib/libm-2.4.so 2b61afb62000-2b61afc61000 ---p 00080000 08:02 30271 /lib/libm-2.4.so 2b61afc61000-2b61afc63000 rw-p 0007f000 08:02 30271 /lib/libm-2.4.so 2b61afc63000-2b61afd99000 r-xp 00000000 08:02 21053 /lib/libc-2.4.so 2b61afd99000-2b61afe99000 ---p 00136000 08:02 21053 /lib/libc-2.4.so 2b61afe99000-2b61afe9c000 r--p 00136000 08:02 21053 /lib/libc-2.4.so 2b61afe9c000-2b61afe9e000 rw-p 00139000 08:02 21053 /lib/libc-2.4.so 2b61afe9e000-2b61afea5000 rw-p 2b61afe9e000 00:00 0 2b61afea5000-2b61afeaf000 r-xp 00000000 08:02 81267 /lib/libnss_files-2.4.so 2b61afeaf000-2b61affae000 ---p 0000a000 08:02 81267 /lib/libnss_files-2.4.so 2b61affae000-2b61affb0000 rw-p 00009000 08:02 81267 /lib/libnss_files-2.4.so 2b61affb0000-2b61affb4000 r-xp 00000000 08:02 81258 /lib/libnss_dns-2.4.so 2b61affb4000-2b61b00b4000 ---p 00004000 08:02 81258 /lib/libnss_dns-2.4.so 2b61b00b4000-2b61b00b6000 rw-p 00004000 08:02 81258 /lib/libnss_dns-2.4.so 2b61b0100000-2b61b0121000 rw-p 2b61b0100000 00:00 0 2b61b0121000-2b61b0200000 ---p 2b61b0121000 00:00 0 2b61b0200000-2b61b020d000 r-xp 00000000 08:02 5424 /lib/libgcc_s.so.1 2b61b020d000-2b61b030c000 ---p 0000d000 08:02 5424 /lib/libgcc_s.so.1 2b61b030c000-2b61b030d000 rw-p 0000c000 08:02 5424 /lib/libgcc_s.so.1 7ffffb2fc000-7ffffb311000 rw-p 7ffffb2fc000 00:00 0 [stack] ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vdso] Aborted (core dumped) From dermoth at aei.ca Mon Apr 2 07:43:26 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Mon, 02 Apr 2007 01:43:26 -0400 Subject: [Nagiosplug-devel] Flight 1.4.8, ready for boarding In-Reply-To: <46109158.3090502@aei.ca> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> <804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com> <20070331185328.GB44795887@CIS.FU-Berlin.DE> <20070402025010.GA49868894@CIS.FU-Berlin.DE> <46109158.3090502@aei.ca> Message-ID: <461097FE.6090203@aei.ca> More details below... On 02/04/07 01:15 AM, Thomas Guyot-Sionnest wrote: > Yup, but this one might be one... Since in only happened once for a > dozen runs at least I guess it's time to learn using core files ;) > > [...] Unfortunately I don't have this core file, but I just got some more (2 different ones). When I run check_ntp in verbose mode I see very erratic behavior from run to run. This one seems to be the new memcpy code (Holger): Core was generated by `plugins/check_ntp -H time.fu-berlin.de -j 2 -k 3'. Program terminated with signal 11, Segmentation fault. #0 0x00002b6e50790ae4 in memcpy () from /lib/libc.so.6 (gdb) bt #0 0x00002b6e50790ae4 in memcpy () from /lib/libc.so.6 #1 0x0000000000401c19 in jitter_request (host=, status=0x7fff5a856c18) at check_ntp.c:546 #2 0x0000000000402df6 in main (argc=, argv=) at check_ntp.c:750 This one is on a free operation at check_ntp.c:621: $ plugins/check_ntp -H time.fu-berlin.de -j 2 -k 3 warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. warning: unable to read server jitter response. *** glibc detected *** plugins/check_ntp: double free or corruption (!prev): 0x0000000000508270 *** ======= Backtrace: ========= /lib/libc.so.6[0x2af332d59733] /lib/libc.so.6(__libc_free+0x84)[0x2af332d598b4] plugins/check_ntp[0x401f3c] plugins/check_ntp[0x402df6] /lib/libc.so.6(__libc_start_main+0xf4)[0x2af332d080c4] plugins/check_ntp[0x401339] ======= Memory map: ======== 00400000-00407000 r-xp 00000000 08:02 1696134 /home/dermoth/DEV/src/nagios-plugins/nagiosplug/plugins/check_ntp 00506000-00507000 rw-p 00006000 08:02 1696134 /home/dermoth/DEV/src/nagios-plugins/nagiosplug/plugins/check_ntp 00507000-00528000 rw-p 00507000 00:00 0 [heap] 2af332821000-2af33283d000 r-xp 00000000 08:02 21045 /lib/ld-2.4.so 2af33283d000-2af332841000 rw-p 2af33283d000 00:00 0 2af33293c000-2af33293e000 rw-p 0001b000 08:02 21045 /lib/ld-2.4.so 2af33293e000-2af332951000 r-xp 00000000 08:02 34268 /lib/libnsl-2.4.so 2af332951000-2af332a51000 ---p 00013000 08:02 34268 /lib/libnsl-2.4.so 2af332a51000-2af332a53000 rw-p 00013000 08:02 34268 /lib/libnsl-2.4.so 2af332a53000-2af332a55000 rw-p 2af332a53000 00:00 0 2af332a55000-2af332a66000 r-xp 00000000 08:02 111584 /lib/libresolv-2.4.so 2af332a66000-2af332b66000 ---p 00011000 08:02 111584 /lib/libresolv-2.4.so 2af332b66000-2af332b68000 rw-p 00011000 08:02 111584 /lib/libresolv-2.4.so 2af332b68000-2af332b6a000 rw-p 2af332b68000 00:00 0 2af332b6a000-2af332bea000 r-xp 00000000 08:02 30271 /lib/libm-2.4.so 2af332bea000-2af332ce9000 ---p 00080000 08:02 30271 /lib/libm-2.4.so 2af332ce9000-2af332ceb000 rw-p 0007f000 08:02 30271 /lib/libm-2.4.so 2af332ceb000-2af332e21000 r-xp 00000000 08:02 21053 /lib/libc-2.4.so 2af332e21000-2af332f21000 ---p 00136000 08:02 21053 /lib/libc-2.4.so 2af332f21000-2af332f24000 r--p 00136000 08:02 21053 /lib/libc-2.4.so 2af332f24000-2af332f26000 rw-p 00139000 08:02 21053 /lib/libc-2.4.so 2af332f26000-2af332f2d000 rw-p 2af332f26000 00:00 0 2af332f2d000-2af332f37000 r-xp 00000000 08:02 81267 /lib/libnss_files-2.4.so 2af332f37000-2af333036000 ---p 0000a000 08:02 81267 /lib/libnss_files-2.4.so 2af333036000-2af333038000 rw-p 00009000 08:02 81267 /lib/libnss_files-2.4.so 2af333038000-2af33303c000 r-xp 00000000 08:02 81258 /lib/libnss_dns-2.4.so 2af33303c000-2af33313c000 ---p 00004000 08:02 81258 /lib/libnss_dns-2.4.so 2af33313c000-2af33313e000 rw-p 00004000 08:02 81258 /lib/libnss_dns-2.4.so 2af333200000-2af333221000 rw-p 2af333200000 00:00 0 2af333221000-2af333300000 ---p 2af333221000 00:00 0 2af333300000-2af33330d000 r-xp 00000000 08:02 5424 /lib/libgcc_s.so.1 2af33330d000-2af33340c000 ---p 0000d000 08:02 5424 /lib/libgcc_s.so.1 2af33340c000-2af33340d000 rw-p 0000c000 08:02 5424 /lib/libgcc_s.so.1 7fff78273000-7fff78289000 rw-p 7fff78273000 00:00 0 [stack] ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vdso] Aborted (core dumped) Core was generated by `plugins/check_ntp -H time.fu-berlin.de -j 2 -k 3'. Program terminated with signal 6, Aborted. #0 0x00002af332d1b47b in raise () from /lib/libc.so.6 (gdb) bt #0 0x00002af332d1b47b in raise () from /lib/libc.so.6 #1 0x00002af332d1cda0 in abort () from /lib/libc.so.6 #2 0x00002af332d5253b in __fsetlocking () from /lib/libc.so.6 #3 0x00002af332d59733 in mallopt () from /lib/libc.so.6 #4 0x00002af332d598b4 in free () from /lib/libc.so.6 #5 0x0000000000401f3c in jitter_request (host=, status=0x7fff78285648) at check_ntp.c:621 #6 0x0000000000402df6 in main (argc=, argv=) at check_ntp.c:750 Thomas From dermoth at aei.ca Mon Apr 2 09:42:34 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Mon, 02 Apr 2007 03:42:34 -0400 Subject: [Nagiosplug-devel] Flight 1.4.8, ready for boarding In-Reply-To: <461097FE.6090203@aei.ca> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> <804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com> <20070331185328.GB44795887@CIS.FU-Berlin.DE> <20070402025010.GA49868894@CIS.FU-Berlin.DE> <46109158.3090502@aei.ca> <461097FE.6090203@aei.ca> Message-ID: <4610B3EA.5040205@aei.ca> On 02/04/07 01:43 AM, Thomas Guyot-Sionnest wrote: > Yada yada yada (Sorry for all the spam...) I found the root cause of one of the problems. In jitter_request it creates a socket and connect to it (my_udp_connect, ~line 525), but for some reason I don't understand, that socket use the same port and sometimes receives a packet from the previous calls. That packet is a bit different but interpreted as it (no checking on the packet type), and therefore the jitter runs start with bogus data. I have no idea how to make the 2nd round of requests start from a different port, which would prevent any problem with old/late packets. Another way would be to check the packet type and skip it if it's not what we expect. Here's an example. The READSTAT response should have the flags 0x16 just like the request. In packet captures it look like a NTP packet rather than a NTP Control packet. The last line (Processing...) is one I added in my code and should read "13" for that server. sending READSTAT requestcontrol packet contents: flags: 0x16 , 0x01 li=0 (0x00) vn=2 (0x10) mode=6 (0x06) response=0 (0x00) more=0 (0x00) error=0 (0x00) op=1 (0x01) sequence: 1 (0x01) status: 0 (0x00) assoc: 0 (0x00) offset: 0 (0x00) count: 0 (0x00) recieving READSTAT responsecontrol packet contents: flags: 0x24 , 0x02 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) response=0 (0x00) more=0 (0x00) error=0 (0x00) op=2 (0x02) sequence: 1261 (0x4ed) status: 0 (0x00) assoc: 25 (0x19) offset: 0 (0x00) count: 1050 (0x41a) Processing 262 peers Thomas From ton.voon at altinity.com Mon Apr 2 11:27:36 2007 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 2 Apr 2007 10:27:36 +0100 Subject: [Nagiosplug-devel] Flight 1.4.8, ready for boarding In-Reply-To: References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> Message-ID: On 30 Mar 2007, at 23:42, Anthony Montibello wrote: > I would like to submit check_nc_net.c to the plugins, > I was working on it this week and finally have it to a good enough > point. > Whats the procedure/best way to submit this, > > check_nc_net is the check_nt used for NC_Net with all the extended > commands and enhancements I added. What do other think about this? I wasn't entirely convinced when check_nt was added into the distribution, and similarly I'm not sure why check_nc_net should be added either. We don't include check_nrpe as part of the distribution, though we do include check_by_ssh, which is an "agent" type plugin. I think I'm worried that the client code needs to be kept in sync with the server code, so should be kept together. It doesn't help anyone if Nagios Plugins distributes old code. I'd be more comfortable if there was an RFC or some other published location that detailed what the comms between the client and server are. At least this says that there is some fixed standard, so then we can say that the one distributed by us is conforming to a particular version. That's probably the difference between check_by_ssh and check_nrpe/ check_nt/check_nc_net - the interface for the agent communication is standardised. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From ton.voon at altinity.com Mon Apr 2 11:31:20 2007 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 2 Apr 2007 10:31:20 +0100 Subject: [Nagiosplug-devel] Flight 1.4.8, ready for boarding In-Reply-To: <460FCA89.8030901@mailing.kaufland-informationssysteme.com> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> <460FCA89.8030901@mailing.kaufland-informationssysteme.com> Message-ID: <298B1069-2451-429A-B77D-924EB9F5C6CA@altinity.com> On 1 Apr 2007, at 16:06, Matthias Eble wrote: > > gcc -g -O2 -o test_disk test_disk-test_disk.o ../utils_disk.o > -L/tmp/np_build.13145/nagios-plugins-HEAD-200704011200/lib/tests > -L/usr/local/lib /usr/local/lib/libtap.dylib -lpthread > > /usr/bin/ld: Undefined symbols: > _rpl_regcomp > _rpl_regexec > collect2: ld returned 1 exit status > Matthias, Looks like macosx does not include regex in the system libraries, unlike the two linux boxes that work. It just required an LDADD so that the linking pulled in the libgnu.a file that provides the regex functions. Compiles and tests run okay at the moment. The next tinderbox build should confirm. BTW, this particular build server keeps changing hostnames - which is why some test results can't be searched (as the logs are indexed by hostname). I'll see if I can fix. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From holger at CIS.FU-Berlin.DE Mon Apr 2 14:45:53 2007 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Mon, 2 Apr 2007 14:45:53 +0200 Subject: [Nagiosplug-devel] Flight 1.4.8, ready for boarding In-Reply-To: <461097FE.6090203@aei.ca> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> <804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com> <20070331185328.GB44795887@CIS.FU-Berlin.DE> <20070402025010.GA49868894@CIS.FU-Berlin.DE> <46109158.3090502@aei.ca> <461097FE.6090203@aei.ca> Message-ID: <20070402124552.GB49868894@CIS.FU-Berlin.DE> * Thomas Guyot-Sionnest [2007-04-02 01:43]: > Unfortunately I don't have this core file, but I just got some more (2 > different ones). I just committed another fix, could you check whether you still get segfaults? Thanks, Holger -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE From dermoth at aei.ca Mon Apr 2 15:17:55 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Mon, 02 Apr 2007 09:17:55 -0400 Subject: [Nagiosplug-devel] Flight 1.4.8, ready for boarding In-Reply-To: <20070402124552.GB49868894@CIS.FU-Berlin.DE> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> <804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com> <20070331185328.GB44795887@CIS.FU-Berlin.DE> <20070402025010.GA49868894@CIS.FU-Berlin.DE> <46109158.3090502@aei.ca> <461097FE.6090203@aei.ca> <20070402124552.GB49868894@CIS.FU-Berlin.DE> Message-ID: <46110283.7020208@aei.ca> On 02/04/07 08:45 AM, Holger Weiss wrote: > * Thomas Guyot-Sionnest [2007-04-02 01:43]: >> Unfortunately I don't have this core file, but I just got some more (2 >> different ones). > > I just committed another fix, could you check whether you still get > segfaults? I've been running it in loops for a few minutes now and no segfault yet. This seems like you fixed it for good :) Do you have any idea how we should go about the other problem? We could loop on reads until we get the packet type we want, but what about the source port? Do you have any idea how we could make sure we get a new one when we connect the 2nd time? Thanks, Thomas From amontibello at gmail.com Mon Apr 2 16:30:23 2007 From: amontibello at gmail.com (Anthony Montibello) Date: Mon, 2 Apr 2007 10:30:23 -0400 Subject: [Nagiosplug-devel] Flight 1.4.8, ready for boarding In-Reply-To: References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> Message-ID: Thanks for the responce, I am not trying to push the issue, but I wanted to make sure I explained my addition request. I agree with the Client/server versions being kept together, and that is how I have been distributing the source. I am not very familiar with How or Where to publish a RFC, but I would be happy to contribute to one. Is there anyone who can asssist in getting this started? I suggested including the newest version of check_nc_net (that I finished this week) because of particular reasons: - It is fully compatible with the older check_nt, (I made only bug fixes to these checks that the original check_nt preforms) So for the commands offered in check_nt it will work with any server: NC_NEt,NS_Client,NS_Client++. - the new command (-v OTHER) that allows for issuing any command to the server side. - A more comprehensive help system by using --help=<-v command> this gives help on the particular command. - It is easier to Nagios users that want to use any of the enhancements that NC_NEt offers, by already having the plugin compile with the Nagios Plugins. (while still preserving the old check_nt) - I also added a switch that allows for output to extend beyond the 1249 bytes (for when server side has extended outputs) once again, thank you for the responce. I suggested its addition because I thought it would be benifit to Nagios comunity. Tony (Author of NC_Net) tony at montitech.com On 4/2/07, Ton Voon wrote: > > > On 30 Mar 2007, at 23:42, Anthony Montibello wrote: > > > I would like to submit check_nc_net.c to the plugins, > > I was working on it this week and finally have it to a good enough > > point. > > Whats the procedure/best way to submit this, > > > > check_nc_net is the check_nt used for NC_Net with all the extended > > commands and enhancements I added. > > What do other think about this? > > I wasn't entirely convinced when check_nt was added into the > distribution, and similarly I'm not sure why check_nc_net should be > added either. We don't include check_nrpe as part of the > distribution, though we do include check_by_ssh, which is an "agent" > type plugin. > > I think I'm worried that the client code needs to be kept in sync > with the server code, so should be kept together. It doesn't help > anyone if Nagios Plugins distributes old code. > > I'd be more comfortable if there was an RFC or some other published > location that detailed what the comms between the client and server > are. At least this says that there is some fixed standard, so then we > can say that the one distributed by us is conforming to a particular > version. > > That's probably the difference between check_by_ssh and check_nrpe/ > check_nt/check_nc_net - the interface for the agent communication is > standardised. > > Ton > > http://www.altinity.com > T: +44 (0)870 787 9243 > F: +44 (0)845 280 1725 > Skype: tonvoon > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________________ > Nagios Plugin Development Mailing List > Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > -------------- next part -------------- An HTML attachment was scrubbed... URL: From seanius at seanius.net Tue Apr 3 00:08:57 2007 From: seanius at seanius.net (sean finney) Date: Tue, 03 Apr 2007 00:08:57 +0200 Subject: [Nagiosplug-devel] Flight 1.4.8, ready for boarding In-Reply-To: <46110283.7020208@aei.ca> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> <804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com> <20070331185328.GB44795887@CIS.FU-Berlin.DE> <20070402025010.GA49868894@CIS.FU-Berlin.DE> <46109158.3090502@aei.ca> <461097FE.6090203@aei.ca> <20070402124552.GB49868894@CIS.FU-Berlin.DE> <46110283.7020208@aei.ca> Message-ID: <1175551737.5284.48.camel@localhost> hey guys, i guess i ought to chime in on the issue, having written the code in the first place :) On Mon, 2007-04-02 at 09:17 -0400, Thomas Guyot-Sionnest wrote: > Do you have any idea how we should go about the other problem? We could > loop on reads until we get the packet type we want, but what about the > source port? Do you have any idea how we could make sure we get a new > one when we connect the 2nd time? it ought to be possible to set up a second udp socket for every host without too much trouble. i believe that unless bind() is called the source port is random, so two sockets should mean two different source ports implicitly--and udp being what it is the remote server shouldn't mind sending one packet to one port and on packet to the other. this should probably prevent the problems with late/re-transmitted ntp time packets getting mixed up with the control packets. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From dermoth at aei.ca Tue Apr 3 02:04:03 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Mon, 02 Apr 2007 20:04:03 -0400 Subject: [Nagiosplug-devel] Flight 1.4.8, ready for boarding In-Reply-To: <1175551737.5284.48.camel@localhost> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> <804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com> <20070331185328.GB44795887@CIS.FU-Berlin.DE> <20070402025010.GA49868894@CIS.FU-Berlin.DE> <46109158.3090502@aei.ca> <461097FE.6090203@aei.ca> <20070402124552.GB49868894@CIS.FU-Berlin.DE> <46110283.7020208@aei.ca> <1175551737.5284.48.camel@localhost> Message-ID: <461199F3.2000506@aei.ca> On 02/04/07 06:08 PM, sean finney wrote: > hey guys, > > i guess i ought to chime in on the issue, having written the code in the > first place :) > > On Mon, 2007-04-02 at 09:17 -0400, Thomas Guyot-Sionnest wrote: >> Do you have any idea how we should go about the other problem? We could >> loop on reads until we get the packet type we want, but what about the >> source port? Do you have any idea how we could make sure we get a new >> one when we connect the 2nd time? > > it ought to be possible to set up a second udp socket for every host > without too much trouble. i believe that unless bind() is called the > source port is random, so two sockets should mean two different source > ports implicitly--and udp being what it is the remote server shouldn't > mind sending one packet to one port and on packet to the other. this > should probably prevent the problems with late/re-transmitted ntp time > packets getting mixed up with the control packets. There might be another way. According to the article below to disconnect a UDP socket you have to call connect with the family member of the socket address structure to AF_UNSPEC. If you don't beat me it time I'll try to code that and see what happens. http://kerneltrap.org/node/7491 If someone can tell me what should I use for the 3rd arg of connect() that'll help, otherwise it won't take me long to figure it out :) Thomas From gavin at openfusion.com.au Tue Apr 3 02:11:23 2007 From: gavin at openfusion.com.au (Gavin Carr) Date: Tue, 3 Apr 2007 10:11:23 +1000 Subject: [Nagiosplug-devel] Nagios::Plugin with multiple threshold limits? In-Reply-To: References: Message-ID: <20070403001123.GB408@openfusion.com.au> Hi Klaus, I'm copying the Nagios Plug-Devel list as well, since we usually try to discuss Nagios::Plugin stuff on-list there. On Mon, Apr 02, 2007 at 06:28:00PM +0200, Pesendorfer, Klaus wrote: > I've discovered your really nice Perl module Nagios::Plugin these days and began > to test it for my needs. Great! We're very interested in people starting to use it for real tasks now, so we value your feedback. I take it you're using version 0.17, right? > Now I'm at the point where the documentation doesn't tell me any more details, > I would like to know. > > Is it possible to use more than one threshold definition in one call? > > So that I could for example check the 3 load average parameters with -w 5,6,7 > -c 10,11,12 [I know that a check_load plugin exists ... that's only an example ;-) ] > > Alternatively the Nagios Plugin Devel-Guidelines allow the syntax: -w 5 -w 6 -w 7 > -c 10 -c 11 -c 12 (I do prefer the first one more) Right now we don't have builtin support for multiple thresholds, but it would be nice. I'll add it to the TODO list. That said, you should be able to handle multiple thresholds right now pretty easily - see below. > The first method could not be parsed as integers, I guess you mean? Yes, you've have to specify it as a string and then split on the commas at the moment. > and the second one's problem is, that the parsed parameters overwrite themselves. This should work fine, but you'd need to specify the argument as an array e.g. spec => 'warning|w=i@' # OR: spec => 'warning|w=s@' in which case $np->opts->warning would be an array reference, and you could do something like this, given an @check array of values to check: for my $i ( 0 .. $#check ) { $code = $np->check_threshold( check => $check[$i], warning => $np->opts->warning->[$i], critical => $np->opts->critical->[$i], ); # Do something if $code != OK } > (Is it possible to store more than one threshold object in the plugin data structure > or do I need to store them somewhere else?) You shouldn't usually need to manipulate threshold objects directly - you should be able to do what you want via check_threshold. We do need to add a couple of things here though - a way of specifying that a given argument is actually a threshold (at the moment by and large we just treat everything as scalars); and support for sets of thresholds, rather than just one. > p.s.: Do I really need all these perl requirements? (Class:Accessor, Params::Validate, > Config::Tiny, Math::Calc::Units) I think in some ways we're still discussing this. We're trying to find a balance between requiring a minimal number of dependencies, and not reinventing the wheel when there are already standardised solutions out there on CPAN. > The dependency "Test::More" was only solvable by settinging the version to 0 instead > of 0.62 (by using the default perl Modules of V.5.8.5). (did I do something wrong?) That's probably set too high then. What version of Test::More do you have, and what's your platform? perl -MTest::More -le 'print $Test::More::VERSION' Regards, Gavin From holger at CIS.FU-Berlin.DE Tue Apr 3 03:52:22 2007 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Tue, 3 Apr 2007 03:52:22 +0200 Subject: [Nagiosplug-devel] Flight 1.4.8, ready for boarding In-Reply-To: <4610903E.9070407@aei.ca> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> <804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com> <20070331185328.GB44795887@CIS.FU-Berlin.DE> <4610903E.9070407@aei.ca> Message-ID: <20070403015222.GC49868894@CIS.FU-Berlin.DE> * Thomas Guyot-Sionnest [2007-04-02 01:10]: > On 31/03/07 02:53 PM, Holger Weiss wrote: > > The memcpy(3) following the realloc(3) call writes out of bounds as soon > > as peer_offset is >0. I committed the following patch: [...] > > > > Could you test whether this fixes the problem for you? > > Well, strangely I couldn't reproduce the problem. What's even stranger > is that I haven't recompiled anything since then. Thanks for fixing > whatever was wrong there though :) JFTR, this fix is only relevant if the READSTAT do/while() loop in jitter_request() is executed more than once (in which case peer_offset is >0). While this usually won't happen (so that the problem wasn't easily reproducible), my guess is that it did happen in your case. Holger -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE From dermoth at aei.ca Tue Apr 3 04:23:33 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Mon, 02 Apr 2007 22:23:33 -0400 Subject: [Nagiosplug-devel] Flight 1.4.8, ready for boarding In-Reply-To: <461199F3.2000506@aei.ca> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> <804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com> <20070331185328.GB44795887@CIS.FU-Berlin.DE> <20070402025010.GA49868894@CIS.FU-Berlin.DE> <46109158.3090502@aei.ca> <461097FE.6090203@aei.ca> <20070402124552.GB49868894@CIS.FU-Berlin.DE> <46110283.7020208@aei.ca> <1175551737.5284.48.camel@localhost> <461199F3.2000506@aei.ca> Message-ID: <4611BAA5.8080009@aei.ca> On 02/04/07 08:04 PM, Thomas Guyot-Sionnest wrote: > On 02/04/07 06:08 PM, sean finney wrote: >> hey guys, >> >> i guess i ought to chime in on the issue, having written the code in the >> first place :) >> >> On Mon, 2007-04-02 at 09:17 -0400, Thomas Guyot-Sionnest wrote: >>> Do you have any idea how we should go about the other problem? We could >>> loop on reads until we get the packet type we want, but what about the >>> source port? Do you have any idea how we could make sure we get a new >>> one when we connect the 2nd time? >> it ought to be possible to set up a second udp socket for every host >> without too much trouble. i believe that unless bind() is called the >> source port is random, so two sockets should mean two different source >> ports implicitly--and udp being what it is the remote server shouldn't >> mind sending one packet to one port and on packet to the other. this >> should probably prevent the problems with late/re-transmitted ntp time >> packets getting mixed up with the control packets. > > There might be another way. According to the article below to disconnect > a UDP socket you have to call connect with the family member of the > socket address structure to AF_UNSPEC. If you don't beat me it time I'll > try to code that and see what happens. > > http://kerneltrap.org/node/7491 > > If someone can tell me what should I use for the 3rd arg of connect() > that'll help, otherwise it won't take me long to figure it out :) Using AF_UNSPEC didn't work, so my fix was simply not to close the sockets. While this works, I left a note in the code explaining why and looking for a better way. Should I open a new, low priority bug for that? The proper way to verify that new code fix the problem it to: 1. Uncomment the line where it closes the sockets. 2. Confirm using packet captures that both NTP and NTP Control messages use the same local port. If they don't, find a system where they do (Ubuntu 6.10 do) 3. Fix it. 4. Confirm on the same system as (2) that the NTP and NTP Control messages use different local ports. Please also note that I still can't get the jitter on my sun box (solaris.beaubien.net). According to Holger this could be due to the byte order, though running check_ntp on that sun box still give me the same results (is that expected?). One last note, I get different results on my sun box than on my home computer (Ububtu). I'll investigate this a little bit... Thomas From dermoth at aei.ca Tue Apr 3 04:34:42 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Mon, 02 Apr 2007 22:34:42 -0400 Subject: [Nagiosplug-devel] Flight 1.4.8, ready for boarding In-Reply-To: <20070403015222.GC49868894@CIS.FU-Berlin.DE> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> <804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com> <20070331185328.GB44795887@CIS.FU-Berlin.DE> <4610903E.9070407@aei.ca> <20070403015222.GC49868894@CIS.FU-Berlin.DE> Message-ID: <4611BD42.4060600@aei.ca> On 02/04/07 09:52 PM, Holger Weiss wrote: > * Thomas Guyot-Sionnest [2007-04-02 01:10]: >> On 31/03/07 02:53 PM, Holger Weiss wrote: >>> The memcpy(3) following the realloc(3) call writes out of bounds as soon >>> as peer_offset is >0. I committed the following patch: [...] >>> >>> Could you test whether this fixes the problem for you? >> Well, strangely I couldn't reproduce the problem. What's even stranger >> is that I haven't recompiled anything since then. Thanks for fixing >> whatever was wrong there though :) > > JFTR, this fix is only relevant if the READSTAT do/while() loop in > jitter_request() is executed more than once (in which case peer_offset > is >0). While this usually won't happen (so that the problem wasn't > easily reproducible), my guess is that it did happen in your case. This likely happened sometimes when it was reading an old NTP packet before tonight's fix. Every time this happened (reading an old NTP packet, and it did very often) the results were totally random. Thomas From noreply at sourceforge.net Tue Apr 3 07:07:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Apr 2007 22:07:45 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1556886 ] check_ntp ---> Memory fault Message-ID: Bugs item #1556886, was opened at 2006-09-12 03:24 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1556886&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: CVS >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Ciro Iriarte (cyruspy) Assigned to: Ton Voon (tonvoon) Summary: check_ntp ---> Memory fault Initial Comment: The plugin works fine if i don't ask for jitter checking, but if i do it just gives Memory Fault. Linux x86_64: asusis-ope2:/etc/nagios # /usr/lib/nagios/plugins/check_ntp -H 10.129.4.140 -j 2 -k 3 Segmentation fault asusis-ope2:/etc/nagios # /usr/lib/nagios/plugins/check_ntp -H 10.129.4.140 -j 2.0 -k 3.0 Segmentation fault asusis-ope2:/etc/nagios # /usr/lib/nagios/plugins/check_ntp -H 10.129.4.140 -j 2,0 -k 3,0 Segmentation fault Tru64: iriartec at es45-1:/usr/users/iriartec/src/nagios-plugins-HEAD-200609062352/plugins> ./check_ntp -H 10.129.4.140 -j 2 -k 3 Memory fault iriartec at es45-1:/usr/users/iriartec/src/nagios-plugins-HEAD-200609062352/plugins> ./check_ntp -H 10.129.4.140 -j 2.0 -k 3.0 Memory fault iriartec at es45-1:/usr/users/iriartec/src/nagios-plugins-HEAD-200609062352/plugins> ./check_ntp -H 10.129.4.140 -j 2,0 -k 3,0 Memory fault ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2007-04-03 01:07 Message: Logged In: YES user_id=375623 Originator: NO A few fixes have been committed in CVS including this one. You can try with CVS HEAD, next snapshot (the one that will be dated Apr 03) or wait for the next release that will come very soon. There is still an issue when using check_ntp with -j/-k on Big-endian architectures (ex. Sun) that may take a bit longer to fix. ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-03-29 07:37 Message: Logged In: YES user_id=375623 Originator: NO The attached patch fixes the segfault on my prod servers, but returns a warning because it can't seems to get the jitter. While getting the jitter seems to be the root of the problem I believe it wouldn't be a bad idea to apply this patch as well. I'll leave the patch to whoever fix the problem though because I don't understand much about NTP ;) File Added: check_ntp.startofvalue.patch ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-03-29 06:41 Message: Logged In: YES user_id=375623 Originator: NO I just tested on my servers and I get SEGV for both 1.4.6 and HEAD: root at josianne:/tmp/nagiosplug# plugins/check_ntp -H 64.94.137.1 -j 2 -k 3 root at josianne:/tmp/nagiosplug# plugins/check_ntp -H 64.94.137.1 NTP OK: Offset -0.0002659001038 secs|offset=-0.0002659001038 root at josianne:/tmp/nagiosplug# gdb plugins/check_ntp GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-slackware-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run -H 64.94.137.1 -j 2 -k 3 Starting program: /tmp/nagiosplug/plugins/check_ntp -H 64.94.137.1 -j 2 -k 3 Program received signal SIGSEGV, Segmentation fault. 0xb7e5a9a1 in ____strtod_l_internal () from /lib/tls/libc.so.6 (gdb) bt #0 0xb7e5a9a1 in ____strtod_l_internal () from /lib/tls/libc.so.6 #1 0xb7e57ec8 in __strtod_internal () from /lib/tls/libc.so.6 #2 0x0804a1af in jitter_request (host=0x804f0b0 "64.94.137.1", status=0xbfd903f0) at /usr/include/stdlib.h:327 #3 0x0804a8a2 in main (argc=7, argv=0xbfd90494) at check_ntp.c:748 ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2007-03-29 05:38 Message: Logged In: YES user_id=664364 Originator: NO Ciro, Can you please try the snapshot as I think this is fixed. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1556886&group_id=29880 From seanius at seanius.net Tue Apr 3 08:25:48 2007 From: seanius at seanius.net (sean finney) Date: Tue, 03 Apr 2007 08:25:48 +0200 Subject: [Nagiosplug-devel] Flight 1.4.8, ready for boarding In-Reply-To: <461199F3.2000506@aei.ca> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> <804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com> <20070331185328.GB44795887@CIS.FU-Berlin.DE> <20070402025010.GA49868894@CIS.FU-Berlin.DE> <46109158.3090502@aei.ca> <461097FE.6090203@aei.ca> <20070402124552.GB49868894@CIS.FU-Berlin.DE> <46110283.7020208@aei.ca> <1175551737.5284.48.camel@localhost> <461199F3.2000506@aei.ca> Message-ID: <1175581548.30348.6.camel@localhost> hey, On Mon, 2007-04-02 at 20:04 -0400, Thomas Guyot-Sionnest wrote: > There might be another way. According to the article below to disconnect > a UDP socket you have to call connect with the family member of the > socket address structure to AF_UNSPEC. If you don't beat me it time I'll > try to code that and see what happens. > > http://kerneltrap.org/node/7491 from a speed standpoint, i think the 2-socketed approach is a little better because you can pre-allocate them, and no further action is needed at runtime. so, faster at the expense of a some extra fd's. > If someone can tell me what should I use for the 3rd arg of connect() > that'll help, otherwise it won't take me long to figure it out :) sizeof(struct sockaddr_in) i believe. i guess this value would be different for ipv6 though. currently in the code we use getaddrinfo's results for the first batch of sockets. the nice thing about that is iirc the info passed back is compatible with ipv6 as well (the length is a field in the results), so i guess that'd be another argument for the 2 sockets approach. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From seanius at seanius.net Tue Apr 3 08:29:39 2007 From: seanius at seanius.net (sean finney) Date: Tue, 03 Apr 2007 08:29:39 +0200 Subject: [Nagiosplug-devel] Flight 1.4.8, ready for boarding In-Reply-To: <4611BAA5.8080009@aei.ca> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> <804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com> <20070331185328.GB44795887@CIS.FU-Berlin.DE> <20070402025010.GA49868894@CIS.FU-Berlin.DE> <46109158.3090502@aei.ca> <461097FE.6090203@aei.ca> <20070402124552.GB49868894@CIS.FU-Berlin.DE> <46110283.7020208@aei.ca> <1175551737.5284.48.camel@localhost> <461199F3.2000506@aei.ca> <4611BAA5.8080009@aei.ca> Message-ID: <1175581779.30348.10.camel@localhost> hey again :) > Please also note that I still can't get the jitter on my sun box > (solaris.beaubien.net). According to Holger this could be due to the > byte order, though running check_ntp on that sun box still give me the > same results (is that expected?). i wouldn't be surprised if it were either a byte-order issue or a 32/64 bit thing. i'd done my best to properly use ntoh[sl]/hton[sl] where appropriate, but it's possible i've missed something, or that there's a mistake buriend in all the bit-mangling going on. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From ae at op5.se Tue Apr 3 11:57:53 2007 From: ae at op5.se (Andreas Ericsson) Date: Tue, 03 Apr 2007 11:57:53 +0200 Subject: [Nagiosplug-devel] Flight 1.4.8, ready for boarding In-Reply-To: <461199F3.2000506@aei.ca> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> <804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com> <20070331185328.GB44795887@CIS.FU-Berlin.DE> <20070402025010.GA49868894@CIS.FU-Berlin.DE> <46109158.3090502@aei.ca> <461097FE.6090203@aei.ca> <20070402124552.GB49868894@CIS.FU-Berlin.DE> <46110283.7020208@aei.ca> <1175551737.5284.48.camel@localhost> <461199F3.2000506@aei.ca> Message-ID: <46122521.8010402@op5.se> Thomas Guyot-Sionnest wrote: > On 02/04/07 06:08 PM, sean finney wrote: > > There might be another way. According to the article below to disconnect > a UDP socket you have to call connect with the family member of the > socket address structure to AF_UNSPEC. If you don't beat me it time I'll > try to code that and see what happens. > Linux doesn't support disconnecting by specifying AF_UNSPEC, as per the connect(2) man-page. BUGS Unconnecting a socket by calling connect() with a AF_UNSPEC address is not yet implemented. > > If someone can tell me what should I use for the 3rd arg of connect() > that'll help, otherwise it won't take me long to figure it out :) > sizeof(struct sockaddr), as Sean has already pointed out. You shouldn't have to use connect(2) at all, as UDP is not a stateful protocol. Instead you should be able to use sendto(2) and recvfrom(2). I'll have a look at it and see if I can find something. For techincal completeness; connect(2) only associates a socket with the specified address inside the kernel. If it's used with UDP sockets, no further action is taken. If used with a TCP socket, the 3-way TCP handshake is initiated and the caller is by default made to wait the predefined socket timeout value if no connection can be established. The socket timeout can be set by using setsockopt(2). -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From ae at op5.se Tue Apr 3 12:03:48 2007 From: ae at op5.se (Andreas Ericsson) Date: Tue, 03 Apr 2007 12:03:48 +0200 Subject: [Nagiosplug-devel] [Nagiosplug-checkins] nagiosplug/plugins check_ntp.c, 1.21, 1.22 In-Reply-To: References: Message-ID: <46122684.3000907@op5.se> Thomas Guyot wrote: > Update of /cvsroot/nagiosplug/nagiosplug/plugins > In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv18344/plugins > > Modified Files: > check_ntp.c > Log Message: > Temporary fix for jitter calculation > > > Index: check_ntp.c > =================================================================== > RCS file: /cvsroot/nagiosplug/nagiosplug/plugins/check_ntp.c,v > retrieving revision 1.21 > retrieving revision 1.22 > diff -u -d -r1.21 -r1.22 > --- check_ntp.c 2 Apr 2007 12:39:30 -0000 1.21 > +++ check_ntp.c 3 Apr 2007 01:31:25 -0000 1.22 > @@ -475,7 +475,10 @@ > } > > /* cleanup */ > - for(j=0; j + /* FIXME: Not closing the socket to avoid re-use of the local port > + * which can cause old NTP packets to be read instead of NTP control > + * pactets in jitter_request(). THERE MUST BE ANOTHER WAY... > + * for(j=0; j References: <20070331185328.GB44795887@CIS.FU-Berlin.DE> <20070402025010.GA49868894@CIS.FU-Berlin.DE> <46109158.3090502@aei.ca> <461097FE.6090203@aei.ca> <20070402124552.GB49868894@CIS.FU-Berlin.DE> <46110283.7020208@aei.ca> <1175551737.5284.48.camel@localhost> <461199F3.2000506@aei.ca> <4611BAA5.8080009@aei.ca> <1175581779.30348.10.camel@localhost> Message-ID: <20070403171443.GF49868894@CIS.FU-Berlin.DE> * sean finney [2007-04-03 08:29]: > > Please also note that I still can't get the jitter on my sun box > > (solaris.beaubien.net). According to Holger this could be due to the > > byte order, though running check_ntp on that sun box still give me the > > same results (is that expected?). I don't know why getting the jitter doesn't work with your box (and quite a few other servers I tried). The problem I mentioned was that jitter_request() will issue a WARNING because it doesn't detect the synchronizatin source if check_ntp is run on a big-endian system. > i wouldn't be surprised if it were either a byte-order issue or a 32/64 > bit thing. i'd done my best to properly use ntoh[sl]/hton[sl] where > appropriate, but it's possible i've missed something, or that there's a > mistake buriend in all the bit-mangling going on. The sync source is found using the value of PEER_SEL(peers[i].status), where peers[i].status (which is a 16-bit value) is read without a prior ntohs(3). So, on little-endian, the bytes are the wrong way round. However, PEER_SEL() reads the low-order byte of the status field, while it should read the high-order byte. Therefore, it actually works on little-endian, but not on big-endian systems. I'll fix that in a minute. Holger -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE From benoit.mortier at opensides.be Tue Apr 3 21:30:10 2007 From: benoit.mortier at opensides.be (Benoit Mortier) Date: Tue, 3 Apr 2007 21:30:10 +0200 Subject: [Nagiosplug-devel] Flight 1.4.8, ready for boarding In-Reply-To: References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> Message-ID: <200704032130.11465.benoit.mortier@opensides.be> Le Lundi 2 Avril 2007 16:30, Anthony Montibello a ?crit?: > Thanks for the responce, > I am not trying to push the issue, but I wanted to make sure I explained > my addition request. > > I agree with the Client/server versions being kept together, and that is > how I have been distributing the source. > > I am not very familiar with How or Where to publish a RFC, but I would be > happy to contribute to one. Is there anyone who can asssist in getting > this started? > > I suggested including the newest version of check_nc_net (that I finished > this week) because of particular reasons: > > - It is fully compatible with the older check_nt, (I made only bug > fixes to these checks that the original check_nt preforms) So for the > commands offered in check_nt it will work with any server: > NC_NEt,NS_Client,NS_Client++. Hello, if it works with all the clients and can replace the actual check_nt it's ok for me. And of course we could make sure that an rfc for the communication should be published along the plugin. my 2 cents Cheers -- Benoit Mortier CEO www.opensides.be Contributor to Gosa Project : http://gosa.gonicus.de/ Contributeur to Nagios Plugins : http://nagiosplug.sourceforge.net/ From dermoth at aei.ca Wed Apr 4 04:31:43 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 03 Apr 2007 22:31:43 -0400 Subject: [Nagiosplug-devel] check_ntp: Getting jitter on xntpd Message-ID: <46130E0F.4070106@aei.ca> I reverse-engineered a bit the NTP protocol and found out how to get the jitter data on xntpd (ex. Solaris). Basically xntpd does not seems to support getting specific values (or at least not jitter). By sending a READVAL request with no data all servers will return all their values (in multiple packets hence the quick and dirty my_udp_connect() in the loop). While the "ntpq -p" command prints "rootdispersion=" as it, given the results I get it's possible that this value has to be divided, though it's also well possible that my Sun server it too crappy to get decent jitters. So I made a rough patch that allow to check the jitter on both kind of servers. It look for "jitter=" and If not found it will look for "rootdispersion=" (xntpd). If either is found it will extract the jitter value just as usual. Any comment or suggestion? Do you think it should be included as it or should be polished a bit (ex. looping on reads, sending all packets then polling on the sockets, or anything else...). Thanks Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: check_ntp.xntpd_jitter_draft.patch Type: text/x-patch Size: 1628 bytes Desc: not available URL: From dermoth at aei.ca Wed Apr 4 05:06:27 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 03 Apr 2007 23:06:27 -0400 Subject: [Nagiosplug-devel] check_ntp: Getting jitter on xntpd In-Reply-To: <46130E0F.4070106@aei.ca> References: <46130E0F.4070106@aei.ca> Message-ID: <46131633.90401@aei.ca> On 03/04/07 10:31 PM, Thomas Guyot-Sionnest wrote: > I reverse-engineered a bit the NTP protocol and found out how to get the > jitter data on xntpd (ex. Solaris). > > Basically xntpd does not seems to support getting specific values (or at > least not jitter). By sending a READVAL request with no data all servers > will return all their values (in multiple packets hence the quick and > dirty my_udp_connect() in the loop). > > While the "ntpq -p" command prints "rootdispersion=" as it, given the > results I get it's possible that this value has to be divided, though > it's also well possible that my Sun server it too crappy to get decent > jitters. > > So I made a rough patch that allow to check the jitter on both kind of > servers. It look for "jitter=" and If not found it will look for > "rootdispersion=" (xntpd). If either is found it will extract the jitter > value just as usual. > > Any comment or suggestion? Do you think it should be included as it or > should be polished a bit (ex. looping on reads, sending all packets then > polling on the sockets, or anything else...). The previous patch was broken. 1: I was too confident on how to get the correct pointer. 2: I should have used " dispersion=" instead of "rootdispersion=". This one should be good. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: check_ntp.xntpd_jitter_draft.patch Type: text/x-patch Size: 1649 bytes Desc: not available URL: From dermoth at aei.ca Wed Apr 4 19:37:58 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Wed, 04 Apr 2007 13:37:58 -0400 Subject: [Nagiosplug-devel] check_ntp (Was: Flight 1.4.8, ready for boarding) In-Reply-To: <1175581779.30348.10.camel@localhost> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> <804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com> <20070331185328.GB44795887@CIS.FU-Berlin.DE> <20070402025010.GA49868894@CIS.FU-Berlin.DE> <46109158.3090502@aei.ca> <461097FE.6090203@aei.ca> <20070402124552.GB49868894@CIS.FU-Berlin.DE> <46110283.7020208@aei.ca> <1175551737.5284.48.camel@localhost> <461199F3.2000506@aei.ca> <4611BAA5.8080009@aei.ca> <1175581779.30348.10.camel@localhost> Message-ID: <4613E276.5080507@aei.ca> On 03/04/07 02:29 AM, sean finney wrote: > hey again :) > >> Please also note that I still can't get the jitter on my sun box >> (solaris.beaubien.net). According to Holger this could be due to the >> byte order, though running check_ntp on that sun box still give me the >> same results (is that expected?). > > i wouldn't be surprised if it were either a byte-order issue or a 32/64 > bit thing. i'd done my best to properly use ntoh[sl]/hton[sl] where > appropriate, but it's possible i've missed something, or that there's a > mistake buriend in all the bit-mangling going on. Hi Sean, The problem with xntpd it that it doesn't have a jitter value (ntp v3). I'll work up a patch a bit different than what I sent but basically it'll do the same: take dispersion in place for jitter. While we were working on this check, me and Holger raised up a few issues. I worked up a todo list and I'd like to share it with you. Only the older ntp client support would go in before the 1.4.8 release. 1. Older ntp server support (I'm working on it) 2. The offset and jitter doesn't change on every call, so there's no reason to poll 4 times and compute the average. I'd like to remove all code related to that. 3. Allow to use -H multiple times 3a. Do one lookup for the servers and store an array of IPs for the various functions. (Is it worth it? Will avoid code duplcation implementing #4) 4. When multiple servers are specified (either multiple IP per hostname or multiple -H aguments, check the jitter for all servers. 5. Look into the possibility of storing some of the sent header in a linked list on write and then match them on reads. That will allow to send all packets as fast as possible (ex. when checking the jitter of all sync candidates) and also to easily drop odd packets. If put in a separate routine that would also allow to easily loop for additional packets and append the data. (Any other suggestion?) Thanks, Thomas From seanius at seanius.net Wed Apr 4 22:03:41 2007 From: seanius at seanius.net (sean finney) Date: Wed, 04 Apr 2007 22:03:41 +0200 Subject: [Nagiosplug-devel] check_ntp (Was: Flight 1.4.8, ready for boarding) In-Reply-To: <4613E276.5080507@aei.ca> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> <804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com> <20070331185328.GB44795887@CIS.FU-Berlin.DE> <20070402025010.GA49868894@CIS.FU-Berlin.DE> <46109158.3090502@aei.ca> <461097FE.6090203@aei.ca> <20070402124552.GB49868894@CIS.FU-Berlin.DE> <46110283.7020208@aei.ca> <1175551737.5284.48.camel@localhost> <461199F3.2000506@aei.ca> <4611BAA5.8080009@aei.ca> <1175581779.30348.10.camel@localhost> <4613E276.5080507@aei.ca> Message-ID: <1175717021.5377.29.camel@localhost> hey thomas, On Wed, 2007-04-04 at 13:37 -0400, Thomas Guyot-Sionnest wrote: > The problem with xntpd it that it doesn't have a jitter value (ntp v3). > I'll work up a patch a bit different than what I sent but basically > it'll do the same: take dispersion in place for jitter. okay. i *think* that's the same thing with just a different name, right? > While we were working on this check, me and Holger raised up a few > issues. I worked up a todo list and I'd like to share it with you. Only > the older ntp client support would go in before the 1.4.8 release. > > 1. Older ntp server support (I'm working on it) > > 2. The offset and jitter doesn't change on every call, so there's no > reason to poll 4 times and compute the average. I'd like to remove all > code related to that. one of the design goals when i first wrote the plugin was to mimick as closely as possible the behaviour of the previous perl-based check_ntp plugin. after analyzing the plugin plus the source for ntp plus packet dumping what the ntp cmdline programs did, this was the behaviour i found. that doesn't necessarily mean that various behaviours are the ideal behaviour, but just so you know where it came from :) but anyway, as far sampling/averaging goes, the offset/delay can vary a bit more if the network is less than reliable iirc, hence the multiple requests. this is what the ntp cmdline client does as well. > 3. Allow to use -H multiple times seems reasonable, though i'd probably have a seperate nagios check for each host. see comments below for (4) though. > 3a. Do one lookup for the servers and store an array of IPs for the > various functions. (Is it worth it? Will avoid code duplcation > implementing #4) isn't that what's already done with the getaddrinfo(), and array-of-sockets allocation? > 4. When multiple servers are specified (either multiple IP per hostname > or multiple -H aguments, check the jitter for all servers. i think this falls back into the mimicking-behaviour design again. previously i believe we only checked the jitter on the remote clock declared as the sync source, but i could be wrong. i don't really think this is the *right* behaviour, but before i went fixing it the idea was to get something that was compatible with the current versoin. actually, istr someone pointing out several months ago that we were really doing the wrong thing to begin with wrt jitter checking, and that we ought to really be checking the local jitter and not the jitter of remote systems to begin with, or something like that. i'm going from some hazy memory here, but i think ultimately the problem is that there are two use cases for check_ntp, but the code has in the past and still currently not differentiated between the two cases. first you have the case of checking the status of the local system, by connecting to peers specified on the cmdline and verifying the offset. in such cases we really want to see the local jitter and not the remote jitter. the second case is when you're actually interested in the status of the remote system, and in this case you're comparing the state of its clock with that of yours (or others), and in which case you're interested in the jitter on the remote system. if i'm remembering all of this correctly, i think it would be best to provide a flag for which form of check we're doing and then have the plugin behave appropriately based on that. > 5. Look into the possibility of storing some of the sent header in a > linked list on write and then match them on reads. That will allow to > send all packets as fast as possible (ex. when checking the jitter of > all sync candidates) and also to easily drop odd packets. If put in a > separate routine that would also allow to easily loop for additional > packets and append the data. (Any other suggestion?) i'm not quite sure i follow here. how this is different from poll on an array of sockets...? currently afaik the data *is* sent as fast as possible, and we read the data as fast as it comes in. if we need more per-host information, we know ahead of time how many hosts/sockets/etc that are needed, so i don't think there's any need for a linked list instead of a pre-allocated array for whatever extra data we need to track. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From dermoth at aei.ca Thu Apr 5 00:05:40 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Wed, 04 Apr 2007 18:05:40 -0400 Subject: [Nagiosplug-devel] check_ntp (Was: Flight 1.4.8, ready for boarding) In-Reply-To: <1175717021.5377.29.camel@localhost> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> <804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com> <20070331185328.GB44795887@CIS.FU-Berlin.DE> <20070402025010.GA49868894@CIS.FU-Berlin.DE> <46109158.3090502@aei.ca> <461097FE.6090203@aei.ca> <20070402124552.GB49868894@CIS.FU-Berlin.DE> <46110283.7020208@aei.ca> <1175551737.5284.48.camel@localhost> <461199F3.2000506@aei.ca> <4611BAA5.8080009@aei.ca> <1175581779.30348.10.camel@localhost> <4613E276.5080507@aei.ca> <1175717021.5377.29.camel@localhost> Message-ID: <46142134.9030408@aei.ca> On 04/04/07 04:03 PM, sean finney wrote: > hey thomas, > > On Wed, 2007-04-04 at 13:37 -0400, Thomas Guyot-Sionnest wrote: >> The problem with xntpd it that it doesn't have a jitter value (ntp v3). >> I'll work up a patch a bit different than what I sent but basically >> it'll do the same: take dispersion in place for jitter. > > okay. i *think* that's the same thing with just a different name, > right? Not really. I don't know what's taken into account when calculating the jitter but the dispersion is definately higher in general (or always?) ntpq> lass ind assID status conf reach auth condition last_event cnt =========================================================== [...] 3 63998 97f4 yes yes none pps.peer reachable 15 [...] ntpq> rv 63998 jitter,dispersion assID=63998 status=97f4 reach, conf, sel_pps.peer, 15 events, event_reach, jitter=0.002, dispersion=0.926 >> While we were working on this check, me and Holger raised up a few >> issues. I worked up a todo list and I'd like to share it with you. Only >> the older ntp client support would go in before the 1.4.8 release. >> >> 1. Older ntp server support (I'm working on it) >> >> 2. The offset and jitter doesn't change on every call, so there's no >> reason to poll 4 times and compute the average. I'd like to remove all >> code related to that. > > one of the design goals when i first wrote the plugin was to mimick as > closely as possible the behaviour of the previous perl-based check_ntp > plugin. after analyzing the plugin plus the source for ntp plus packet > dumping what the ntp cmdline programs did, this was the behaviour i > found. that doesn't necessarily mean that various behaviours are the > ideal behaviour, but just so you know where it came from :) > > but anyway, as far sampling/averaging goes, the offset/delay can vary a > bit more if the network is less than reliable iirc, hence the multiple > requests. this is what the ntp cmdline client does as well. What's you're pooling in the jitter section is local variables on the remote server. That server will update them as time goes, but they'Re not affected by network conditions. >> 3. Allow to use -H multiple times > > seems reasonable, though i'd probably have a seperate nagios check for > each host. see comments below for (4) though. > >> 3a. Do one lookup for the servers and store an array of IPs for the >> various functions. (Is it worth it? Will avoid code duplcation >> implementing #4) > > isn't that what's already done with the getaddrinfo(), and > array-of-sockets allocation? The hostname is resolved again in the jitter section. Anyway that's not a big deal, would only be useful for implementing #4. >> 4. When multiple servers are specified (either multiple IP per hostname >> or multiple -H aguments, check the jitter for all servers. > > i think this falls back into the mimicking-behaviour design again. > previously i believe we only checked the jitter on the remote clock > declared as the sync source, but i could be wrong. i don't really think > this is the *right* behaviour, but before i went fixing it the idea was > to get something that was compatible with the current versoin. Right now it gets the first server listed in dns (while the offset function gets them all) and find the synchronization source. It then check the sync source; if there is none it will check all candidates. > actually, istr someone pointing out several months ago that we were > really doing the wrong thing to begin with wrt jitter checking, and that > we ought to really be checking the local jitter and not the jitter of > remote systems to begin with, or something like that. i'm going from > some hazy memory here, but i think ultimately the problem is that there > are two use cases for check_ntp, but the code has in the past and still > currently not differentiated between the two cases. The server jitter somewhat related to its peers's jitter so that's not a big deal. Moreover, Older ntp server does not have dispersion for the server itself so it makes supporting them even worse. > first you have the case of checking the status of the local system, by > connecting to peers specified on the cmdline and verifying the offset. > in such cases we really want to see the local jitter and not the remote > jitter. Can you explain? I remember the old perl script user to show a 0/almost 0 jitter on localhost, but that's devinately not what we get when getting the server jitter. It looks more like it was getting the time and then showing the jitter in that operation. > the second case is when you're actually interested in the status of the > remote system, and in this case you're comparing the state of its clock > with that of yours (or others), and in which case you're interested in > the jitter on the remote system. This is what check_ntp currently do and should be the default behavior IMHO. > if i'm remembering all of this correctly, i think it would be best to > provide a flag for which form of check we're doing and then have the > plugin behave appropriately based on that. Agreed. But for testing the first case we should only accept to run it locally (ex. trough NRPE on a remote time server) otherwise it doesn't make much sense. >> 5. Look into the possibility of storing some of the sent header in a >> linked list on write and then match them on reads. That will allow to >> send all packets as fast as possible (ex. when checking the jitter of >> all sync candidates) and also to easily drop odd packets. If put in a >> separate routine that would also allow to easily loop for additional >> packets and append the data. (Any other suggestion?) > > i'm not quite sure i follow here. how this is different from poll on an > array of sockets...? currently afaik the data *is* sent as fast as > possible, and we read the data as fast as it comes in. if we need more > per-host information, we know ahead of time how many hosts/sockets/etc > that are needed, so i don't think there's any need for a linked list > instead of a pre-allocated array for whatever extra data we need to > track. This has nothing to do with the array of sockets, but rather making sure what we get back is what we expect. This is of the lowest priority but should speed up a bit some sequential operations when there is latency (like checking jitter on all candidates). Thomas From seanius at seanius.net Thu Apr 5 09:08:28 2007 From: seanius at seanius.net (sean finney) Date: Thu, 05 Apr 2007 09:08:28 +0200 Subject: [Nagiosplug-devel] check_ntp (Was: Flight 1.4.8, ready for boarding) In-Reply-To: <46142134.9030408@aei.ca> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> <804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com> <20070331185328.GB44795887@CIS.FU-Berlin.DE> <20070402025010.GA49868894@CIS.FU-Berlin.DE> <46109158.3090502@aei.ca> <461097FE.6090203@aei.ca> <20070402124552.GB49868894@CIS.FU-Berlin.DE> <46110283.7020208@aei.ca> <1175551737.5284.48.camel@localhost> <461199F3.2000506@aei.ca> <4611BAA5.8080009@aei.ca> <1175581779.30348.10.camel@localhost> <4613E276.5080507@aei.ca> <1175717021.5377.29.camel@localhost> <46142134.9030408@aei.ca> Message-ID: <1175756908.1955.35.camel@localhost> heya, On Wed, 2007-04-04 at 18:05 -0400, Thomas Guyot-Sionnest wrote: > > okay. i *think* that's the same thing with just a different name, > > right? > > Not really. I don't know what's taken into account when calculating the > jitter but the dispersion is definately higher in general (or always?) okay, here are some definitions i got from an ntp powerpoint presentation made by the author: Jitter: exponential average of first-order time differences Dispersion: maximum error due oscillator frequency tolerance. so yeah, not quite the same thing. and as you pointed out the differences in value are quite big. should we really be checking it with jitter then? maybe instead we could extend the plugin to check various variables/thresholds, and have it return some failure status when a non-existant variable is requested? > > but anyway, as far sampling/averaging goes, the offset/delay can vary a > > bit more if the network is less than reliable iirc, hence the multiple > > requests. this is what the ntp cmdline client does as well. > > What's you're pooling in the jitter section is local variables on the > remote server. That server will update them as time goes, but they'Re > not affected by network conditions. ah, i see. so the control packet data probably won't change in the interval that it's being checked. in that case it doesn't make any sense to average it, i agree. however, since this is udp we're talking about, maybe it's still worthwhile to throw a couple extra packets on the wire to make sure one of them is recieved? or perhaps we could default to a single packet, but provide a configurable retry parameter or something. > The hostname is resolved again in the jitter section. Anyway that's not > a big deal, would only be useful for implementing #4. oh, i was looking in the offset_request function there, sorry. > >> 4. When multiple servers are specified (either multiple IP per hostname > >> or multiple -H aguments, check the jitter for all servers. > > > > i think this falls back into the mimicking-behaviour design again. > > previously i believe we only checked the jitter on the remote clock > > declared as the sync source, but i could be wrong. i don't really think > > this is the *right* behaviour, but before i went fixing it the idea was > > to get something that was compatible with the current versoin. > > Right now it gets the first server listed in dns (while the offset > function gets them all) and find the synchronization source. It then > check the sync source; if there is none it will check all candidates. right. again to be filed under "behaves as before" wrt check_ntp and ntpq/ntpdate. > > actually, istr someone pointing out several months ago that we were > > really doing the wrong thing to begin with wrt jitter checking, and that > > we ought to really be checking the local jitter and not the jitter of > > remote systems to begin with, or something like that. i'm going from > > some hazy memory here, but i think ultimately the problem is that there > > are two use cases for check_ntp, but the code has in the past and still > > currently not differentiated between the two cases. > > The server jitter somewhat related to its peers's jitter so that's not a > big deal. Moreover, Older ntp server does not have dispersion for the > server itself so it makes supporting them even worse. out of curiosity, is there any difference on the packet level that could let us know the version/vendor of the ntp server? > > first you have the case of checking the status of the local system, by > > connecting to peers specified on the cmdline and verifying the offset. > > in such cases we really want to see the local jitter and not the remote > > jitter. > > Can you explain? I remember the old perl script user to show a 0/almost > 0 jitter on localhost, but that's devinately not what we get when > getting the server jitter. It looks more like it was getting the time > and then showing the jitter in that operation. my memory is hazy, but i'll go digging through the list archives and see if i can find the message i'm thinking of. > > the second case is when you're actually interested in the status of the > > remote system, and in this case you're comparing the state of its clock > > with that of yours (or others), and in which case you're interested in > > the jitter on the remote system. > > This is what check_ntp currently do and should be the default behavior IMHO. so for clarity: with check_ntp -H host, should the jitter on the host be calculated, or the jitter of its sync source / candidate sync sources be checked? > > if i'm remembering all of this correctly, i think it would be best to > > provide a flag for which form of check we're doing and then have the > > plugin behave appropriately based on that. > > Agreed. But for testing the first case we should only accept to run it > locally (ex. trough NRPE on a remote time server) otherwise it doesn't > make much sense. agreed on both these. > >> 5. Look into the possibility of storing some of the sent header in a > >> linked list on write and then match them on reads. That will allow to > >> send all packets as fast as possible (ex. when checking the jitter of > >> all sync candidates) and also to easily drop odd packets. If put in a > >> separate routine that would also allow to easily loop for additional > >> packets and append the data. (Any other suggestion?) > > > > i'm not quite sure i follow here. how this is different from poll on an > > array of sockets...? currently afaik the data *is* sent as fast as > > possible, and we read the data as fast as it comes in. if we need more > > per-host information, we know ahead of time how many hosts/sockets/etc > > that are needed, so i don't think there's any need for a linked list > > instead of a pre-allocated array for whatever extra data we need to > > track. > > This has nothing to do with the array of sockets, but rather making sure > what we get back is what we expect. This is of the lowest priority but > should speed up a bit some sequential operations when there is latency > (like checking jitter on all candidates). i think i was looking at the offset_request function again, oops. anyway, probably the same method could still be used, though the setup might be a little more complicated if the total size results from a few different gettaddrinfo calls. is that what you were thinking of using the linked list for? i.e. the setup and not the actual i/o? sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From dermoth at aei.ca Thu Apr 5 15:29:28 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Thu, 05 Apr 2007 09:29:28 -0400 Subject: [Nagiosplug-devel] check_ntp (Was: Flight 1.4.8, ready for boarding) In-Reply-To: <1175756908.1955.35.camel@localhost> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> <804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com> <20070331185328.GB44795887@CIS.FU-Berlin.DE> <20070402025010.GA49868894@CIS.FU-Berlin.DE> <46109158.3090502@aei.ca> <461097FE.6090203@aei.ca> <20070402124552.GB49868894@CIS.FU-Berlin.DE> <46110283.7020208@aei.ca> <1175551737.5284.48.camel@localhost> <461199F3.2000506@aei.ca> <4611BAA5.8080009@aei.ca> <1175581779.30348.10.camel@localhost> <4613E276.5080507@aei.ca> <1175717021.5377.29.camel@localhost> <46142134.9030408@aei.ca> <1175756908.1955.35.camel@localhost> Message-ID: <4614F9B8.8030500@aei.ca> On 05/04/07 03:08 AM, sean finney wrote: > heya, > > On Wed, 2007-04-04 at 18:05 -0400, Thomas Guyot-Sionnest wrote: >> Not really. I don't know what's taken into account when calculating the >> jitter but the dispersion is definately higher in general (or always?) > > okay, here are some definitions i got from an ntp powerpoint > presentation made by the author: > > Jitter: exponential average of first-order time differences > Dispersion: maximum error due oscillator frequency tolerance. > > so yeah, not quite the same thing. and as you pointed out the > differences in value are quite big. should we really be checking it > with jitter then? maybe instead we could extend the plugin to check > various variables/thresholds, and have it return some failure status > when a non-existant variable is requested? That could begin to confuse users that don't know much about NTP. Aspecially since "ntpq -p " will return the dispersion if there is no jitter. I'd suggest the same behavior for check_ntp. >> What's you're pooling in the jitter section is local variables on the >> remote server. That server will update them as time goes, but they'Re >> not affected by network conditions. > > ah, i see. so the control packet data probably won't change in the > interval that it's being checked. in that case it doesn't make any > sense to average it, i agree. however, since this is udp we're talking > about, maybe it's still worthwhile to throw a couple extra packets on > the wire to make sure one of them is recieved? or perhaps we could > default to a single packet, but provide a configurable retry parameter > or something. I'll take a look at what the other check used to do... But I doubt it would be useful for the jitter section. >> Right now it gets the first server listed in dns (while the offset >> function gets them all) and find the synchronization source. It then >> check the sync source; if there is none it will check all candidates. > > right. again to be filed under "behaves as before" wrt check_ntp and > ntpq/ntpdate. So you're ok to check jitter on all servers? >>> actually, istr someone pointing out several months ago that we were >>> really doing the wrong thing to begin with wrt jitter checking, and that >>> we ought to really be checking the local jitter and not the jitter of >>> remote systems to begin with, or something like that. i'm going from >>> some hazy memory here, but i think ultimately the problem is that there >>> are two use cases for check_ntp, but the code has in the past and still >>> currently not differentiated between the two cases. >> The server jitter somewhat related to its peers's jitter so that's not a >> big deal. Moreover, Older ntp server does not have dispersion for the >> server itself so it makes supporting them even worse. > > out of curiosity, is there any difference on the packet level that could > let us know the version/vendor of the ntp server? Yes, but I felt is was much safer to just try with jitter, then try dispersion if jitter doesn't work. There's many different version/forks of net daemons out there and it would be really difficult to behave correctly on all of them. >>> first you have the case of checking the status of the local system, by >>> connecting to peers specified on the cmdline and verifying the offset. >>> in such cases we really want to see the local jitter and not the remote >>> jitter. >> Can you explain? I remember the old perl script user to show a 0/almost >> 0 jitter on localhost, but that's devinately not what we get when >> getting the server jitter. It looks more like it was getting the time >> and then showing the jitter in that operation. > > my memory is hazy, but i'll go digging through the list archives and see > if i can find the message i'm thinking of. > >>> the second case is when you're actually interested in the status of the >>> remote system, and in this case you're comparing the state of its clock >>> with that of yours (or others), and in which case you're interested in >>> the jitter on the remote system. >> This is what check_ntp currently do and should be the default behavior IMHO. > > so for clarity: with check_ntp -H host, should the jitter on the host be > calculated, or the jitter of its sync source / candidate sync sources be > checked? You mean: check_ntp -H host -j x -k y As without -j or -k jitter is not calculated. Checking the host jitter or its sync source(s) is pretty much the same (ex if you have one peer both values are equal). The more I think about it the more I believe there should be no other way. The NTP server itself is the best place to look for time health. We could however add more checks, like reachability... >>> if i'm remembering all of this correctly, i think it would be best to >>> provide a flag for which form of check we're doing and then have the >>> plugin behave appropriately based on that. >> Agreed. But for testing the first case we should only accept to run it >> locally (ex. trough NRPE on a remote time server) otherwise it doesn't >> make much sense. > > agreed on both these. > >>>> 5. Look into the possibility of storing some of the sent header in a >>>> linked list on write and then match them on reads. That will allow to >>>> send all packets as fast as possible (ex. when checking the jitter of >>>> all sync candidates) and also to easily drop odd packets. If put in a >>>> separate routine that would also allow to easily loop for additional >>>> packets and append the data. (Any other suggestion?) >>> i'm not quite sure i follow here. how this is different from poll on an >>> array of sockets...? currently afaik the data *is* sent as fast as >>> possible, and we read the data as fast as it comes in. if we need more >>> per-host information, we know ahead of time how many hosts/sockets/etc >>> that are needed, so i don't think there's any need for a linked list >>> instead of a pre-allocated array for whatever extra data we need to >>> track. >> This has nothing to do with the array of sockets, but rather making sure >> what we get back is what we expect. This is of the lowest priority but >> should speed up a bit some sequential operations when there is latency >> (like checking jitter on all candidates). > > i think i was looking at the offset_request function again, oops. > anyway, probably the same method could still be used, though the setup > might be a little more complicated if the total size results from a few > different gettaddrinfo calls. is that what you were thinking of using > the linked list for? i.e. the setup and not the actual i/o? I was thinking of resolving the address once and putting them in an array. The linked list would contain some of the header fields on sent packets so that when we get a packet back we can match it. This is longer-term though so we'll see later. Thomas From holger at CIS.FU-Berlin.DE Thu Apr 5 17:36:49 2007 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Thu, 5 Apr 2007 17:36:49 +0200 Subject: [Nagiosplug-devel] check_ntp In-Reply-To: <4614F9B8.8030500@aei.ca> References: <46110283.7020208@aei.ca> <1175551737.5284.48.camel@localhost> <461199F3.2000506@aei.ca> <4611BAA5.8080009@aei.ca> <1175581779.30348.10.camel@localhost> <4613E276.5080507@aei.ca> <1175717021.5377.29.camel@localhost> <46142134.9030408@aei.ca> <1175756908.1955.35.camel@localhost> <4614F9B8.8030500@aei.ca> Message-ID: <20070405153648.GH49868894@CIS.FU-Berlin.DE> * Thomas Guyot-Sionnest [2007-04-05 09:29]: > On 05/04/07 03:08 AM, sean finney wrote: > > On Wed, 2007-04-04 at 18:05 -0400, Thomas Guyot-Sionnest wrote: > >> Not really. I don't know what's taken into account when calculating the > >> jitter but the dispersion is definately higher in general (or always?) > > > > okay, here are some definitions i got from an ntp powerpoint > > presentation made by the author: > > > > Jitter: exponential average of first-order time differences > > Dispersion: maximum error due oscillator frequency tolerance. > > > > so yeah, not quite the same thing. and as you pointed out the > > differences in value are quite big. should we really be checking it > > with jitter then? maybe instead we could extend the plugin to check > > various variables/thresholds, and have it return some failure status > > when a non-existant variable is requested? > > That could begin to confuse users that don't know much about NTP. > Aspecially since "ntpq -p " will return the dispersion if there is > no jitter. I'd suggest the same behavior for check_ntp. I agree, precisely for this reason. > >> What's you're pooling in the jitter section is local variables on the > >> remote server. That server will update them as time goes, but they'Re > >> not affected by network conditions. > > > > ah, i see. so the control packet data probably won't change in the > > interval that it's being checked. in that case it doesn't make any > > sense to average it, i agree. however, since this is udp we're talking > > about, maybe it's still worthwhile to throw a couple extra packets on > > the wire to make sure one of them is recieved? or perhaps we could > > default to a single packet, but provide a configurable retry parameter > > or something. > > I'll take a look at what the other check used to do... But I doubt it > would be useful for the jitter section. Why not? Retries are a good idea IMO. Holger -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE From Thomas at zango.com Thu Apr 5 18:19:52 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Thu, 5 Apr 2007 09:19:52 -0700 Subject: [Nagiosplug-devel] check_ntp In-Reply-To: <20070405153648.GH49868894@CIS.FU-Berlin.DE> References: <46110283.7020208@aei.ca> <1175551737.5284.48.camel@localhost><461199F3.2000506@aei.ca> <4611BAA5.8080009@aei.ca><1175581779.30348.10.camel@localhost> <4613E276.5080507@aei.ca><1175717021.5377.29.camel@localhost> <46142134.9030408@aei.ca><1175756908.1955.35.camel@localhost> <4614F9B8.8030500@aei.ca> <20070405153648.GH49868894@CIS.FU-Berlin.DE> Message-ID: <804160344192334BB21922E8082EA6C074ED0E@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net > [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On > Behalf Of Holger Weiss > Sent: April 5, 2007 11:37 > To: Nagios Plugins Development > Subject: Re: [Nagiosplug-devel] check_ntp > > * Thomas Guyot-Sionnest [2007-04-05 09:29]: > > On 05/04/07 03:08 AM, sean finney wrote: > > > ah, i see. so the control packet data probably won't > change in the > > > interval that it's being checked. in that case it > doesn't make any > > > sense to average it, i agree. however, since this is udp > we're talking > > > about, maybe it's still worthwhile to throw a couple > extra packets on > > > the wire to make sure one of them is recieved? or > perhaps we could > > > default to a single packet, but provide a configurable > retry parameter > > > or something. > > > > I'll take a look at what the other check used to do... But > I doubt it > > would be useful for the jitter section. > > Why not? Retries are a good idea IMO. I haven't really tested it but with the current code I expect any packet drop will cause the plugin to timeout. That's not really what I call retries. So unless you have a suggestion on how to timeout on undeceived packets (ex. Storing the time on the linked list (or whatever else) of #5 and somehow stop listening after some timeout, obviously < than the main timeout) that could work, otherwise I'll hold my position on this. Hey, is Ton aware that we're onboard for 1.4.8? Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From holger at CIS.FU-Berlin.DE Thu Apr 5 18:42:08 2007 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Thu, 5 Apr 2007 18:42:08 +0200 Subject: [Nagiosplug-devel] check_ntp In-Reply-To: <804160344192334BB21922E8082EA6C074ED0E@seaex01.180solutions.com> References: <46110283.7020208@aei.ca> <4614F9B8.8030500@aei.ca> <20070405153648.GH49868894@CIS.FU-Berlin.DE> <804160344192334BB21922E8082EA6C074ED0E@seaex01.180solutions.com> Message-ID: <20070405164208.GI49868894@CIS.FU-Berlin.DE> * Thomas Guyot-Sionnest [2007-04-05 09:19]: > > * Thomas Guyot-Sionnest [2007-04-05 09:29]: > > > On 05/04/07 03:08 AM, sean finney wrote: > > > > the wire to make sure one of them is recieved? or perhaps we could > > > > default to a single packet, but provide a configurable retry > > > > parameter or something. > > > > > > I'll take a look at what the other check used to do... But I doubt it > > > would be useful for the jitter section. > > > > Why not? Retries are a good idea IMO. > > I haven't really tested it but with the current code I expect any packet > drop will cause the plugin to timeout. That's not really what I call > retries. So unless you have a suggestion on how to timeout on undeceived > packets Use a non-blocking socket and resend the request if reading the reply (that is, poll(2) or select(2)) times out. It's far from being a critical feature though, especially since Nagios knows "soft states". Holger -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE From seanius at seanius.net Thu Apr 5 19:09:14 2007 From: seanius at seanius.net (sean finney) Date: Thu, 05 Apr 2007 19:09:14 +0200 Subject: [Nagiosplug-devel] check_ntp (Was: Flight 1.4.8, ready for boarding) In-Reply-To: <4614F9B8.8030500@aei.ca> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> <804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com> <20070331185328.GB44795887@CIS.FU-Berlin.DE> <20070402025010.GA49868894@CIS.FU-Berlin.DE> <46109158.3090502@aei.ca> <461097FE.6090203@aei.ca> <20070402124552.GB49868894@CIS.FU-Berlin.DE> <46110283.7020208@aei.ca> <1175551737.5284.48.camel@localhost> <461199F3.2000506@aei.ca> <4611BAA5.8080009@aei.ca> <1175581779.30348.10.camel@localhost> <4613E276.5080507@aei.ca> <1175717021.5377.29.camel@localhost> <46142134.9030408@aei.ca> <1175756908.1955.35.camel@localhost> <4614F9B8.8030500@aei.ca> Message-ID: <1175792954.17521.7.camel@localhost> On Thu, 2007-04-05 at 09:29 -0400, Thomas Guyot-Sionnest wrote: > >> Right now it gets the first server listed in dns (while the offset > >> function gets them all) and find the synchronization source. It then > >> check the sync source; if there is none it will check all candidates. > > > > right. again to be filed under "behaves as before" wrt check_ntp and > > ntpq/ntpdate. > > So you're ok to check jitter on all servers? on all servers resolving from the record for the sync source, yes. > Yes, but I felt is was much safer to just try with jitter, then try > dispersion if jitter doesn't work. There's many different version/forks > of net daemons out there and it would be really difficult to behave > correctly on all of them. seems reasonable. but i wonder whether thresholds for checking jitter are practical for checking dispersion and vice versa. > > so for clarity: with check_ntp -H host, should the jitter on the host be > > calculated, or the jitter of its sync source / candidate sync sources be > > checked? > > You mean: check_ntp -H host -j x -k y > > As without -j or -k jitter is not calculated. > > Checking the host jitter or its sync source(s) is pretty much the same > (ex if you have one peer both values are equal). are they? i thought jitter had to do with the level of variance from the host clock to the time source, in which case it could be very host-dependent. > > i think i was looking at the offset_request function again, oops. > > anyway, probably the same method could still be used, though the setup > > might be a little more complicated if the total size results from a few > > different gettaddrinfo calls. is that what you were thinking of using > > the linked list for? i.e. the setup and not the actual i/o? > > I was thinking of resolving the address once and putting them in an > array. The linked list would contain some of the header fields on sent > packets so that when we get a packet back we can match it. This is > longer-term though so we'll see later. but i still don't see why you need to store the header packets for lookup purposes (esp in a linked list), when you already know implicitly where the packets are coming from (i.e. which socket you're reading from). sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From seanius at seanius.net Thu Apr 5 19:12:21 2007 From: seanius at seanius.net (sean finney) Date: Thu, 05 Apr 2007 19:12:21 +0200 Subject: [Nagiosplug-devel] check_ntp In-Reply-To: <804160344192334BB21922E8082EA6C074ED0E@seaex01.180solutions.com> References: <46110283.7020208@aei.ca> <1175551737.5284.48.camel@localhost> <461199F3.2000506@aei.ca> <4611BAA5.8080009@aei.ca> <1175581779.30348.10.camel@localhost> <4613E276.5080507@aei.ca> <1175717021.5377.29.camel@localhost> <46142134.9030408@aei.ca> <1175756908.1955.35.camel@localhost> <4614F9B8.8030500@aei.ca> <20070405153648.GH49868894@CIS.FU-Berlin.DE> <804160344192334BB21922E8082EA6C074ED0E@seaex01.180solutions.com> Message-ID: <1175793142.17521.11.camel@localhost> On Thu, 2007-04-05 at 09:19 -0700, Thomas Guyot-Sionnest wrote: > I haven't really tested it but with the current code I expect any packet > drop will cause the plugin to timeout. That's not really what I call > retries. So unless you have a suggestion on how to timeout on undeceived > packets (ex. Storing the time on the linked list (or whatever else) of #5 > and somehow stop listening after some timeout, obviously < than the main > timeout) that could work, otherwise I'll hold my position on this. i'm not sure about jitter, but for the offset calculation as long as at least one packet is recieved things are okay. it sends 4 requests and *tries* to read 4 replies, but if plugin_timeout/2 passes first it will stop and work with what it's recieved. so if the "best match" only responds with 2 packets, then the average will be calculated from that. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From holger at CIS.FU-Berlin.DE Thu Apr 5 19:20:05 2007 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Thu, 5 Apr 2007 19:20:05 +0200 Subject: [Nagiosplug-devel] check_ntp (Was: Flight 1.4.8, ready for boarding) In-Reply-To: <1175792954.17521.7.camel@localhost> References: <1175551737.5284.48.camel@localhost> <461199F3.2000506@aei.ca> <4611BAA5.8080009@aei.ca> <1175581779.30348.10.camel@localhost> <4613E276.5080507@aei.ca> <1175717021.5377.29.camel@localhost> <46142134.9030408@aei.ca> <1175756908.1955.35.camel@localhost> <4614F9B8.8030500@aei.ca> <1175792954.17521.7.camel@localhost> Message-ID: <20070405172005.GJ49868894@CIS.FU-Berlin.DE> * sean finney [2007-04-05 19:09]: > On Thu, 2007-04-05 at 09:29 -0400, Thomas Guyot-Sionnest wrote: > > Yes, but I felt is was much safer to just try with jitter, then try > > dispersion if jitter doesn't work. There's many different version/forks > > of net daemons out there and it would be really difficult to behave > > correctly on all of them. > > seems reasonable. but i wonder whether thresholds for checking jitter > are practical for checking dispersion and vice versa. Probably not. So, if a server which returns the dispersion but not the jitter is checked, users might have to specify higher thresholds. So what? Holger -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE From Thomas at zango.com Thu Apr 5 20:03:47 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Thu, 5 Apr 2007 11:03:47 -0700 Subject: [Nagiosplug-devel] check_ntp In-Reply-To: <1175793142.17521.11.camel@localhost> References: <46110283.7020208@aei.ca> <1175551737.5284.48.camel@localhost><461199F3.2000506@aei.ca> <4611BAA5.8080009@aei.ca><1175581779.30348.10.camel@localhost> <4613E276.5080507@aei.ca><1175717021.5377.29.camel@localhost> <46142134.9030408@aei.ca><1175756908.1955.35.camel@localhost> <4614F9B8.8030500@aei.ca><20070405153648.GH49868894@CIS.FU-Berlin.DE><804160344192334BB21922E8082EA6C074ED0E@seaex01.180solutions.com> <1175793142.17521.11.camel@localhost> Message-ID: <804160344192334BB21922E8082EA6C074EDA0@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net > [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On > Behalf Of sean finney > Sent: April 5, 2007 13:12 > To: Nagios Plugin Development Mailing List > Subject: Re: [Nagiosplug-devel] check_ntp > > On Thu, 2007-04-05 at 09:19 -0700, Thomas Guyot-Sionnest wrote: > > I haven't really tested it but with the current code I > expect any packet > > drop will cause the plugin to timeout. That's not really what I call > > retries. So unless you have a suggestion on how to timeout > on undeceived > > packets (ex. Storing the time on the linked list (or > whatever else) of #5 > > and somehow stop listening after some timeout, obviously < > than the main > > timeout) that could work, otherwise I'll hold my position on this. > > i'm not sure about jitter, but for the offset calculation as > long as at > least one packet is recieved things are okay. it sends 4 requests and > *tries* to read 4 replies, but if plugin_timeout/2 passes > first it will > stop and work with what it's recieved. so if the "best match" only > responds with 2 packets, then the average will be calculated > from that. Great. If we decide to do the same kind of multi-host check for the jitter we'll do it that way as well (or maybe integrate it to the check_offset function?). I also noticed that the plugin is not always clear as to shy a warning condition has occures so this could be worked out at the same time... Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From Thomas at zango.com Thu Apr 5 20:21:52 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Thu, 5 Apr 2007 11:21:52 -0700 Subject: [Nagiosplug-devel] check_ntp (Was: Flight 1.4.8, ready for boarding) In-Reply-To: <1175792954.17521.7.camel@localhost> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com><804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com><20070331185328.GB44795887@CIS.FU-Berlin.DE><20070402025010.GA49868894@CIS.FU-Berlin.DE> <46109158.3090502@aei.ca><461097FE.6090203@aei.ca> <20070402124552.GB49868894@CIS.FU-Berlin.DE><46110283.7020208@aei.ca> <1175551737.5284.48.camel@localhost><461199F3.2000506@aei.ca> <4611BAA5.8080009@aei.ca><1175581779.30348.10.camel@localhost> <4613E276.5080507@aei.ca><1175717021.5377.29.camel@localhost> <46142134.9030408@aei.ca><1175756908.1955.35.camel@localhost> <4614F9B8.8030500@aei.ca> <1175792954.17521.7.camel@localhost> Message-ID: <804160344192334BB21922E8082EA6C074EDBB@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net > [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On > Behalf Of sean finney > Sent: April 5, 2007 13:09 > To: Nagios Plugin Development Mailing List > Subject: Re: [Nagiosplug-devel] check_ntp (Was: Flight > 1.4.8,ready for boarding) > > On Thu, 2007-04-05 at 09:29 -0400, Thomas Guyot-Sionnest wrote: > > > so for clarity: with check_ntp -H host, should the jitter > on the host be > > > calculated, or the jitter of its sync source / candidate > sync sources be > > > checked? > > > > You mean: check_ntp -H host -j x -k y > > > > As without -j or -k jitter is not calculated. > > > > Checking the host jitter or its sync source(s) is pretty > much the same > > (ex if you have one peer both values are equal). > > are they? i thought jitter had to do with the level of variance from > the host clock to the time source, in which case it could be very > host-dependent. I'm talking about the host jitter (READVAR with assocID set to 0) and its only peer's jitter (READVAR with the only possible assocID) Not to be confounded with the jitter the Perl check_ntp used to get, which looked like the jitter between the monitoring station and the checked host over a round of ntp calls. I don't believe there's any practical use for that unless the monitoring host is using that server for synchronization, though it could use it's own server to check that (-h localhost). Maybe for those running ntpdate instead of an ntp daemon, though when you don't care that much about precision do you really care for jitter? > > I was thinking of resolving the address once and putting them in an > > array. The linked list would contain some of the header > fields on sent > > packets so that when we get a packet back we can match it. This is > > longer-term though so we'll see later. > > but i still don't see why you need to store the header packets for > lookup purposes (esp in a linked list), when you already know > implicitly > where the packets are coming from (i.e. which socket you're reading > from). UDP is not a connection-oriented protocol. It will take anything suposedly sent from the remote ip/port to the local ip/port and packet ordering is not guarenteed. What if earlier in the plugin you decided that some packet was not coming back, but some routing issues on the network made it come back a few seconds later? What about the bug where I have to leave the socket open in order to start on a new port, because It receive an odd packet in the jitter section. The linked-list solution would just silently discard odd packets. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From ton.voon at altinity.com Thu Apr 5 20:25:39 2007 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 5 Apr 2007 19:25:39 +0100 Subject: [Nagiosplug-devel] check_ntp In-Reply-To: <804160344192334BB21922E8082EA6C074ED0E@seaex01.180solutions.com> References: <46110283.7020208@aei.ca> <1175551737.5284.48.camel@localhost><461199F3.2000506@aei.ca> <4611BAA5.8080009@aei.ca><1175581779.30348.10.camel@localhost> <4613E276.5080507@aei.ca><1175717021.5377.29.camel@localhost> <46142134.9030408@aei.ca><1175756908.1955.35.camel@localhost> <4614F9B8.8030500@aei.ca> <20070405153648.GH49868894@CIS.FU-Berlin.DE> <804160344192334BB21922E8082EA6C074ED0E@seaex01.180solutions.com> Message-ID: <7AD0E07C-1AE4-42B5-91CD-E310E29DA779@altinity.com> On 5 Apr 2007, at 17:19, Thomas Guyot-Sionnest wrote: > Hey, is Ton aware that we're onboard for 1.4.8? I've stayed out of this conversation because you don't need my ramblings - you guys are doing a great job working out what's best. I'll hold off a 1.4.8 until you're all happy with check_ntp, unless you tell me otherwise. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From Thomas at zango.com Thu Apr 5 21:13:48 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Thu, 5 Apr 2007 12:13:48 -0700 Subject: [Nagiosplug-devel] check_ntp In-Reply-To: <7AD0E07C-1AE4-42B5-91CD-E310E29DA779@altinity.com> References: <46110283.7020208@aei.ca><1175551737.5284.48.camel@localhost><461199F3.2000506@aei.ca><4611BAA5.8080009@aei.ca><1175581779.30348.10.camel@localhost><4613E276.5080507@aei.ca><1175717021.5377.29.camel@localhost><46142134.9030408@aei.ca><1175756908.1955.35.camel@localhost><4614F9B8.8030500@aei.ca><20070405153648.GH49868894@CIS.FU-Berlin.DE><804160344192334BB21922E8082EA6C074ED0E@seaex01.180solutions.com> <7AD0E07C-1AE4-42B5-91CD-E310E29DA779@altinity.com> Message-ID: <804160344192334BB21922E8082EA6C074EE02@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net > [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On > Behalf Of Ton Voon > Sent: April 5, 2007 14:26 > To: Nagios Plugin Development Mailing List > Subject: Re: [Nagiosplug-devel] check_ntp > > > On 5 Apr 2007, at 17:19, Thomas Guyot-Sionnest wrote: > > > Hey, is Ton aware that we're onboard for 1.4.8? > > I've stayed out of this conversation because you don't need my > ramblings - you guys are doing a great job working out what's best. > > I'll hold off a 1.4.8 until you're all happy with check_ntp, unless > you tell me otherwise. All short-term work for check_ntp is done; lots of bug fixes and enhancements by various members of the team. I'd like to see 1.4.8 out ASAP so we'll have time to discuss, implement and test the proposed changes for the next release. While we're at it, I'm still holding off some changes I'd like to do with check_file_age. Basically I'd like that we agree on if and how Nagios-plugins Perl script should make use of Nagios::Plugin code. I sent a post some time ago, but basically I was wondering if we should install it system-wide if not already present or locally in @libdir@ (my preference). If installation is local I guess we should slightly change the name to avoid Perl complaining if it finds two libraries of the same name... Thanks, Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From ton.voon at altinity.com Thu Apr 5 21:44:16 2007 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 5 Apr 2007 20:44:16 +0100 Subject: [Nagiosplug-devel] check_ntp In-Reply-To: <804160344192334BB21922E8082EA6C074EE02@seaex01.180solutions.com> References: <46110283.7020208@aei.ca><1175551737.5284.48.camel@localhost><461199F3.2000506@aei.ca><4611BAA5.8080009@aei.ca><1175581779.30348.10.camel@localhost><4613E276.5080507@aei.ca><1175717021.5377.29.camel@localhost><46142134.9030408@aei.ca><1175756908.1955.35.camel@localhost><4614F9B8.8030500@aei.ca><20070405153648.GH49868894@CIS.FU-Berlin.DE><804160344192334BB21922E8082EA6C074ED0E@seaex01.180solutions.com> <7AD0E07C-1AE4-42B5-91CD-E310E29DA779@altinity.com> <804160344192334BB21922E8082EA6C074EE02@seaex01.180solutions.com> Message-ID: On 5 Apr 2007, at 20:13, Thomas Guyot-Sionnest wrote: > All short-term work for check_ntp is done; lots of bug fixes and > enhancements > by various members of the team. Thanks for all the fixes to check_ntp. > I'd like to see 1.4.8 out ASAP so we'll have time to discuss, > implement and > test the proposed changes for the next release. OK. I will cut 1.4.8 on Tuesday (as it is a long weekend as of now!). > While we're at it, I'm still holding off some changes I'd like to > do with > check_file_age. Basically I'd like that we agree on if and how > Nagios-plugins > Perl script should make use of Nagios::Plugin code. I sent a post > some time > ago, but basically I was wondering if we should install it system- > wide if not > already present or locally in @libdir@ (my preference). If > installation is > local I guess we should slightly change the name to avoid Perl > complaining if > it finds two libraries of the same name... Agreed - I think Nagios::Plugin is ready to be integrated in. I've been thinking about it, and I know Gavin has too. Let's discuss the ideas next week to get agreement on the best approach. I think integration of N::P is probably also worthy of calling the next release 1.5. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From ghenry at suretecsystems.com Thu Apr 5 21:52:22 2007 From: ghenry at suretecsystems.com (Gavin Henry) Date: Thu, 5 Apr 2007 20:52:22 +0100 (BST) Subject: [Nagiosplug-devel] Updating check_ldap.c Message-ID: <56440.192.168.100.90.1175802742.squirrel@webmail.suretecsystems.com> Hi list, Any thoughts on why I shouldn't update check_ldap.c to use non-deprecated libldap functions? Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ From seanius at seanius.net Thu Apr 5 22:10:55 2007 From: seanius at seanius.net (sean finney) Date: Thu, 05 Apr 2007 22:10:55 +0200 Subject: [Nagiosplug-devel] check_ntp (Was: Flight 1.4.8, ready for boarding) In-Reply-To: <804160344192334BB21922E8082EA6C074EDBB@seaex01.180solutions.com> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> <804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com> <20070331185328.GB44795887@CIS.FU-Berlin.DE> <20070402025010.GA49868894@CIS.FU-Berlin.DE> <46109158.3090502@aei.ca> <461097FE.6090203@aei.ca> <20070402124552.GB49868894@CIS.FU-Berlin.DE> <46110283.7020208@aei.ca> <1175551737.5284.48.camel@localhost> <461199F3.2000506@aei.ca> <4611BAA5.8080009@aei.ca> <1175581779.30348.10.camel@localhost> <4613E276.5080507@aei.ca> <1175717021.5377.29.camel@localhost> <46142134.9030408@aei.ca> <1175756908.1955.35.camel@localhost> <4614F9B8.8030500@aei.ca> <1175792954.17521.7.camel@localhost> <804160344192334BB21922E8082EA6C074EDBB@seaex01.180solutions.com> Message-ID: <1175803855.17521.35.camel@localhost> hi, On Thu, 2007-04-05 at 11:21 -0700, Thomas Guyot-Sionnest wrote: > > but i still don't see why you need to store the header packets for > > lookup purposes (esp in a linked list), when you already know > > implicitly > > where the packets are coming from (i.e. which socket you're reading > > from). > > UDP is not a connection-oriented protocol. It will take anything suposedly > sent from the remote ip/port to the local ip/port and packet ordering is not > guarenteed. What if earlier in the plugin you decided that some packet was > not coming back, but some routing issues on the network made it come back a if you only send offset requests through an fd, you only get offset responses through the fd. if you have a different fd for the readstat requests (via a new socket while the previous one was open, bind(), or maybe setsockopt) then you don't have to worry about the ordering, without the use of any extra data structures (besides an array or two). but maybe this is all moot... has anyone looked to see how hard it'd be to just determine the packet type from the contents? i.e. if you're waiting for readstat responses and a stale packet comes in, couldn't it just be discarded? for example, in the print_offset_request function i see something like: if(p->op&REM_RESP && p->op&OP_READSTAT){ so couldn't that check be used to filter out any possible stale packets? so like: DBG(printf("recieving READSTAT response")) read(conn, &req, SIZEOF_NTPCM(req)); DBG(print_ntp_control_message(&req)); + if(p->op&REM_RESP && p->op&OP_READSTAT) { /* Each peer identifier is 4 bytes in the data section, which * we represent as a ntp_assoc_status_pair datatype. */ ... + } or maybe something better in case the bits at the same spot in a offset message weren't predictable? sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From Thomas at zango.com Thu Apr 5 22:54:53 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Thu, 5 Apr 2007 13:54:53 -0700 Subject: [Nagiosplug-devel] check_ntp (Was: Flight 1.4.8, ready for boarding) In-Reply-To: <1175803855.17521.35.camel@localhost> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com><804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com><20070331185328.GB44795887@CIS.FU-Berlin.DE><20070402025010.GA49868894@CIS.FU-Berlin.DE> <46109158.3090502@aei.ca><461097FE.6090203@aei.ca> <20070402124552.GB49868894@CIS.FU-Berlin.DE><46110283.7020208@aei.ca> <1175551737.5284.48.camel@localhost><461199F3.2000506@aei.ca> <4611BAA5.8080009@aei.ca><1175581779.30348.10.camel@localhost> <4613E276.5080507@aei.ca><1175717021.5377.29.camel@localhost> <46142134.9030408@aei.ca><1175756908.1955.35.camel@localhost> <4614F9B8.8030500@aei.ca><1175792954.17521.7.camel@localhost><804160344192334BB21922E8082EA6C074EDBB@seaex01.180solutions.com> <1175803855.17521.35.camel@localhost> Message-ID: <804160344192334BB21922E8082EA6C074EE65@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net > [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On > Behalf Of sean finney > Sent: April 5, 2007 16:11 > To: Nagios Plugin Development Mailing List > Subject: Re: [Nagiosplug-devel] check_ntp (Was: Flight > 1.4.8,ready for boarding) > > hi, > > > > > UDP is not a connection-oriented protocol. It will take > anything suposedly > > sent from the remote ip/port to the local ip/port and > packet ordering is not > > guarenteed. What if earlier in the plugin you decided that > some packet was > > not coming back, but some routing issues on the network > made it come back a > > if you only send offset requests through an fd, you only get offset > responses through the fd. if you have a different fd for the readstat > requests (via a new socket while the previous one was open, bind(), or > maybe setsockopt) then you don't have to worry about the ordering, > without the use of any extra data structures (besides an array or > two). > > but maybe this is all moot... has anyone looked to see how > hard it'd be > to just determine the packet type from the contents? i.e. if you're > waiting for readstat responses and a stale packet comes in, > couldn't it > just be discarded? for example, in the print_offset_request > function i > see something like: > > if(p->op&REM_RESP && p->op&OP_READSTAT){ > > so couldn't that check be used to filter out any possible > stale packets? > > so like: > > DBG(printf("recieving READSTAT response")) > read(conn, &req, SIZEOF_NTPCM(req)); > DBG(print_ntp_control_message(&req)); > + if(p->op&REM_RESP && p->op&OP_READSTAT) { > /* Each peer identifier is 4 bytes in the > data section, > which > * we represent as a ntp_assoc_status_pair datatype. > */ > ... > + } > > or maybe something better in case the bits at the same spot > in a offset > message weren't predictable? I was rather thinking of adding ntp read and write functions that takes a pointer to the structure you want to send/receive and the linked list. On write it will send the packet then append a node to the linked list with some of the headers on success. On read it will remove the matching node from the list, drop the request if the packet is not matched, then check the error field. The return status could be used to induce various behavior (i.e. error, unmatched, nothing to read (empty list or packets too old)). Anyways let me first see how I'm gonna work it out to: 1) Allow multiple servers to be specified on the command line, and 2) make the jitter check run on every host found. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From seanius at seanius.net Fri Apr 6 00:14:25 2007 From: seanius at seanius.net (sean finney) Date: Fri, 06 Apr 2007 00:14:25 +0200 Subject: [Nagiosplug-devel] check_ntp (Was: Flight 1.4.8, ready for boarding) In-Reply-To: <804160344192334BB21922E8082EA6C074EE65@seaex01.180solutions.com> References: <42DF28BE-DBF5-4AC6-A77A-D7DA10FFD0DF@altinity.com> <804160344192334BB21922E8082EA6C07053FF@seaex01.180solutions.com> <20070331185328.GB44795887@CIS.FU-Berlin.DE> <20070402025010.GA49868894@CIS.FU-Berlin.DE> <46109158.3090502@aei.ca> <461097FE.6090203@aei.ca> <20070402124552.GB49868894@CIS.FU-Berlin.DE> <46110283.7020208@aei.ca> <1175551737.5284.48.camel@localhost> <461199F3.2000506@aei.ca> <4611BAA5.8080009@aei.ca> <1175581779.30348.10.camel@localhost> <4613E276.5080507@aei.ca> <1175717021.5377.29.camel@localhost> <46142134.9030408@aei.ca> <1175756908.1955.35.camel@localhost> <4614F9B8.8030500@aei.ca> <1175792954.17521.7.camel@localhost> <804160344192334BB21922E8082EA6C074EDBB@seaex01.180solutions.com> <1175803855.17521.35.camel@localhost> <804160344192334BB21922E8082EA6C074EE65@seaex01.180solutions.com> Message-ID: <1175811265.6709.36.camel@localhost> hi thomas, On Thu, 2007-04-05 at 13:54 -0700, Thomas Guyot-Sionnest wrote: > > I was rather thinking of adding ntp read and write functions that takes a > pointer to the structure you want to send/receive and the linked list. On > write it will send the packet then append a node to the linked list with > some of the headers on success. On read it will remove the matching node > from the list, drop the request if the packet is not matched, then check the > error field. The return status could be used to induce various behavior > (i.e. error, unmatched, nothing to read (empty list or packets too old)). i still say this is overengineering things though. why not just do what we're doing in the offset calculation again? if we know how to throw away stale packets then we don't even have the problem with needing to duplicate all the fd's, and we know O(n) instead of O(n^2) where a packet has come from (we already traverse all n fd's to find the ones with input waiting after a poll). i suppose we could set up a single socket and use some form of non-blocking send/recv* family of functions, but i don't think that it would fare much better and using poll() is much friendlier and more efficient than looping around nonblocking reads, and plus then we'd have to figure from the packet contents where it came from instead of just knowing by knowing which fd it came from. > Anyways let me first see how I'm gonna work it out to: 1) Allow multiple > servers to be specified on the command line, and 2) make the jitter check > run on every host found. i don't think either would be too hard, if we just generalized the code from offset_request(). i would hazard that it could be possible to: - build a list of supplied hostnames, and generalize the current resolution via getaddrinfo to work for a list of hostnames. - preallocate enough space for all the fd's - poll() the entire thing after firing off the offset packets. - know which sockets belonged to which host for calculating the sync sources - use the same set of fd's for jitter and just discard anything that arrives too late. or, filter it and put it back with the offset information, and defer the final offset calculation until the very end. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From dermoth at aei.ca Fri Apr 6 06:00:15 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Fri, 06 Apr 2007 00:00:15 -0400 Subject: [Nagiosplug-devel] check_ntp perf data in scientific notation... Message-ID: <4615C5CF.3040004@aei.ca> NTP WARNING: Offset -3.337860107e-06 secs|offset=-3.337860107e-06 jitter=-1.000000 AFAIK scientific notation is not valid for perfdata right?? If so I'll fix that before the next release. Thomas From noreply at sourceforge.net Mon Apr 9 22:57:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Apr 2007 13:57:45 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1497248 ] check_disk does not compile on Solaris 10 because of floorf Message-ID: Bugs item #1497248, was opened at 2006-05-29 19:45 Message generated for change (Comment added) made by ramereth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1497248&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: Release (specify) Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Daniel Austin (danaus) Assigned to: Ton Voon (tonvoon) Summary: check_disk does not compile on Solaris 10 because of floorf Initial Comment: Nagios Plugis: 1.4.3 Related to previous bug: 1374705 Compilation on Solaris 10 results in error when compiling check_disk.c: error: static declaration of 'floorf' follows non-static declaration On line 32 of check_disk.c common.h is imported. On line 196 of common.h we see: /* Solaris does not have floorf, but floor works. Should probably be in configure */ #if defined(__sun) || defined(__sun__) static inline float floorf (float x) { return floor(x); } #endif Solaris 10 actually *does* have floorf (but not earlier versions it seems). Workaround is to just comment out the line for now but, as original commenter said, prob best to replace this with configure test. Sorry -- lack the skill to do that at the moment, so no patch. :-( ---------------------------------------------------------------------- Comment By: Lance Albertson (ramereth) Date: 2007-04-09 15:57 Message: Logged In: YES user_id=696519 Originator: NO Looks like there's a reference to this in lib/utils_base.c. See output below: if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I../gl -I../intl -I../plugins -D_REENTRANT -g -O2 -MT utils_base.o -MD -MP -MF ".deps/utils_base.Tpo" -c -o utils_base.o utils_base.c; \ then mv -f ".deps/utils_base.Tpo" ".deps/utils_base.Po"; else rm -f ".deps/utils_base.Tpo"; exit 1; fi In file included from utils_base.c:16: ../plugins/common.h:179: error: static declaration of 'floorf' follows non-static declaration It appears as though floorf is defined on Solaris 10, but not prior to that. I tried building this package on Solaris 9 and didn't encounter this problem. It might be better to add a check in configure for this, but I'm no autoconf guru. :-) Thanks- ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2006-08-02 21: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: 2006-07-19 18:29 Message: Logged In: YES user_id=664364 Daniel, Can you please try the snapshot at http://nagiosplug.sf.net/snapshot. floorf has been removed from check_disk.c, so it should compile happily. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1497248&group_id=29880 From mark.eisenblaetter at gmail.com Tue Apr 10 15:46:14 2007 From: mark.eisenblaetter at gmail.com (Mark Eisenblaetter) Date: Tue, 10 Apr 2007 15:46:14 +0200 Subject: [Nagiosplug-devel] Feature Request: Check_cluster2 Message-ID: <288245630704100646l762868a3s63c8864f81ae5563@mail.gmail.com> Hi, I dont know if this is the right location, because the plugin is in the contrib section? In my case i need to test if only one check is ok? So its also Critical if 2 are running. But i found no way to test it. Or is this the wrong plugin to handle that problem? Mark -- Mark Eisenbl?tter Geissendoerfer & Leschinsky GmbH www.gl-sytemhaus.de From dermoth at aei.ca Tue Apr 10 21:18:48 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 10 Apr 2007 15:18:48 -0400 Subject: [Nagiosplug-devel] Feature Request: Check_cluster2 In-Reply-To: <288245630704100646l762868a3s63c8864f81ae5563@mail.gmail.com> References: <288245630704100646l762868a3s63c8864f81ae5563@mail.gmail.com> Message-ID: <461BE318.6040904@aei.ca> On 10/04/07 09:46 AM, Mark Eisenblaetter wrote: > Hi, > > I dont know if this is the right location, because the plugin is in > the contrib section? > > In my case i need to test if only one check is ok? So its also > Critical if 2 are running. But i found no way to test it. > > Or is this the wrong plugin to handle that problem? I'm not sure what you're trying there, and not even sure how this plugin was intented to be used... Could be of great use for Nagios3 because you can get the status codes of other host/services as macros, but how are you supposed to use it otherwise? Can you give more details please? Thomas From dermoth at aei.ca Tue Apr 10 21:41:35 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 10 Apr 2007 15:41:35 -0400 Subject: [Nagiosplug-devel] [Nagios-users] Problem with nagios-plugins-1.4.7 In-Reply-To: <20070410154836.9B30F4F4045@desire.netways.de> References: <20070410154836.9B30F4F4045@desire.netways.de> Message-ID: <461BE86F.6050103@aei.ca> On 10/04/07 11:48 AM, nmrk sharma wrote: > Hi all > > I am planing to install Latest nagios Plugins (nagios-plugins-1.4.7).When i given ./configure it is stoping at following location and not going forward.Can any one help me in this regard. > > checking for ping... /bin/ping > checking for ping6... /usr/sbin/ping6 > checking for ICMP ping syntax... Please reply to the Nagios Plugin Development Mailing List (nagiosplug-devel at lists.sourceforge.net). You may need to subscribe first. How long have you waited? What OS/distribution are you using? It happened in the past that some OS bugs caused the configure script to take insanely long time to execute, though I believe it was on some other checks. As last resort you may try: ./configure --without-ping-command --without-ping6-command But be aware that check_ping won't work (Shouldn't be compiled either but looks like there's a bug). You may use check_icmp as a replacement but you will have to set proper permissions for Nagios to be able use it. check_icmp is like check_ping but does the network stuff itself instead of calling "ping". The permissions for check_icmp should looks like this: mode 4750, owned by "root" with group "nagios". Thomas From adevey at omniture.com Wed Apr 11 02:05:07 2007 From: adevey at omniture.com (Aaron Devey) Date: Tue, 10 Apr 2007 18:05:07 -0600 Subject: [Nagiosplug-devel] nagios-plugins-1.4.7 mysql configure problem. Message-ID: <461C2633.1060605@omniture.com> I have been trying to get the configure script provided with nagios-plugins-1.4.7 to pick up my mysql installation, to no avail. nagios-plugins-1.4.6 has no problems picking it up. See output below: This command works with nagios-plugins-1.4.6: [nagios at nagios nagios-plugins-1.4.6]$ ./configure --prefix=/home/nagios --with-mysql=/usr/local/mysql 2>&1 | grep mysql --with-mysql: /usr/local/mysql/bin/mysql_config The same command does not work with nagios-plugins-1.4.7: [nagios at nagios nagios-plugins-1.4.7]$ ./configure --prefix=/home/nagios --with-mysql=/usr/local/mysql 2>&1 | grep mysql checking for mysql_init in -lmysqlclient... no --with-mysql: not found /usr/local/mysql/bin/mysql_config exists, and the current user has permission to read and execute it, as seen from the command below: [nagios at nagios nagios-plugins-1.4.7]$ /usr/local/mysql/bin/mysql_config Usage: /usr/local/mysql/bin/mysql_config [OPTIONS] Options: --cflags [-I'/usr/local/mysql/include/mysql'] --libs [-L'/usr/local/mysql/lib' -lmysqlclient -lz -lcrypt -lnsl -lm -Wl,--start-group -lc -lnss_files -lnss_dns -lresolv -Wl,--end-group] --socket [/tmp/mysql.sock] --port [3306] --version [3.23.51] Any suggestions? Thanks in advance, -Aaron Devey adevey at omniture.com (p.s. my apologies if I sent this to the wrong list. It seemed to be a development related issue.) From mark.eisenblaetter at gmail.com Wed Apr 11 09:58:45 2007 From: mark.eisenblaetter at gmail.com (Mark Eisenblaetter) Date: Wed, 11 Apr 2007 09:58:45 +0200 Subject: [Nagiosplug-devel] Feature Request: Check_cluster2 In-Reply-To: <461BE318.6040904@aei.ca> References: <288245630704100646l762868a3s63c8864f81ae5563@mail.gmail.com> <461BE318.6040904@aei.ca> Message-ID: <288245630704110058wabeb800pee4132e5f0690459@mail.gmail.com> Hi Thomas, sure, normaly i use check_cluster2 to monitor duplicates services. 2 are running ok, 1 are running warning and 0 running critical. in my new case i have the service (apache) schould be running only on one maschine at time. So I test on both maschines if the apache is running. So one service should be critical and on OK. And i thought check_cluster would handle that but it not. So i think it would be easyer to enhance check_cluster2 to test on special amount of oks as to write an new Plugin. Mark On 4/10/07, Thomas Guyot-Sionnest wrote: > On 10/04/07 09:46 AM, Mark Eisenblaetter wrote: > > Hi, > > > > I dont know if this is the right location, because the plugin is in > > the contrib section? > > > > In my case i need to test if only one check is ok? So its also > > Critical if 2 are running. But i found no way to test it. > > > > Or is this the wrong plugin to handle that problem? > > I'm not sure what you're trying there, and not even sure how this plugin > was intented to be used... Could be of great use for Nagios3 because you > can get the status codes of other host/services as macros, but how are > you supposed to use it otherwise? > > > Can you give more details please? > > Thomas > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > -- Mark Eisenbl?tter Geissendoerfer & Leschinsky GmbH www.gl-sytemhaus.de From ton.voon at altinity.com Wed Apr 11 10:02:35 2007 From: ton.voon at altinity.com (Ton Voon) Date: Wed, 11 Apr 2007 09:02:35 +0100 Subject: [Nagiosplug-devel] nagios-plugins-1.4.7 mysql configure problem. In-Reply-To: <461C2633.1060605@omniture.com> References: <461C2633.1060605@omniture.com> Message-ID: Aaron, On 11 Apr 2007, at 01:05, Aaron Devey wrote: > I have been trying to get the configure script provided with > nagios-plugins-1.4.7 to pick up my mysql installation, to no avail. > nagios-plugins-1.4.6 has no problems picking it up. See output below: > > This command works with nagios-plugins-1.4.6: > [nagios at nagios nagios-plugins-1.4.6]$ ./configure --prefix=/home/ > nagios > --with-mysql=/usr/local/mysql 2>&1 | grep mysql > --with-mysql: /usr/local/mysql/bin/mysql_config > > > The same command does not work with nagios-plugins-1.4.7: > [nagios at nagios nagios-plugins-1.4.7]$ ./configure --prefix=/home/ > nagios > --with-mysql=/usr/local/mysql 2>&1 | grep mysql > checking for mysql_init in -lmysqlclient... no > --with-mysql: not found > > > /usr/local/mysql/bin/mysql_config exists, and the current user has > permission to read and execute it, as seen from the command below: > [nagios at nagios nagios-plugins-1.4.7]$ /usr/local/mysql/bin/ > mysql_config > Usage: /usr/local/mysql/bin/mysql_config [OPTIONS] > Options: > --cflags [-I'/usr/local/mysql/include/mysql'] > --libs [-L'/usr/local/mysql/lib' -lmysqlclient -lz > -lcrypt -lnsl -lm -Wl,--start-group -lc -lnss_files -lnss_dns -lresolv > -Wl,--end-group] > --socket [/tmp/mysql.sock] > --port [3306] > --version [3.23.51] > Can you please try the snapshot at http://nagiosplug.sf.net/snapshot. I discovered 1.4.7 was too aggressive in its testing of mysql just after the release. We will be releasing 1.4.8 sometime today. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From matthias.eble at mailing.kaufland-informationssysteme.com Wed Apr 11 11:36:42 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Wed, 11 Apr 2007 11:36:42 +0200 Subject: [Nagiosplug-devel] Feature Request: Check_cluster2 In-Reply-To: <461BE318.6040904@aei.ca> References: <288245630704100646l762868a3s63c8864f81ae5563@mail.gmail.com> <461BE318.6040904@aei.ca> Message-ID: <461CAC2A.8030509@mailing.kaufland-informationssysteme.com> Hi Thomas, > I'm not sure what you're trying there, and not even sure how this plugin > was intented to be used... Could be of great use for Nagios3 because you > can get the status codes of other host/services as macros, but how are > you supposed to use it otherwise? status codes of other services are already available in Nagios 2.x They are called "On Demand Macros" in the docs. The problem with the OK States is caused by check_cluster2's lack of range thresholds (like eg check_procs has). Maybe he wants to alert on split brain scenarios when a service is up on multiple nodes.. Has anyone an idea why check_cluster2 is in contrib? To me it's quite a useful plugin for every nagios user. matthias From dermoth at aei.ca Thu Apr 12 07:14:36 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Thu, 12 Apr 2007 01:14:36 -0400 Subject: [Nagiosplug-devel] Feature Request: Check_cluster2 In-Reply-To: <461CAC2A.8030509@mailing.kaufland-informationssysteme.com> References: <288245630704100646l762868a3s63c8864f81ae5563@mail.gmail.com> <461BE318.6040904@aei.ca> <461CAC2A.8030509@mailing.kaufland-informationssysteme.com> Message-ID: <461DC03C.6010004@aei.ca> On 11/04/07 05:36 AM, Matthias Eble wrote: > Hi Thomas, > >> I'm not sure what you're trying there, and not even sure how this plugin >> was intented to be used... Could be of great use for Nagios3 because you >> can get the status codes of other host/services as macros, but how are >> you supposed to use it otherwise? > > status codes of other services are already available in Nagios 2.x They > are called "On Demand Macros" in the docs. > > > The problem with the OK States is caused by check_cluster2's lack of > range thresholds (like eg check_procs has). Maybe he wants to alert on > split brain scenarios when a service is up on multiple nodes.. I'm getting it now... It would be easy to add -W and -C that would: "Specifies the maximum number of hosts or services in cluster that can be in a OK state before returning a WARNING/CRITICAL status level". I'll do it only if we agree to include it in the main distribution. Shall we keep the name "check_cluster2"? I think the "2" may confuse new users, though renaming it to "check_cluster" would confuse old users. Damn ;) > Has anyone an idea why check_cluster2 is in contrib? To me it's quite a > useful plugin for every nagios user. Considering that it's simple, well written (authored by Ethan BTW) and very useful for clusters I'd vote for including it. Thomas From mark.eisenblaetter at gmail.com Thu Apr 12 10:49:32 2007 From: mark.eisenblaetter at gmail.com (Mark Eisenblaetter) Date: Thu, 12 Apr 2007 10:49:32 +0200 Subject: [Nagiosplug-devel] Feature Request: Check_cluster2 In-Reply-To: <461DC03C.6010004@aei.ca> References: <288245630704100646l762868a3s63c8864f81ae5563@mail.gmail.com> <461BE318.6040904@aei.ca> <461CAC2A.8030509@mailing.kaufland-informationssysteme.com> <461DC03C.6010004@aei.ca> Message-ID: <288245630704120149k311a362bj52eef88f93eba20a@mail.gmail.com> Hi, will it be possible to use both minimm and maximum at the same time? In my case it would be the same problem with minimum or maximum. So I would prefer the ranges like check_procs, to be able to alert both maximum and minimum? Mark. On 4/12/07, Thomas Guyot-Sionnest wrote: > On 11/04/07 05:36 AM, Matthias Eble wrote: > > Hi Thomas, > > > >> I'm not sure what you're trying there, and not even sure how this plugin > >> was intented to be used... Could be of great use for Nagios3 because you > >> can get the status codes of other host/services as macros, but how are > >> you supposed to use it otherwise? > > > > status codes of other services are already available in Nagios 2.x They > > are called "On Demand Macros" in the docs. > > > > > > The problem with the OK States is caused by check_cluster2's lack of > > range thresholds (like eg check_procs has). Maybe he wants to alert on > > split brain scenarios when a service is up on multiple nodes.. > > I'm getting it now... It would be easy to add -W and -C that would: > "Specifies the maximum number of hosts or services in cluster that can > be in a OK state before returning a WARNING/CRITICAL status level". > > I'll do it only if we agree to include it in the main distribution. > Shall we keep the name "check_cluster2"? I think the "2" may confuse new > users, though renaming it to "check_cluster" would confuse old users. > Damn ;) > > > Has anyone an idea why check_cluster2 is in contrib? To me it's quite a > > useful plugin for every nagios user. > > Considering that it's simple, well written (authored by Ethan BTW) and > very useful for clusters I'd vote for including it. > > > Thomas > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > -- Mark Eisenbl?tter Geissendoerfer & Leschinsky GmbH www.gl-sytemhaus.de From ton.voon at altinity.com Thu Apr 12 11:22:38 2007 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 12 Apr 2007 10:22:38 +0100 Subject: [Nagiosplug-devel] Feature Request: Check_cluster2 In-Reply-To: <461DC03C.6010004@aei.ca> References: <288245630704100646l762868a3s63c8864f81ae5563@mail.gmail.com> <461BE318.6040904@aei.ca> <461CAC2A.8030509@mailing.kaufland-informationssysteme.com> <461DC03C.6010004@aei.ca> Message-ID: <27947810-0B9A-431B-97FD-5FFB8FDB705C@altinity.com> On 12 Apr 2007, at 06:14, Thomas Guyot-Sionnest wrote: > On 11/04/07 05:36 AM, Matthias Eble wrote: >> Hi Thomas, >> >>> I'm not sure what you're trying there, and not even sure how this >>> plugin >>> was intented to be used... Could be of great use for Nagios3 >>> because you >>> can get the status codes of other host/services as macros, but >>> how are >>> you supposed to use it otherwise? >> >> status codes of other services are already available in Nagios 2.x >> They >> are called "On Demand Macros" in the docs. >> >> >> The problem with the OK States is caused by check_cluster2's lack of >> range thresholds (like eg check_procs has). Maybe he wants to >> alert on >> split brain scenarios when a service is up on multiple nodes.. > > I'm getting it now... It would be easy to add -W and -C that would: > "Specifies the maximum number of hosts or services in cluster that can > be in a OK state before returning a WARNING/CRITICAL status level". > > I'll do it only if we agree to include it in the main distribution. > Shall we keep the name "check_cluster2"? I think the "2" may > confuse new > users, though renaming it to "check_cluster" would confuse old users. > Damn ;) Yes, I agree that it should be in the main distribution. Thomas, Matthias, please co-ordinate between yourselves who'll add it in. I agree also that the name with a "2" is confusing. We can either go with - check_cluster, with a clear statement in NEWS that this works differently from the previous check_cluster in contrib - a new name (check_cluster_states ? check_states?) I would like some good tests for this plugin too, which should be fairly easy to do as there is no external "thing" that needs to return data. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From kuhlmeier at riege.com Thu Apr 12 12:37:10 2007 From: kuhlmeier at riege.com (Dennis Kuhlmeier) Date: Thu, 12 Apr 2007 12:37:10 +0200 Subject: [Nagiosplug-devel] check_ldap not built in 1.4.8 Message-ID: <461E0BD6.3080904@riege.com> Hello, just got the 1.4.8 sources and compiled them. For some reason, although everything looked fine, the check_ldap plugin was not built. Rechecked with 1.4.5 on the same machine and attached both config.log files. System: Red Hat Enterprise Linux WS release 4 (Nahant Update 4) Installed LDAP packages: openldap-2.2.13-6.4E openldap-clients-2.2.13-6.4E nss_ldap-226-17 openldap-devel-2.2.13-6.4E Thanks for any help! Dennis -- .............................................................. Riege Software International GmbH Fon: +49 (2159) 9148 0 Mollsfeld 10 Fax: +49 (2159) 9148 11 40670 Meerbusch Web: www.riege.com Germany E-Mail: kuhlmeier at riege.com --- --- Handelsregister: Managing Directors: Amtsgericht Neuss HRB-NR 4207 Johannes Riege & USt-ID-Nr.: DE120585842 Gabriele Riege .............................................................. YOU CARE FOR FREIGHT, WE CARE FOR YOU transport logistic - june 12-15, 2007 messe muenchen - hall c4, stand 429 -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log-1.4.5.gz Type: application/x-gzip Size: 27318 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log-1.4.8.gz Type: application/x-gzip Size: 33027 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kuhlmeier.vcf Type: text/x-vcard Size: 306 bytes Desc: not available URL: From kvdkumar at gmail.com Thu Apr 12 13:39:05 2007 From: kvdkumar at gmail.com (VamseeDeep) Date: Thu, 12 Apr 2007 17:09:05 +0530 Subject: [Nagiosplug-devel] How to run a shell script in nagios repeatedly Message-ID: <4d60c40e0704120439n6fac3675rb8837747df00cad@mail.gmail.com> Hi, I am interested in using nagios. My problem is : I would like to execute a shell script program in nagios repeatedly with some time period. I don't want to keep this script(what ever i required for execute) in /etc/crontab file.I would like to run a script with nagios only. I am using Nagios 2.6, plugins are 1.4.0. Please help me to solve this problem,Give detailed information on how to overcome this problem. Thanks, Deep. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dermoth at aei.ca Thu Apr 12 13:50:42 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Thu, 12 Apr 2007 07:50:42 -0400 Subject: [Nagiosplug-devel] Feature Request: Check_cluster2 In-Reply-To: <288245630704120149k311a362bj52eef88f93eba20a@mail.gmail.com> References: <288245630704100646l762868a3s63c8864f81ae5563@mail.gmail.com> <461BE318.6040904@aei.ca> <461CAC2A.8030509@mailing.kaufland-informationssysteme.com> <461DC03C.6010004@aei.ca> <288245630704120149k311a362bj52eef88f93eba20a@mail.gmail.com> Message-ID: <461E1D12.6020704@aei.ca> On 12/04/07 04:49 AM, Mark Eisenblaetter wrote: > Hi, > > will it be possible to use both minimm and maximum at the same time? > In my case it would be the same problem with minimum or maximum. > > So I would prefer the ranges like check_procs, to be able to alert > both maximum and minimum? You're right. The proper way to do it then will be to use the official threshold format: http://nagiosplug.sourceforge.net/developer-guidelines.html#THRESHOLDFORMAT Note however that this will slightly change the definition of a single number on the command line. In the current check it meant " >= x" while with the official threshold format it will mean " < 0 or > x". For example to alert as soon as one service is down you will need to use "0" instead of "1". Thomas From dermoth at aei.ca Thu Apr 12 14:34:48 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Thu, 12 Apr 2007 08:34:48 -0400 Subject: [Nagiosplug-devel] How to run a shell script in nagios repeatedly In-Reply-To: <4d60c40e0704120439n6fac3675rb8837747df00cad@mail.gmail.com> References: <4d60c40e0704120439n6fac3675rb8837747df00cad@mail.gmail.com> Message-ID: <461E2768.5050902@aei.ca> On 12/04/07 07:39 AM, VamseeDeep wrote: > Hi, > > I am interested in using nagios. > My problem is : > I would like to execute a shell script program in nagios repeatedly with > some time period. > I don't want to keep this script(what ever i required for execute) in > /etc/crontab file.I would like to run a script with nagios only. > > I am using Nagios 2.6, plugins are 1.4.0. > > Please help me to solve this problem,Give detailed information on how to > overcome this problem. This is fairly simple; you may want to look at the documentation for object syntax: http://nagios.sourceforge.net/docs/2_0/ First create a check command that contain the actual command-line and arguments. Then create an active service definition that use that check command, and set the check interval to the interval to what you want to run the script at. Please keep in mind however that Nagios does not guarantee your script will be run exactly at the defined interval. This can be especially true for huge setups if many hosts are down or if Nagios is misconfigured. I wouldn't use it as a crontab replacement. If you want the results of your crontabs in nagios I'd rather do passive monitoring with NSCA. Also note that anything run by Nagios is run as user nagios, so if your scripts needs root privileges you will need to use sudo. Thomas From lavalamp at spiritual-machines.org Thu Apr 12 15:42:11 2007 From: lavalamp at spiritual-machines.org (Brian A. Seklecki) Date: Thu, 12 Apr 2007 09:42:11 -0400 (EDT) Subject: [Nagiosplug-devel] How to run a shell script in nagios repeatedly In-Reply-To: <4d60c40e0704120439n6fac3675rb8837747df00cad@mail.gmail.com> References: <4d60c40e0704120439n6fac3675rb8837747df00cad@mail.gmail.com> Message-ID: <20070412093836.P76445@arbitor.digitalfreaks.org> It sounds like you need a tutorial on Nagios. I recommend any of the books on the market. You understand that nagios will only help you here (over cron) if your shell script returns variable return codes based on success? Check the Nagios plugin reference API. You can set up a check for localhost that runs a custom shell scipt command. check_freshnes=1 and is_volatile=1 for sure. normal check interval as low as you want. ~BAS On Thu, 12 Apr 2007, VamseeDeep wrote: > Hi, > > I am interested in using nagios. > My problem is : > I would like to execute a shell script program in nagios repeatedly with > some time period. > I don't want to keep this script(what ever i required for execute) in > /etc/crontab file.I would like to run a script with nagios only. > > I am using Nagios 2.6, plugins are 1.4.0. > > Please help me to solve this problem,Give detailed information on how to > overcome this problem. > > Thanks, > Deep. > l8* -lava (Brian A. Seklecki - Pittsburgh, PA, USA) http://www.spiritual-machines.org/ "...from back in the heady days when "helpdesk" meant nothing, "diskquota" meant everything, and lives could be bought and sold for a couple of pages of laser printout - and frequently were." -------------- next part -------------- ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -------------- next part -------------- _______________________________________________________ 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 matthias.eble at mailing.kaufland-informationssysteme.com Thu Apr 12 16:49:05 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Thu, 12 Apr 2007 16:49:05 +0200 Subject: [Nagiosplug-devel] Feature Request: Check_cluster2 In-Reply-To: <461E1D12.6020704@aei.ca> References: <288245630704100646l762868a3s63c8864f81ae5563@mail.gmail.com> <461BE318.6040904@aei.ca> <461CAC2A.8030509@mailing.kaufland-informationssysteme.com> <461DC03C.6010004@aei.ca> <288245630704120149k311a362bj52eef88f93eba20a@mail.gmail.com> <461E1D12.6020704@aei.ca> Message-ID: <461E46E1.5050400@mailing.kaufland-informationssysteme.com> Hi All, > Note however that this will slightly change the definition of a single > number on the command line. In the current check it meant " >= x" while > with the official threshold format it will mean " < 0 or > x". For > example to alert as soon as one service is down you will need to use "0" > instead of "1". I geuss there was a discussion about threshold format, a couple of weeks ago. I think the consens was, to include the unified format in a 2.0 release, is that right? So should we decide about the new range format first? I'd really like to implement it, if everybody is fine with it, but I'll go on vacation on Saturday and will likely be offline for two weeks. Maybe I can get it to work until tomorrow. I'll post a message if the time is not enough. So eg Thomas can do it in the meantime. Test cases should be, like Ton already said, no problem. The name should be changed, in my opinion, too. I like check_states. check_cluster is to special to me since the checked services/hosts only _might_ be part of a "Cluster". One more thing: Check_cluster is also mentioned in the nagios docs.. this should be considered when renaming. matthias From Thomas at zango.com Thu Apr 12 17:09:17 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Thu, 12 Apr 2007 08:09:17 -0700 Subject: [Nagiosplug-devel] Feature Request: Check_cluster2 In-Reply-To: <461E46E1.5050400@mailing.kaufland-informationssysteme.com> References: <288245630704100646l762868a3s63c8864f81ae5563@mail.gmail.com> <461BE318.6040904@aei.ca> <461CAC2A.8030509@mailing.kaufland-informationssysteme.com> <461DC03C.6010004@aei.ca> <288245630704120149k311a362bj52eef88f93eba20a@mail.gmail.com><461E1D12.6020704@aei.ca> <461E46E1.5050400@mailing.kaufland-informationssysteme.com> Message-ID: <804160344192334BB21922E8082EA6C074F9E9@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net > [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On > Behalf Of Matthias Eble > Sent: April 12, 2007 10:49 > To: Nagios Plugin Development Mailing List > Subject: Re: [Nagiosplug-devel] Feature Request: Check_cluster2 > > I'd really like to implement it, if everybody is fine with > it, but I'll > go on vacation on Saturday and will likely be offline for two weeks. > Maybe I can get it to work until tomorrow. I'll post a message if the > time is not enough. So eg Thomas can do it in the meantime. I'm not sure when I can do it so I guess we'll know only when it happens... If you fear both of us could do it at the same time I'm hanging in the #nagios channel on irc.freenode.net (nick: dermoth) so /msg me if you start working on it :) > The name should be changed, in my opinion, too. > I like check_states. check_cluster is to special to me since > the checked > services/hosts only _might_ be part of a "Cluster". > > One more thing: Check_cluster is also mentioned in the nagios docs.. > this should be considered when renaming. The doc can be changed, though I like check_cluster. Unless someone objects or beat me up on time I'll use that. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From benoit.mortier at opensides.be Fri Apr 13 12:16:58 2007 From: benoit.mortier at opensides.be (Benoit Mortier) Date: Fri, 13 Apr 2007 12:16:58 +0200 Subject: [Nagiosplug-devel] Welcome to the "Nagiosplug-i18n" mailing list Message-ID: <200704131217.01561.benoit.mortier@opensides.be> Hello, In an effort to have more people help with the translation of the nagios-plugins we have open a mailing list dedicated to the translation of the nagios plugins. Everybody is welcome ;-) The list is at https://lists.sourceforge.net/lists/listinfo/nagiosplug-i18n Have a good day -- Benoit Mortier CEO www.opensides.be Contributor to Gosa Project : http://gosa.gonicus.de/ Contributeur to Nagios Plugins : http://nagiosplug.sourceforge.net/ From benoit.mortier at opensides.be Fri Apr 13 12:39:57 2007 From: benoit.mortier at opensides.be (Benoit Mortier) Date: Fri, 13 Apr 2007 12:39:57 +0200 Subject: [Nagiosplug-devel] A nagios Day at the rmll 2007 Message-ID: <200704131239.59450.benoit.mortier@opensides.be> Hello, i have been asked to organize a Monitoring/Nagios day at the rmll 2007. For the people who don't know it, the RMLL are the "LIBRE SOFTWARE MEETING", they are organized each year in a different french city. For 4 days people share knowledge, discuss with other people, look for technical achievement, listen to speakers in various topics in a cool and friendly way. Those 4 days are free to attend for everybody. I have thought of the following schedule and looking for speaker in it, but it is not fixed. 1) Whats i Nagios, how does it work, Why is it diff?rent from others monitoring tools. 2) What are the plugins, how do they work, why are they so special 3) Nagios graphing, performance data, integrating with other graphing tools 4) Nagios Multi-site, failover, clustering monitoring. 5) Nagios NDO, how does they work 6) Nagios Real use Case 7) Future of Nagios, Nagios 3 -- Benoit Mortier CEO www.opensides.be Contributor to Gosa Project : http://gosa.gonicus.de/ Contributeur to Nagios Plugins : http://nagiosplug.sourceforge.net/ From matthias.eble at mailing.kaufland-informationssysteme.com Fri Apr 13 15:35:44 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Fri, 13 Apr 2007 15:35:44 +0200 Subject: [Nagiosplug-devel] Feature Request: Check_cluster2 In-Reply-To: <804160344192334BB21922E8082EA6C074F9E9@seaex01.180solutions.com> References: <288245630704100646l762868a3s63c8864f81ae5563@mail.gmail.com> <461BE318.6040904@aei.ca> <461CAC2A.8030509@mailing.kaufland-informationssysteme.com> <461DC03C.6010004@aei.ca> <288245630704120149k311a362bj52eef88f93eba20a@mail.gmail.com><461E1D12.6020704@aei.ca> <461E46E1.5050400@mailing.kaufland-informationssysteme.com> <804160344192334BB21922E8082EA6C074F9E9@seaex01.180solutions.com> Message-ID: <461F8730.1010204@mailing.kaufland-informationssysteme.com> Hi Thomas, great.. i tried to get it included in my local copy.. the basic version worked well but I compile failed when I included utils.h and called a function from it. I've no experience with automake unfortunately. I tried to reach you on #nagios but I guess you were away.. Are you going to implement the range stuff? OFFTOPIC: Has anyone got a good tutorial on the build tools? matthias From noreply at sourceforge.net Fri Apr 13 15:59:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Apr 2007 06:59:19 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1675286 ] The "-S" flag on the check_by_ssh plugin does not work Message-ID: Bugs item #1675286, was opened at 2007-03-06 22:37 Message generated for change (Comment added) made by johnnytenpin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1675286&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hector (higles2000) Assigned to: Nobody/Anonymous (nobody) Summary: The "-S" flag on the check_by_ssh plugin does not work Initial Comment: The "-S" flag on the check_by_ssh plugin does not work in versions 1.4.3 and 1.4.6, it does work when I run version 1.4.2. Not sure what changed from one version to the next. Suppressing stderr altogether for this plugin would also resolve the issue. ---------------------------------------------------------------------- Comment By: johnnytenpin (johnnytenpin) Date: 2007-04-13 15:59 Message: Logged In: YES user_id=1768734 Originator: NO Also broken in 1.4.8 The '--skiplines n' option is broken as well, with -S the script will run and fail on output, with --skiplines the script fails with: "./check_by_ssh: unrecognized option `--skiplines'" check_by_ssh from nagios-plugins 1.4.1 works correctly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1675286&group_id=29880 From Thomas at zango.com Fri Apr 13 16:48:55 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Fri, 13 Apr 2007 07:48:55 -0700 Subject: [Nagiosplug-devel] Feature Request: Check_cluster2 In-Reply-To: <461F8730.1010204@mailing.kaufland-informationssysteme.com> References: <288245630704100646l762868a3s63c8864f81ae5563@mail.gmail.com> <461BE318.6040904@aei.ca> <461CAC2A.8030509@mailing.kaufland-informationssysteme.com> <461DC03C.6010004@aei.ca> <288245630704120149k311a362bj52eef88f93eba20a@mail.gmail.com><461E1D12.6020704@aei.ca> <461E46E1.5050400@mailing.kaufland-informationssysteme.com><804160344192334BB21922E8082EA6C074F9E9@seaex01.180solutions.com> <461F8730.1010204@mailing.kaufland-informationssysteme.com> Message-ID: <804160344192334BB21922E8082EA6C07979EF@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net > [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On > Behalf Of Matthias Eble > Sent: April 13, 2007 9:36 > To: Nagios Plugin Development Mailing List > Subject: Re: [Nagiosplug-devel] Feature Request: Check_cluster2 > > Hi Thomas, > > great.. i tried to get it included in my local copy.. > the basic version worked well but I compile failed when I included > utils.h and called a function from it. I've no experience > with automake Look at the Makefile.am in the plugins directory. I believe all you have to do is change this line: check_cluster_DEPENDENCIES = check_cluster.c $(DEPLIBS) To this: check_cluster_DEPENDENCIES = check_cluster.c $(BASEOBJS) $(DEPLIBS) I'm no Automake guru either, I usually check what's being done for similar plugins and derive my code from them. Basically those lines tells automake what's required for building those. > unfortunately. I tried to reach you on #nagios but I guess > you were away.. Was there a bit earlier... > Are you going to implement the range stuff? Like you want. I could likely do it tonight... > OFFTOPIC: Has anyone got a good tutorial on the build tools? See the automake/autoconf home pages: http://sources.redhat.com/automake/ http://www.gnu.org/software/autoconf/ Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From matthias.eble at mailing.kaufland-informationssysteme.com Fri Apr 13 17:35:22 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Fri, 13 Apr 2007 17:35:22 +0200 Subject: [Nagiosplug-devel] Feature Request: Check_cluster2 In-Reply-To: <804160344192334BB21922E8082EA6C07979EF@seaex01.180solutions.com> References: <288245630704100646l762868a3s63c8864f81ae5563@mail.gmail.com> <461BE318.6040904@aei.ca> <461CAC2A.8030509@mailing.kaufland-informationssysteme.com> <461DC03C.6010004@aei.ca> <288245630704120149k311a362bj52eef88f93eba20a@mail.gmail.com><461E1D12.6020704@aei.ca> <461E46E1.5050400@mailing.kaufland-informationssysteme.com><804160344192334BB21922E8082EA6C074F9E9@seaex01.180solutions.com> <461F8730.1010204@mailing.kaufland-informationssysteme.com> <804160344192334BB21922E8082EA6C07979EF@seaex01.180solutions.com> Message-ID: <461FA33A.1010004@mailing.kaufland-informationssysteme.com> > > Look at the Makefile.am in the plugins directory. I believe all you have to > do is change this line: > > check_cluster_DEPENDENCIES = check_cluster.c $(DEPLIBS) > > To this: > > check_cluster_DEPENDENCIES = check_cluster.c $(BASEOBJS) $(DEPLIBS) > > I'm no Automake guru either, I usually check what's being done for similar > plugins and derive my code from them. Basically those lines tells automake > what's required for building those. i tried to do so (derive and so on) i think I tried sth like your your proposal, too. I'll try, too > >> Are you going to implement the range stuff? > > Like you want. I could likely do it tonight... please do it. I'll do it offline for training purposes.. i probably won't get it before my journey.. I will make t/check_cluster.t then and check it in tonight.. > >> OFFTOPIC: Has anyone got a good tutorial on the build tools? > > See the automake/autoconf home pages: > http://sources.redhat.com/automake/ > http://www.gnu.org/software/autoconf/ > I tried to start there a couple of months ago without success. Maybe I should try again... thanks matthias From ugob at lubik.ca Fri Apr 13 23:38:26 2007 From: ugob at lubik.ca (Ugo Bellavance) Date: Fri, 13 Apr 2007 17:38:26 -0400 Subject: [Nagiosplug-devel] check_mailq_in Message-ID: Hi, I manage many MailScanner servers, and therefore have modified check_mailq 1.6 so that I can monitor the inbound queue on my servers (located in /var/spool/mqueue.in). Would it be possible to include such a version or make check_mailq more flexible so that we can provide the queue path as an argument? I'm basically just trying to find a way to avoid having to edit all the check_mailq files manually everytime check_mailq is updated. If you'd like, I'll gladly edit check_mailq when a version is out so that you can add my check_mailq_in in the package. Regards, Ugo Bellavance From noreply at sourceforge.net Sat Apr 14 05:11:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Apr 2007 20:11:25 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1675286 ] The "-S" flag on the check_by_ssh plugin does not work Message-ID: Bugs item #1675286, was opened at 2007-03-06 22:37 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1675286&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Hector (higles2000) >Assigned to: Holger Weiss (hweiss) Summary: The "-S" flag on the check_by_ssh plugin does not work Initial Comment: The "-S" flag on the check_by_ssh plugin does not work in versions 1.4.3 and 1.4.6, it does work when I run version 1.4.2. Not sure what changed from one version to the next. Suppressing stderr altogether for this plugin would also resolve the issue. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-04-14 05:11 Message: Logged In: YES user_id=759506 Originator: NO Up to the 1.4.2 release, "-S" skipped the specified number of lines written to stderr. With 1.4.3 and newer, "-S" skips the specified number of lines written to stdout. I now changed the behaviour as follows: 1) "-S" skips the specified number of lines written to stderr. 2) If the number specified via "-S" minus the number of lines written to stderr is larger than 0, the difference is used as the number of lines written to stdout to skip. However, if you want to ignore all output written to stderr by ssh(1) itself (such as logon banners), simply use the "-q" flag. Mentioning "--skiplines" was an error in the "--help" output, the long option of "-S" is called "--skip". I fixed the "--help" output. Thanks for your report, Holger ---------------------------------------------------------------------- Comment By: johnnytenpin (johnnytenpin) Date: 2007-04-13 15:59 Message: Logged In: YES user_id=1768734 Originator: NO Also broken in 1.4.8 The '--skiplines n' option is broken as well, with -S the script will run and fail on output, with --skiplines the script fails with: "./check_by_ssh: unrecognized option `--skiplines'" check_by_ssh from nagios-plugins 1.4.1 works correctly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1675286&group_id=29880 From noreply at sourceforge.net Sat Apr 14 16:59:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Apr 2007 07:59:53 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1433179 ] check_jabber (check_tcp) does not honor --mismatch Message-ID: Bugs item #1433179, was opened at 2006-02-16 16:27 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1433179&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: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: BuckNaked (mnk26) >Assigned to: Thomas Guyot (dermoth) Summary: check_jabber (check_tcp) does not honor --mismatch Initial Comment: expect_mismatch_state is set but is never used anywhere. ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2007-04-14 10:59 Message: Logged In: YES user_id=375623 Originator: NO It does. After deliberately breaking the expect match: $ plugins/check_jabber -H jabber.org JABBER WARNING - Unexpected response from host/socket on port 5222|time=0.217635s;0.000000;0.000000;0.000000;10.000000 $ plugins/check_jabber -H jabber.org --mismatch=crit JABBER CRITICAL - Unexpected response from host/socket on port 5222|time=0.193435s;0.000000;0.000000;0.000000;10.000000 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1433179&group_id=29880 From noreply at sourceforge.net Sun Apr 15 08:43:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Apr 2007 23:43:51 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1344584 ] check_snmp Counter64 values not handled correctly Message-ID: Bugs item #1344584, was opened at 2005-11-01 01:44 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1344584&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: snapshot tarball >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: prjctgeek (prjctgeek) >Assigned to: Thomas Guyot (dermoth) Summary: check_snmp Counter64 values not handled correctly Initial Comment: After adding this snippet at line 253 else if (strstr (response, "Counter64: ")) { show = strstr (response, "Counter64: ") + 11; } and at 285-to show long longs asprintf (&show, "%llu", response_value[i]); the comparison of Counter64 values to the warning and critical ranges still do not function correctly. ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-04-15 02:43 Message: Logged In: YES user_id=375623 Originator: NO this problem is now fixed in cvs. thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1344584&group_id=29880 From dermoth at aei.ca Sun Apr 15 20:00:03 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Sun, 15 Apr 2007 14:00:03 -0400 Subject: [Nagiosplug-devel] Feature Request: Check_cluster2 In-Reply-To: <288245630704120149k311a362bj52eef88f93eba20a@mail.gmail.com> References: <288245630704100646l762868a3s63c8864f81ae5563@mail.gmail.com> <461BE318.6040904@aei.ca> <461CAC2A.8030509@mailing.kaufland-informationssysteme.com> <461DC03C.6010004@aei.ca> <288245630704120149k311a362bj52eef88f93eba20a@mail.gmail.com> Message-ID: <46226823.8020701@aei.ca> On 12/04/07 04:49 AM, Mark Eisenblaetter wrote: > Hi, > > will it be possible to use both minimm and maximum at the same time? > In my case it would be the same problem with minimum or maximum. > > So I would prefer the ranges like check_procs, to be able to alert > both maximum and minimum? Hi Mark, You can try with the latest CVS HEAD (or wait until tomorrow and download the latest snapshot (Apr 16 or latter) from: http://nagiosplug.sourceforge.net/snapshot/ ). check_cluster2 had been added to the main nagios-plugins distribution as check_cluster, and now use the official threshold format. Note that this breaks backward-compatibility, for example "-w 1 -c 2" should now be written "-w 0 -c 1" to get the same results. Thomas From mark.eisenblaetter at gmail.com Mon Apr 16 09:19:13 2007 From: mark.eisenblaetter at gmail.com (Mark Eisenblaetter) Date: Mon, 16 Apr 2007 09:19:13 +0200 Subject: [Nagiosplug-devel] Feature Request: Check_cluster2 In-Reply-To: <46226823.8020701@aei.ca> References: <288245630704100646l762868a3s63c8864f81ae5563@mail.gmail.com> <461BE318.6040904@aei.ca> <461CAC2A.8030509@mailing.kaufland-informationssysteme.com> <461DC03C.6010004@aei.ca> <288245630704120149k311a362bj52eef88f93eba20a@mail.gmail.com> <46226823.8020701@aei.ca> Message-ID: <288245630704160019w48d5f2c1j7ee1c3b8f0950ead@mail.gmail.com> Hi Thomas, wow, thats fast. I will try it today and gife some feedback. Thanks Mark On 4/15/07, Thomas Guyot-Sionnest wrote: > On 12/04/07 04:49 AM, Mark Eisenblaetter wrote: > > Hi, > > > > will it be possible to use both minimm and maximum at the same time? > > In my case it would be the same problem with minimum or maximum. > > > > So I would prefer the ranges like check_procs, to be able to alert > > both maximum and minimum? > > Hi Mark, > > You can try with the latest CVS HEAD (or wait until tomorrow and > download the latest snapshot (Apr 16 or latter) from: > http://nagiosplug.sourceforge.net/snapshot/ ). > > check_cluster2 had been added to the main nagios-plugins distribution as > check_cluster, and now use the official threshold format. Note that this > breaks backward-compatibility, for example "-w 1 -c 2" should now be > written "-w 0 -c 1" to get the same results. > > Thomas > -- Mark Eisenbl?tter Geissendoerfer & Leschinsky GmbH www.gl-sytemhaus.de From ton.voon at altinity.com Tue Apr 17 10:19:42 2007 From: ton.voon at altinity.com (Ton Voon) Date: Tue, 17 Apr 2007 09:19:42 +0100 Subject: [Nagiosplug-devel] Patch to check_load to cater for multiple CPUs Message-ID: <36282BFE-6468-4386-A060-646072A75A48@altinity.com> Hi! Wanted to get a 2nd (or 3rd or 4th...) opinion on this. I've received a patch from a customer for check_load so that it divides the load averages by the number of CPUs (based on returned values from sysconf). This works on their Redhat servers, but I don't know if all unices provide this system call. I guess configure could see if sysconf was available and just return -1 if not - would that be sufficient? Would we need to check for the existence of the _SC_NPROCESSORS_CONF attribute too? Patch attached. Opinions? Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- A non-text attachment was scrubbed... Name: check_load_percpu_v2.diff Type: text/x-patch Size: 2275 bytes Desc: not available URL: -------------- next part -------------- From holger at CIS.FU-Berlin.DE Tue Apr 17 10:55:09 2007 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Tue, 17 Apr 2007 10:55:09 +0200 Subject: [Nagiosplug-devel] Patch to check_load to cater for multiple CPUs In-Reply-To: <36282BFE-6468-4386-A060-646072A75A48@altinity.com> References: <36282BFE-6468-4386-A060-646072A75A48@altinity.com> Message-ID: <20070417085509.GM161803@CIS.FU-Berlin.DE> * Ton Voon [2007-04-17 09:19]: > Wanted to get a 2nd (or 3rd or 4th...) opinion on this. I've received > a patch from a customer for check_load so that it divides the load > averages by the number of CPUs (based on returned values from > sysconf). This works on their Redhat servers, but I don't know if all > unices provide this system call. I guess configure could see if > sysconf was available and just return -1 if not - would that be > sufficient? > > Would we need to check for the existence of the _SC_NPROCESSORS_CONF > attribute too? sysconf(3) is POSIX.1 and should be very portable, but _SC_NPROCESSORS_CONF isn't, at least NetBSD and IRIX don't know it (IRIX knows _SC_NPROC_CONF, I'm not aware of an equivalent on NetBSD). So yes, we should add an Autoconf check. Holger -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE From ae at op5.se Tue Apr 17 15:24:05 2007 From: ae at op5.se (Andreas Ericsson) Date: Tue, 17 Apr 2007 15:24:05 +0200 Subject: [Nagiosplug-devel] [Nagiosplug-checkins] nagiosplug/plugins check_by_ssh.c, 1.41, 1.42 In-Reply-To: References: Message-ID: <4624CA75.8080404@op5.se> Holger Weiss wrote: > Update of /cvsroot/nagiosplug/nagiosplug/plugins > In directory sc8-pr-cvs16:/tmp/cvs-serv13836/plugins > > Modified Files: > check_by_ssh.c > Log Message: > Up to revision 1.35, the "-S" option skipped the specified number of > lines written to stderr. With revision 1.36 and newer, "-S" skipped the > specified number of lines written to stdout. Now, "-S" skips the > specified number of lines written to stderr; and if the number specified > via "-S" minus the number of lines written to stderr is larger than 0, > the difference is used as the number of lines written to stdout to skip. > Also, the "--help" output was fixed. (Hector - 1675286) > So.. If --skip=10 is used, and there's 7 lines of output on stderr, the first 3 lines of stdout are skipped? Why not just keep "--skiplines" as-is, and introduce --skip-stderr and --skip-stdout, which would solve the same problem in a more intuitive way, not break backwards-compatibility *and* provide a finer granularity. When specified without options, they should skip ALL output on the targeted fd. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From mark.eisenblaetter at gmail.com Tue Apr 17 16:53:07 2007 From: mark.eisenblaetter at gmail.com (Mark Eisenblaetter) Date: Tue, 17 Apr 2007 16:53:07 +0200 Subject: [Nagiosplug-devel] Feature Request: Check_cluster2 In-Reply-To: <288245630704160019w48d5f2c1j7ee1c3b8f0950ead@mail.gmail.com> References: <288245630704100646l762868a3s63c8864f81ae5563@mail.gmail.com> <461BE318.6040904@aei.ca> <461CAC2A.8030509@mailing.kaufland-informationssysteme.com> <461DC03C.6010004@aei.ca> <288245630704120149k311a362bj52eef88f93eba20a@mail.gmail.com> <46226823.8020701@aei.ca> <288245630704160019w48d5f2c1j7ee1c3b8f0950ead@mail.gmail.com> Message-ID: <288245630704170753i6b11f3b8y651152463f585ddf@mail.gmail.com> Hi, it working fine. nice job so i can update my production server. Mark On 4/16/07, Mark Eisenblaetter wrote: > Hi Thomas, > > wow, thats fast. I will try it today and gife some feedback. > > Thanks > Mark > > On 4/15/07, Thomas Guyot-Sionnest wrote: > > On 12/04/07 04:49 AM, Mark Eisenblaetter wrote: > > > Hi, > > > > > > will it be possible to use both minimm and maximum at the same time? > > > In my case it would be the same problem with minimum or maximum. > > > > > > So I would prefer the ranges like check_procs, to be able to alert > > > both maximum and minimum? > > > > Hi Mark, > > > > You can try with the latest CVS HEAD (or wait until tomorrow and > > download the latest snapshot (Apr 16 or latter) from: > > http://nagiosplug.sourceforge.net/snapshot/ ). > > > > check_cluster2 had been added to the main nagios-plugins distribution as > > check_cluster, and now use the official threshold format. Note that this > > breaks backward-compatibility, for example "-w 1 -c 2" should now be > > written "-w 0 -c 1" to get the same results. > > > > Thomas > > > > > -- > Mark Eisenbl?tter > Geissendoerfer & Leschinsky GmbH > www.gl-sytemhaus.de > -- Mark Eisenbl?tter Geissendoerfer & Leschinsky GmbH www.gl-sytemhaus.de From holger at CIS.FU-Berlin.DE Tue Apr 17 17:04:10 2007 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Tue, 17 Apr 2007 17:04:10 +0200 Subject: [Nagiosplug-devel] [Nagiosplug-checkins] nagiosplug/plugins check_by_ssh.c, 1.41, 1.42 In-Reply-To: <4624CA75.8080404@op5.se> References: <4624CA75.8080404@op5.se> Message-ID: <20070417150410.GO161803@CIS.FU-Berlin.DE> * Andreas Ericsson [2007-04-17 15:24]: > Holger Weiss wrote: > > Update of /cvsroot/nagiosplug/nagiosplug/plugins > > In directory sc8-pr-cvs16:/tmp/cvs-serv13836/plugins > > > > Modified Files: > > check_by_ssh.c > > Log Message: > > Up to revision 1.35, the "-S" option skipped the specified number of > > lines written to stderr. With revision 1.36 and newer, "-S" skipped the > > specified number of lines written to stdout. Now, "-S" skips the > > specified number of lines written to stderr; and if the number specified > > via "-S" minus the number of lines written to stderr is larger than 0, > > the difference is used as the number of lines written to stdout to skip. > > Also, the "--help" output was fixed. (Hector - 1675286) > > So.. If --skip=10 is used, and there's 7 lines of output on stderr, the first > 3 lines of stdout are skipped? Yes. > Why not just keep "--skiplines" as-is You mean keep it as it was up to r1.35 ("--skip-stderr") or between r1.36 and r1.41 ("--skip-stdout")? > and introduce --skip-stderr and --skip-stdout, which would solve the > same problem in a more intuitive way, not break backwards-compatibility > *and* provide a finer granularity. Well, the problem I tried to fix was that we *did* break backwards compatibility with releases <= 1.4.2 and users complained about that. My idea was to make things somewhat compatible with both the old and the new behaviour. However, I agree that the result really seems too clumsy, especially as it doesn't provide real backwards compatibility anyway. Actually, I thought about reverting that in favour of the options you suggested myself. Convinced, will do. > When specified without options, they should skip ALL output on the targeted > fd. Yes. Thanks, Holger -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE From ae at op5.se Tue Apr 17 17:15:11 2007 From: ae at op5.se (Andreas Ericsson) Date: Tue, 17 Apr 2007 17:15:11 +0200 Subject: [Nagiosplug-devel] [Nagiosplug-checkins] nagiosplug/plugins check_by_ssh.c, 1.41, 1.42 In-Reply-To: <20070417150410.GO161803@CIS.FU-Berlin.DE> References: <4624CA75.8080404@op5.se> <20070417150410.GO161803@CIS.FU-Berlin.DE> Message-ID: <4624E47F.5000604@op5.se> Holger Weiss wrote: > * Andreas Ericsson [2007-04-17 15:24]: >> Holger Weiss wrote: >>> Update of /cvsroot/nagiosplug/nagiosplug/plugins >>> In directory sc8-pr-cvs16:/tmp/cvs-serv13836/plugins >>> >>> Modified Files: >>> check_by_ssh.c >>> Log Message: >>> Up to revision 1.35, the "-S" option skipped the specified number of >>> lines written to stderr. With revision 1.36 and newer, "-S" skipped the >>> specified number of lines written to stdout. Now, "-S" skips the >>> specified number of lines written to stderr; and if the number specified >>> via "-S" minus the number of lines written to stderr is larger than 0, >>> the difference is used as the number of lines written to stdout to skip. >>> Also, the "--help" output was fixed. (Hector - 1675286) >> So.. If --skip=10 is used, and there's 7 lines of output on stderr, the first >> 3 lines of stdout are skipped? > > Yes. > >> Why not just keep "--skiplines" as-is > > You mean keep it as it was up to r1.35 ("--skip-stderr") or between > r1.36 and r1.41 ("--skip-stdout")? > I'm not sure. Whichever was used in the most stable releases, I guess :P Mucking with how options work is not a good idea in a product so widely used as the nagiosplugins. Literally speaking, they're run tens of millions of times every day over the world. >> and introduce --skip-stderr and --skip-stdout, which would solve the >> same problem in a more intuitive way, not break backwards-compatibility >> *and* provide a finer granularity. > > Well, the problem I tried to fix was that we *did* break backwards > compatibility with releases <= 1.4.2 and users complained about that. > My idea was to make things somewhat compatible with both the old and the > new behaviour. However, I agree that the result really seems too > clumsy, especially as it doesn't provide real backwards compatibility > anyway. Actually, I thought about reverting that in favour of the > options you suggested myself. Convinced, will do. > Thanks. That should keep everyone happy (well, theoretically anyways). -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From holger at CIS.FU-Berlin.DE Tue Apr 17 17:24:50 2007 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Tue, 17 Apr 2007 17:24:50 +0200 Subject: [Nagiosplug-devel] [Nagiosplug-checkins] nagiosplug/plugins check_by_ssh.c, 1.41, 1.42 In-Reply-To: <4624E47F.5000604@op5.se> References: <4624CA75.8080404@op5.se> <20070417150410.GO161803@CIS.FU-Berlin.DE> <4624E47F.5000604@op5.se> Message-ID: <20070417152450.GP161803@CIS.FU-Berlin.DE> * Andreas Ericsson [2007-04-17 17:15]: > Holger Weiss wrote: > > * Andreas Ericsson [2007-04-17 15:24]: > >> Why not just keep "--skiplines" as-is > > > > You mean keep it as it was up to r1.35 ("--skip-stderr") or between > > r1.36 and r1.41 ("--skip-stdout")? > > I'm not sure. Whichever was used in the most stable releases, I guess :P Ok, if nobody objects, I'll go for keeping the newer behaviour in order to not change the option _again_, then. (That is, "--skip" would be an alias for "--skip-stdout".) > Mucking with how options work is not a good idea in a product so widely > used as the nagiosplugins. Sure, I fully agree. Holger -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE From noreply at sourceforge.net Wed Apr 18 11:16:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 Apr 2007 02:16:13 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1667488 ] check_dhcp: server identifier(54) as offerer/siaddr Message-ID: Patches item #1667488, was opened at 2007-02-23 22:54 Message generated for change (Comment added) made by deac- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1667488&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: 6 Private: No Submitted By: denis knauf (deac-) Assigned to: Nobody/Anonymous (nobody) Summary: check_dhcp: server identifier(54) as offerer/siaddr Initial Comment: check_dhcp doesn't use server identifier (54) as server (siaddr), but this is the real serveraddresse. source is only the address of the relay-dhcp (giaddr). this patch adds the server_identifier as siaddr. btw. please "ident" your code. it's so terrible to patch this files, if somebody wrotes such unreadable code. thanks. ---------------------------------------------------------------------- >Comment By: denis knauf (deac-) Date: 2007-04-18 11:16 Message: Logged In: YES user_id=608083 Originator: YES how much time you need to submit this patch to cvs? i don't understand, that the nagios-plugins-project is so slow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1667488&group_id=29880 From noreply at sourceforge.net Wed Apr 18 13:59:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 Apr 2007 04:59:40 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1667488 ] check_dhcp: server identifier(54) as offerer/siaddr Message-ID: Patches item #1667488, was opened at 2007-02-23 22:54 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1667488&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None Status: Open Resolution: None >Priority: 5 Private: No Submitted By: denis knauf (deac-) >Assigned to: Holger Weiss (hweiss) Summary: check_dhcp: server identifier(54) as offerer/siaddr Initial Comment: check_dhcp doesn't use server identifier (54) as server (siaddr), but this is the real serveraddresse. source is only the address of the relay-dhcp (giaddr). this patch adds the server_identifier as siaddr. btw. please "ident" your code. it's so terrible to patch this files, if somebody wrotes such unreadable code. thanks. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-04-18 13:59 Message: Logged In: YES user_id=759506 Originator: NO 1) We're all doing this on a voluntary basis. 2) Looking into a patch (that is, understanding it, testing it, making sure that it does the right thing[tm], that it's portable, that it doesn't introduce subtle side effects, and so on) takes time. 3) Adding such comments and increasing the tracker item priority *without* an apparent reason generally won't speed things up. 4) Although I personally prefer other styles of indentation than the one used in check_dhcp.c (but that's just a matter of taste), the critical point is to be *consistent* with your indentation, which check_dhcp.c *is*. As a side note, it would be nice to have a consistent indentation style across *all* plugins, which we currently haven't. However, changing indentation style has the *big* drawback that it makes cvs diffs which cross the indentation change unreadable. 5) When contributing patches, it is generally considered bad style to break such consistency and/or to include changes other than the actual fix/feature within the same diff. 6) However, thank you for your patch. ---------------------------------------------------------------------- Comment By: denis knauf (deac-) Date: 2007-04-18 11:16 Message: Logged In: YES user_id=608083 Originator: YES how much time you need to submit this patch to cvs? i don't understand, that the nagios-plugins-project is so slow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1667488&group_id=29880 From noreply at sourceforge.net Wed Apr 18 14:26:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 Apr 2007 05:26:25 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1667488 ] check_dhcp: server identifier(54) as offerer/siaddr Message-ID: Patches item #1667488, was opened at 2007-02-23 22:54 Message generated for change (Comment added) made by deac- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1667488&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: denis knauf (deac-) Assigned to: Holger Weiss (hweiss) Summary: check_dhcp: server identifier(54) as offerer/siaddr Initial Comment: check_dhcp doesn't use server identifier (54) as server (siaddr), but this is the real serveraddresse. source is only the address of the relay-dhcp (giaddr). this patch adds the server_identifier as siaddr. btw. please "ident" your code. it's so terrible to patch this files, if somebody wrotes such unreadable code. thanks. ---------------------------------------------------------------------- >Comment By: denis knauf (deac-) Date: 2007-04-18 14:26 Message: Logged In: YES user_id=608083 Originator: YES if nothing happens, everybody thinks, the project is dead. my patch we (fachhochschule koeln - netzwerkzentrum/university of applied siences cologne - network operations center) use productive. we are highliy interested, that this patch is officially in nagios-plugins. and i'm interested in a clean coding standard. for example this: indent -nbfde -nbfda -npsl -nbad -bap -br -nce -bli0 -ncdw -ut -l80 -i4 -ts4 -cbi0 -nss -pcs -cs -bs -saf -sai -saw -nbc -brs -bls -ppi4 -ci8 -nlp i had to indent all the code to understand this program and patch one. then i had to backport it to unclean code. this had taken many time. ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-04-18 13:59 Message: Logged In: YES user_id=759506 Originator: NO 1) We're all doing this on a voluntary basis. 2) Looking into a patch (that is, understanding it, testing it, making sure that it does the right thing[tm], that it's portable, that it doesn't introduce subtle side effects, and so on) takes time. 3) Adding such comments and increasing the tracker item priority *without* an apparent reason generally won't speed things up. 4) Although I personally prefer other styles of indentation than the one used in check_dhcp.c (but that's just a matter of taste), the critical point is to be *consistent* with your indentation, which check_dhcp.c *is*. As a side note, it would be nice to have a consistent indentation style across *all* plugins, which we currently haven't. However, changing indentation style has the *big* drawback that it makes cvs diffs which cross the indentation change unreadable. 5) When contributing patches, it is generally considered bad style to break such consistency and/or to include changes other than the actual fix/feature within the same diff. 6) However, thank you for your patch. ---------------------------------------------------------------------- Comment By: denis knauf (deac-) Date: 2007-04-18 11:16 Message: Logged In: YES user_id=608083 Originator: YES how much time you need to submit this patch to cvs? i don't understand, that the nagios-plugins-project is so slow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1667488&group_id=29880 From holger at CIS.FU-Berlin.DE Wed Apr 18 17:44:10 2007 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Wed, 18 Apr 2007 17:44:10 +0200 Subject: [Nagiosplug-devel] [Nagiosplug-checkins] nagiosplug/plugins check_by_ssh.c, 1.41, 1.42 In-Reply-To: <4624CA75.8080404@op5.se> References: <4624CA75.8080404@op5.se> Message-ID: <20070418154409.GQ161803@CIS.FU-Berlin.DE> * Andreas Ericsson [2007-04-17 15:24]: > Why not just keep "--skiplines" as-is, and introduce --skip-stderr and > --skip-stdout, which would solve the same problem in a more intuitive way, > not break backwards-compatibility *and* provide a finer granularity. > > When specified without options, they should skip ALL output on the targeted > fd. Hmm, really skip _all_ output in case of "--skip-stdout" and print nothing? Or print just the last line? Or print a line generated by check_by_ssh? Holger -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE From ae at op5.se Wed Apr 18 17:46:54 2007 From: ae at op5.se (Andreas Ericsson) Date: Wed, 18 Apr 2007 17:46:54 +0200 Subject: [Nagiosplug-devel] [Nagiosplug-checkins] nagiosplug/plugins check_by_ssh.c, 1.41, 1.42 In-Reply-To: <20070418154409.GQ161803@CIS.FU-Berlin.DE> References: <4624CA75.8080404@op5.se> <20070418154409.GQ161803@CIS.FU-Berlin.DE> Message-ID: <46263D6E.7050807@op5.se> Holger Weiss wrote: > * Andreas Ericsson [2007-04-17 15:24]: >> Why not just keep "--skiplines" as-is, and introduce --skip-stderr and >> --skip-stdout, which would solve the same problem in a more intuitive way, >> not break backwards-compatibility *and* provide a finer granularity. >> >> When specified without options, they should skip ALL output on the targeted >> fd. > > Hmm, really skip _all_ output in case of "--skip-stdout" and print > nothing? Or print just the last line? Or print a line generated by > check_by_ssh? > Skip all of it. If --skip-stdout and --skip-stderr is used together cook up some message ("check_by_ssh: remote command ' exited (un)successfully) and let it be at that. Some programs people might want to run don't print output useful for displaying, or prints multiline output, or... -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From pitchfork at ederdrom.de Wed Apr 18 21:10:30 2007 From: pitchfork at ederdrom.de (Joerg Linge) Date: Wed, 18 Apr 2007 21:10:30 +0200 Subject: [Nagiosplug-devel] Patch: remove check_buffer stats in cgi/extinfo.c Message-ID: <200704182110.30732.pitchfork@ederdrom.de> Hi Ethan, the buffer_stats[1] are no longer needed in cgi/extinfo.c The patch just deletes Line 2415 Joerg -------------- next part -------------- A non-text attachment was scrubbed... Name: remove_check_buffer.extinfo.c.patch Type: text/x-diff Size: 754 bytes Desc: not available URL: From holger at CIS.FU-Berlin.DE Wed Apr 18 21:31:57 2007 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Wed, 18 Apr 2007 21:31:57 +0200 Subject: [Nagiosplug-devel] [Nagiosplug-checkins] nagiosplug/plugins check_by_ssh.c, 1.41, 1.42 In-Reply-To: <46263D6E.7050807@op5.se> References: <4624CA75.8080404@op5.se> <20070418154409.GQ161803@CIS.FU-Berlin.DE> <46263D6E.7050807@op5.se> Message-ID: <20070418193157.GR161803@CIS.FU-Berlin.DE> * Andreas Ericsson [2007-04-18 17:46]: > Holger Weiss wrote: > > * Andreas Ericsson [2007-04-17 15:24]: > >> Why not just keep "--skiplines" as-is, and introduce --skip-stderr and > >> --skip-stdout, which would solve the same problem in a more intuitive way, > >> not break backwards-compatibility *and* provide a finer granularity. > >> > >> When specified without options, they should skip ALL output on the targeted > >> fd. > > > > Hmm, really skip _all_ output in case of "--skip-stdout" and print > > nothing? Or print just the last line? Or print a line generated by > > check_by_ssh? > > Skip all of it. If --skip-stdout and --skip-stderr is used together cook up > some message ("check_by_ssh: remote command ' exited > (un)successfully) and let it be at that. I've added a message which is printed if no (non-skipped) stdout/stderr output is available, regardless of whether/which "--skip*" options have been specified. Thanks again, Holger -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE From noreply at sourceforge.net Wed Apr 18 21:41:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 Apr 2007 12:41:19 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1675286 ] The "-S" flag on the check_by_ssh plugin does not work Message-ID: Bugs item #1675286, was opened at 2007-03-06 22:37 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1675286&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Hector (higles2000) Assigned to: Holger Weiss (hweiss) Summary: The "-S" flag on the check_by_ssh plugin does not work Initial Comment: The "-S" flag on the check_by_ssh plugin does not work in versions 1.4.3 and 1.4.6, it does work when I run version 1.4.2. Not sure what changed from one version to the next. Suppressing stderr altogether for this plugin would also resolve the issue. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-04-18 21:41 Message: Logged In: YES user_id=759506 Originator: NO Following a suggestion of Andreas Ericsson (thanks!), I reverted my change to the "-S/--skip" option in favour of the two options "-E/--skip-stderr" and "-S/--skip-stdout" ("--skip" is kept as an alias for "--skip-stdout" for backwards compatibility with recent releases). Both options support omitting the number of lines to skip, in which case all output on the respective file descriptor is skipped. This should make things clearer and more flexible. However, to get the behaviour of "-S" up to the 1.4.2 release, you'll have to use "-E" with future releases. Sorry for the confusion. ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-04-14 05:11 Message: Logged In: YES user_id=759506 Originator: NO Up to the 1.4.2 release, "-S" skipped the specified number of lines written to stderr. With 1.4.3 and newer, "-S" skips the specified number of lines written to stdout. I now changed the behaviour as follows: 1) "-S" skips the specified number of lines written to stderr. 2) If the number specified via "-S" minus the number of lines written to stderr is larger than 0, the difference is used as the number of lines written to stdout to skip. However, if you want to ignore all output written to stderr by ssh(1) itself (such as logon banners), simply use the "-q" flag. Mentioning "--skiplines" was an error in the "--help" output, the long option of "-S" is called "--skip". I fixed the "--help" output. Thanks for your report, Holger ---------------------------------------------------------------------- Comment By: johnnytenpin (johnnytenpin) Date: 2007-04-13 15:59 Message: Logged In: YES user_id=1768734 Originator: NO Also broken in 1.4.8 The '--skiplines n' option is broken as well, with -S the script will run and fail on output, with --skiplines the script fails with: "./check_by_ssh: unrecognized option `--skiplines'" check_by_ssh from nagios-plugins 1.4.1 works correctly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1675286&group_id=29880 From noreply at sourceforge.net Thu Apr 19 18:27:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Apr 2007 09:27:17 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1703759 ] Unnecessary ${SHELL} in INSTALL_STRIP_PROGRAM options Message-ID: Bugs item #1703759, was opened at 2007-04-19 16:27 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=1703759&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nico Kadel-Garcia (nkadelgarcia) Assigned to: Nobody/Anonymous (nobody) Summary: Unnecessary ${SHELL} in INSTALL_STRIP_PROGRAM options Initial Comment: The presence in configure and configure.in of the unnecessary %{SHELL} means that attempts to use /usr/bin/install instead of install-sh fail miserably, and for no valid reason. The patch is below: diff -ur nagios-plugins-1.4.8/aclocal.m4 nagios-plugins-1.4.8.chmod/aclocal.m4 --- nagios-plugins-1.4.8/aclocal.m4 2007-04-11 08:11:58.000000000 -0400 +++ nagios-plugins-1.4.8.chmod/aclocal.m4 2007-04-19 11:07:41.000000000 -0400 @@ -7158,7 +7158,7 @@ if test "$cross_compiling" != no; then AC_CHECK_TOOL([STRIP], [strip], :) fi -INSTALL_STRIP_PROGRAM="\${SHELL} \$(install_sh) -c -s" +INSTALL_STRIP_PROGRAM="\$(install_sh) -c -s" AC_SUBST([INSTALL_STRIP_PROGRAM])]) # Check how to create a tarball. -*- Autoconf -*- diff -ur nagios-plugins-1.4.8/configure nagios-plugins-1.4.8.chmod/configure --- nagios-plugins-1.4.8/configure 2007-04-11 08:12:37.000000000 -0400 +++ nagios-plugins-1.4.8.chmod/configure 2007-04-19 11:11:31.000000000 -0400 @@ -2007,7 +2007,7 @@ fi fi -INSTALL_STRIP_PROGRAM="\${SHELL} \$(install_sh) -c -s" +INSTALL_STRIP_PROGRAM="\$(install_sh) -c -s" # We need awk for the "check" target. The system "awk" is bad on # some platforms. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1703759&group_id=29880 From nagios at nagios.org Thu Apr 19 18:41:44 2007 From: nagios at nagios.org (Ethan Galstad) Date: Thu, 19 Apr 2007 11:41:44 -0500 Subject: [Nagiosplug-devel] Patch: remove check_buffer stats in cgi/extinfo.c In-Reply-To: <200704182110.30732.pitchfork@ederdrom.de> References: <200704182110.30732.pitchfork@ederdrom.de> Message-ID: <46279BC8.2000306@nagios.org> Joerg Linge wrote: > Hi Ethan, > > the buffer_stats[1] are no longer needed in cgi/extinfo.c > > The patch just deletes Line 2415 > > Joerg Thanks Joerg! Ethan Galstad, Nagios Developer --- Email: nagios at nagios.org Website: http://www.nagios.org From pitchfork at ederdrom.de Thu Apr 19 18:50:32 2007 From: pitchfork at ederdrom.de (Joerg Linge) Date: Thu, 19 Apr 2007 18:50:32 +0200 Subject: [Nagiosplug-devel] Patch: remove check_buffer stats in cgi/extinfo.c In-Reply-To: <46279BC8.2000306@nagios.org> References: <200704182110.30732.pitchfork@ederdrom.de> <46279BC8.2000306@nagios.org> Message-ID: <200704191850.33145.pitchfork@ederdrom.de> Am Donnerstag, 19. April 2007 18:41 schrieb Ethan Galstad: > Joerg Linge wrote: > > Hi Ethan, > > > > the buffer_stats[1] are no longer needed in cgi/extinfo.c > > > > The patch just deletes Line 2415 > > > > Joerg > > Thanks Joerg! Oooops, posted to the wrong list ;-) Sorry about that. Joerg From noreply at sourceforge.net Thu Apr 19 20:16:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Apr 2007 11:16:12 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-1703823 ] [check_ntp] add option to verify stratum Message-ID: Feature Requests item #1703823, was opened at 2007-04-19 20:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1703823&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 Priority: 5 Private: No Submitted By: Enrico Scholz (ensc) Assigned to: Nobody/Anonymous (nobody) Summary: [check_ntp] add option to verify stratum Initial Comment: Please add an option which checks whether stratum of server exceeds a certain value. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1703823&group_id=29880 From noreply at sourceforge.net Fri Apr 20 02:50:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Apr 2007 17:50:30 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1703759 ] Unnecessary ${SHELL} in INSTALL_STRIP_PROGRAM options Message-ID: Bugs item #1703759, was opened at 2007-04-19 11:27 Message generated for change (Comment added) made by nkadel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1703759&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nico Kadel-Garcia (nkadelgarcia) Assigned to: Nobody/Anonymous (nobody) Summary: Unnecessary ${SHELL} in INSTALL_STRIP_PROGRAM options Initial Comment: The presence in configure and configure.in of the unnecessary %{SHELL} means that attempts to use /usr/bin/install instead of install-sh fail miserably, and for no valid reason. The patch is below: diff -ur nagios-plugins-1.4.8/aclocal.m4 nagios-plugins-1.4.8.chmod/aclocal.m4 --- nagios-plugins-1.4.8/aclocal.m4 2007-04-11 08:11:58.000000000 -0400 +++ nagios-plugins-1.4.8.chmod/aclocal.m4 2007-04-19 11:07:41.000000000 -0400 @@ -7158,7 +7158,7 @@ if test "$cross_compiling" != no; then AC_CHECK_TOOL([STRIP], [strip], :) fi -INSTALL_STRIP_PROGRAM="\${SHELL} \$(install_sh) -c -s" +INSTALL_STRIP_PROGRAM="\$(install_sh) -c -s" AC_SUBST([INSTALL_STRIP_PROGRAM])]) # Check how to create a tarball. -*- Autoconf -*- diff -ur nagios-plugins-1.4.8/configure nagios-plugins-1.4.8.chmod/configure --- nagios-plugins-1.4.8/configure 2007-04-11 08:12:37.000000000 -0400 +++ nagios-plugins-1.4.8.chmod/configure 2007-04-19 11:11:31.000000000 -0400 @@ -2007,7 +2007,7 @@ fi fi -INSTALL_STRIP_PROGRAM="\${SHELL} \$(install_sh) -c -s" +INSTALL_STRIP_PROGRAM="\$(install_sh) -c -s" # We need awk for the "check" target. The system "awk" is bad on # some platforms. ---------------------------------------------------------------------- Comment By: Nico Kadel-Garcia (nkadel) Date: 2007-04-19 19:50 Message: Logged In: YES user_id=923047 Originator: NO Dang. There are other fascinating little interactions, that interfere at least with installation as non-root users in various other ways. The DAG RPM's get around this by completely ignoring the "make install" option and doing it manually in the .spec files. It's a shame to have to do that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1703759&group_id=29880 From noreply at sourceforge.net Fri Apr 20 04:48:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Apr 2007 19:48:44 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-1703823 ] [check_ntp] add option to verify stratum Message-ID: Feature Requests item #1703823, was opened at 2007-04-19 14:16 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1703823&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 Priority: 5 Private: No Submitted By: Enrico Scholz (ensc) >Assigned to: Thomas Guyot (dermoth) Summary: [check_ntp] add option to verify stratum Initial Comment: Please add an option which checks whether stratum of server exceeds a certain value. ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2007-04-19 22:48 Message: Logged In: YES user_id=375623 Originator: NO That would be fairly easy now that i know that much about check_ntp and can be interesting in many scenarios :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1703823&group_id=29880 From rouilj at cs.umb.edu Fri Apr 20 06:00:59 2007 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Fri, 20 Apr 2007 00:00:59 -0400 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-1703823 ] [check_ntp] add option to verify stratum In-Reply-To: Your message of "Thu, 19 Apr 2007 19:48:44 PDT." Message-ID: <200704200400.l3K40xo0023534@mx1.cs.umb.edu> In message , "SourceForge.net" writes: >Submitted By: Enrico Scholz (ensc) >>Assigned to: Thomas Guyot (dermoth) >Initial Comment: >Please add an option which checks whether stratum of server exceeds a >certain value. > >---------------------------------------------------------------------- > >>Comment By: Thomas Guyot (dermoth) >Date: 2007-04-19 22:48 > >Message: >Logged In: YES >user_id=375623 >Originator: NO > >That would be fairly easy now that i know that much about check_ntp and >can be interesting in many scenarios :) I enhanced the original check_ntp script quite a while ago becuse it was monitoring things incorrectly according to my understanding of ntp. My stratum check accepts a range that the synchronization peer must be at. So -s 2:3 means that the sync peer host must be at 2 or 3. It returns a warning if the host is lower or higher then it should be. Also I think you already test warning and critical levels for the jitter of the sys.peer (or pps.peer), but I added -C (--candidates) Check number of backup servers that are capable of becoming peers. Range (min:max), solo number is minimum number. If you look at the output of ntpq -p, this counts the number of * and + hosts that are available. E.G in this case: remote refid st t when poll reach delay offset jitter ============================================================================== *ntp1 66.187.233.4 2 u 937 1024 377 0.393 -1.660 0.444 +ntp2 192.5.41.209 2 u 470 1024 377 9.619 4.526 1.559 +ntp3 195.66.241.10 2 u 645 1024 377 47.782 -1.140 0.382 ntp4 193.5.41.209 2 u 470 1024 377 9.619 18.526 25.559 LOCAL(0) LOCAL(0) 10 l 61 64 377 0.000 0.000 0.004 would compare 3 to the range specified by -C. This is useful for detecting peers that have lost synchronization leaving you vulnerable to a timeshift due to lack of other peers to stabilize the algorithm. Also -F (--falseticker) Check the number of falsetickers reported. Range (min:max). so -F 0:2 means I will accept up to 2 falsetickers connected to my ntp server. Good for detecting broken time sync sources. Also I implemented: -l (--last) Maximum time (seconds) between packets received from polled machines. This is compared against the "when" column in the ntpq output to look for ntp servers that are unresponsive, down, or unreachable due to network issues. If you want you can use some/all of these ideas in your check_ntp implementation. -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. From matthias.flittner at nethinks.com Fri Apr 20 11:09:06 2007 From: matthias.flittner at nethinks.com (matthias.flittner at nethinks.com) Date: Fri, 20 Apr 2007 11:09:06 +0200 Subject: [Nagiosplug-devel] [patch] check_apt Message-ID: Hello Guys, check_apt has at the moment no perfdate. So I have patched. Here the patched check_apt. -------------- next part -------------- A non-text attachment was scrubbed... Name: check_apt.patch Type: application/octet-stream Size: 14891 bytes Desc: not available URL: From matthias.flittner at nethinks.com Fri Apr 20 11:32:18 2007 From: matthias.flittner at nethinks.com (matthias.flittner at nethinks.com) Date: Fri, 20 Apr 2007 11:32:18 +0200 Subject: [Nagiosplug-devel] [patch] check_log Message-ID: Hallo, The plugin check_log doesn't return perfdata. So I have fixed it. Here is the fixed file..... Regards, Flitti -------------- next part -------------- A non-text attachment was scrubbed... Name: check_log Type: application/octet-stream Size: 6095 bytes Desc: not available URL: From noreply at sourceforge.net Fri Apr 20 19:26:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Apr 2007 10:26:21 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1667488 ] check_dhcp: server identifier(54) as offerer/siaddr Message-ID: Patches item #1667488, was opened at 2007-02-23 22:54 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1667488&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: denis knauf (deac-) Assigned to: Holger Weiss (hweiss) Summary: check_dhcp: server identifier(54) as offerer/siaddr Initial Comment: check_dhcp doesn't use server identifier (54) as server (siaddr), but this is the real serveraddresse. source is only the address of the relay-dhcp (giaddr). this patch adds the server_identifier as siaddr. btw. please "ident" your code. it's so terrible to patch this files, if somebody wrotes such unreadable code. thanks. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-04-20 19:26 Message: Logged In: YES user_id=759506 Originator: NO JFTR, the plugin does not use 'giaddr' as the server address, it uses 'siaddr', which however also isn't (necessarily) correct: | DHCP clarifies the interpretation of the 'siaddr' field as the | address of the server to use in the next step of the client's | bootstrap process. A DHCP server may return its own address in the | 'siaddr' field, if the server is prepared to supply the next | bootstrap service (e.g., delivery of an operating system executable | image). A DHCP server always returns its own address in the 'server | identifier' option. [ ftp://ftp.fu-berlin.de/doc/rfc/rfc2131.txt ] So, you're right, we should use the 'server identifier' option instead. I committed your patch (slightly modified) to CVS. Dankesch?n, Holger ---------------------------------------------------------------------- Comment By: denis knauf (deac-) Date: 2007-04-18 14:26 Message: Logged In: YES user_id=608083 Originator: YES if nothing happens, everybody thinks, the project is dead. my patch we (fachhochschule koeln - netzwerkzentrum/university of applied siences cologne - network operations center) use productive. we are highliy interested, that this patch is officially in nagios-plugins. and i'm interested in a clean coding standard. for example this: indent -nbfde -nbfda -npsl -nbad -bap -br -nce -bli0 -ncdw -ut -l80 -i4 -ts4 -cbi0 -nss -pcs -cs -bs -saf -sai -saw -nbc -brs -bls -ppi4 -ci8 -nlp i had to indent all the code to understand this program and patch one. then i had to backport it to unclean code. this had taken many time. ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-04-18 13:59 Message: Logged In: YES user_id=759506 Originator: NO 1) We're all doing this on a voluntary basis. 2) Looking into a patch (that is, understanding it, testing it, making sure that it does the right thing[tm], that it's portable, that it doesn't introduce subtle side effects, and so on) takes time. 3) Adding such comments and increasing the tracker item priority *without* an apparent reason generally won't speed things up. 4) Although I personally prefer other styles of indentation than the one used in check_dhcp.c (but that's just a matter of taste), the critical point is to be *consistent* with your indentation, which check_dhcp.c *is*. As a side note, it would be nice to have a consistent indentation style across *all* plugins, which we currently haven't. However, changing indentation style has the *big* drawback that it makes cvs diffs which cross the indentation change unreadable. 5) When contributing patches, it is generally considered bad style to break such consistency and/or to include changes other than the actual fix/feature within the same diff. 6) However, thank you for your patch. ---------------------------------------------------------------------- Comment By: denis knauf (deac-) Date: 2007-04-18 11:16 Message: Logged In: YES user_id=608083 Originator: YES how much time you need to submit this patch to cvs? i don't understand, that the nagios-plugins-project is so slow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1667488&group_id=29880 From noreply at sourceforge.net Fri Apr 20 21:21:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Apr 2007 12:21:15 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1614168 ] 1.4.5 - not compatible w/ OpenSSL 0.9.8d Message-ID: Bugs item #1614168, was opened at 2006-12-12 12:40 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1614168&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: Release (specify) >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: alexus (a1exus) >Assigned to: Thomas Guyot (dermoth) Summary: 1.4.5 - not compatible w/ OpenSSL 0.9.8d Initial Comment: gmake[2]: Entering directory `/home/install/nagios/nagios-plugins-1.4.5/plugins' /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -L. -L/usr/local/ssl/lib -o check_http check_http.o sslutils.o netutils.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -lnsl -lresolv -lssl -lcrypto gcc -g -O2 -o check_http check_http.o sslutils.o netutils.o utils.o -L/home/install/nagios/nagios-plugins-1.4.5/plugins -L/usr/local/ssl/lib ../lib/libnagiosplug.a ../lib/libcoreutils.a -lnsl -lresolv -lssl -lcrypto /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x38): In function `dlfcn_load': : undefined reference to `dlopen' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0xa0): In function `dlfcn_load': : undefined reference to `dlclose' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0xc9): In function `dlfcn_load': : undefined reference to `dlerror' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x13e): In function `dlfcn_unload': : undefined reference to `dlclose' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x1f5): In function `dlfcn_bind_var': : undefined reference to `dlsym' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x241): In function `dlfcn_bind_var': : undefined reference to `dlerror' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x2d5): In function `dlfcn_bind_func': : undefined reference to `dlsym' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x321): In function `dlfcn_bind_func': : undefined reference to `dlerror' collect2: ld returned 1 exit status gmake[2]: *** [check_http] Error 1 gmake[2]: Leaving directory `/home/install/nagios/nagios-plugins-1.4.5/plugins' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/install/nagios/nagios-plugins-1.4.5' gmake: *** [all] Error 2 [root at localhost nagios-plugins-1.4.5]# ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2007-04-20 15:21 Message: Logged In: YES user_id=375623 Originator: NO I just realized my prod servers are all using openssl-0.9.8d and I I never had any trouble compiling OpenSSL (I compiled 1.4.6 to .8 on them and possibly 1.4.5 as well) Also: $ strings /usr/lib/libcrypto.a|grep dlopen dlopen I'm setting this bug to pending. Unless you can reproduce it on the latest release and provide me with more details on your distribution and where your ssl libraries came from this bug report will be closed. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1614168&group_id=29880 From dermoth at aei.ca Sun Apr 22 16:24:13 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Sun, 22 Apr 2007 10:24:13 -0400 Subject: [Nagiosplug-devel] Feature Request: Check_cluster2 In-Reply-To: <461FA33A.1010004@mailing.kaufland-informationssysteme.com> References: <288245630704100646l762868a3s63c8864f81ae5563@mail.gmail.com> <461BE318.6040904@aei.ca> <461CAC2A.8030509@mailing.kaufland-informationssysteme.com> <461DC03C.6010004@aei.ca> <288245630704120149k311a362bj52eef88f93eba20a@mail.gmail.com><461E1D12.6020704@aei.ca> <461E46E1.5050400@mailing.kaufland-informationssysteme.com><804160344192334BB21922E8082EA6C074F9E9@seaex01.180solutions.com> <461F8730.1010204@mailing.kaufland-informationssysteme.com> <804160344192334BB21922E8082EA6C07979EF@seaex01.180solutions.com> <461FA33A.1010004@mailing.kaufland-informationssysteme.com> Message-ID: <462B700D.7040501@aei.ca> On 13/04/07 11:35 AM, Matthias Eble wrote: >>> Are you going to implement the range stuff? >> Like you want. I could likely do it tonight... > > please do it. I'll do it offline for training purposes.. i probably > won't get it before my journey.. I will make t/check_cluster.t > then and check it in tonight.. Hi Matthias, Are you still working on check_cluster.t? Thomas From ton.voon at altinity.com Mon Apr 23 18:25:23 2007 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 23 Apr 2007 17:25:23 +0100 Subject: [Nagiosplug-devel] Integrating Nagios::Plugin into the distribution Message-ID: Hi! I promised to start this discussion, so apologies for not doing it earlier. I think Nagios::Plugin is at a state where it is good enough to start using for the plugins in distribution. The main question is: how? The current utils.pm has problems because of the parsing of the location of this module. We want to fix this so it is not an issue with N::P. If N::P is installed in the perl system libraries, no paths need changing. If N::P is installed elsewhere, the perl plugins need to know where to find N::P. I think it comes down to two choices: 1. Expect N::P to be installed from an external mechanism, either manually installed via CPAN, or using a OS specific package. We'd have to make sure the Nagios Plugins requires these packages (amend various spec files, update REQUIREMENTS file, etc) 2. Install N::P (and other dependent perl modules) in a (./configure chosen) location. (1) is easier, though it pushes responsibility onto packagers. As N::P and the perl scripts in Nagios Plugins are updated, there is a dependency on packagers to make the newer version available for us to require on. (2) is harder, though we would have control over what versions are recommended. Ideally we need to support both, so that packagers can include only the minimum software required for Nagios Plugins, but a "direct install" case will still work for most users. My proposal is this: ./configure has two new options: --enable-local-perl-modules, -- disable-local-perl-modules. The default is to search for N::P and enable if not found or disable if found. --disable-local-perl-modules does nothing beyond current --enable-local-perl-modules will install N::P from a new top level subdirectory I'm calling "nanocpan". In this directory is the tar file from CPAN for N::P plus all the dependent perl modules. At make time, a "perl Makefile.PL PREFIX=$prefix" (and some other options that I'm not too sure of right now) and "make" will be run to compile all the required perl modules - this will be recursive, so other dependent perl modules will be included. At make install time, those perl modules will be installed into, say, $prefix/lib. All perl scripts that require N::P will have 'use FindBin qw($Bin); use lib "$Bin/../lib"; use Nagios::Plugin'. This means that the script will expect to find N::P in $prefix/lib - unfortunately there is a limitation that the libexec/ directory needs to reside in the same dir as lib/. If N::P is not installed in $prefix/lib, then the standard perl system libraries will be searched. If they aren't found there, then the script should fail (return code 2 on my perl 5.8.4). As newer versions of N::P are developed, we can include them in the nagiosplug distribution. If more dependent plugins are needed, those could just be dropped into the nanocpan/ directory. So I think the work is: a) amend configure scripts b) develop some "nanocpan" system where a directory holds all the possible perl modules that may be needed c) develop some "nanocpan-install" script where it installs a specified perl module (in our case, N::P) and recursively installs dependent ones if required (hopefully, this will be similar to already developed CPAN code) d) amend existing perl scripts to expect N::P in $Bin/../lib I'm not aware of anything like (b) and (c), but would welcome enlightenment if there is. Otherwise I can see a "nanocpan" system being useful for other projects besides Nagios Plugins, that we can contribute back to the perl community. Opinions? BTW, if you have any doubts about why we should use perl modules, can I point you to this lightning talk presentation I gave at FOSDEM in Feburary: http://nagiosplugins.org/index.php? option=com_docman&task=cat_view&gid=28&Itemid=28 Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Mon Apr 23 21:02:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Apr 2007 12:02:58 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1703759 ] Unnecessary ${SHELL} in INSTALL_STRIP_PROGRAM options Message-ID: Bugs item #1703759, was opened at 2007-04-19 17:27 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1703759&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: Pending Resolution: None Priority: 5 Private: No Submitted By: Nico Kadel-Garcia (nkadelgarcia) >Assigned to: Ton Voon (tonvoon) Summary: Unnecessary ${SHELL} in INSTALL_STRIP_PROGRAM options Initial Comment: The presence in configure and configure.in of the unnecessary %{SHELL} means that attempts to use /usr/bin/install instead of install-sh fail miserably, and for no valid reason. The patch is below: diff -ur nagios-plugins-1.4.8/aclocal.m4 nagios-plugins-1.4.8.chmod/aclocal.m4 --- nagios-plugins-1.4.8/aclocal.m4 2007-04-11 08:11:58.000000000 -0400 +++ nagios-plugins-1.4.8.chmod/aclocal.m4 2007-04-19 11:07:41.000000000 -0400 @@ -7158,7 +7158,7 @@ if test "$cross_compiling" != no; then AC_CHECK_TOOL([STRIP], [strip], :) fi -INSTALL_STRIP_PROGRAM="\${SHELL} \$(install_sh) -c -s" +INSTALL_STRIP_PROGRAM="\$(install_sh) -c -s" AC_SUBST([INSTALL_STRIP_PROGRAM])]) # Check how to create a tarball. -*- Autoconf -*- diff -ur nagios-plugins-1.4.8/configure nagios-plugins-1.4.8.chmod/configure --- nagios-plugins-1.4.8/configure 2007-04-11 08:12:37.000000000 -0400 +++ nagios-plugins-1.4.8.chmod/configure 2007-04-19 11:11:31.000000000 -0400 @@ -2007,7 +2007,7 @@ fi fi -INSTALL_STRIP_PROGRAM="\${SHELL} \$(install_sh) -c -s" +INSTALL_STRIP_PROGRAM="\$(install_sh) -c -s" # We need awk for the "check" target. The system "awk" is bad on # some platforms. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2007-04-23 20:02 Message: Logged In: YES user_id=664364 Originator: NO Hi Nico, aclocal.m4 is generated by autoconf, and it looks like the section for INSTALL_STRIP_PROGRAM is outside of the control of the Nagios Plugins project. According to the information in aclocal.m4, it says: # Fortunately install-sh will honor a STRIPPROG variable, so we # always use install-sh in `make install-strip', and initialize # STRIPPROG with the value of the STRIP variable (set by the user). So it looks like install-sh is always used, but you can control the strip program by use of the STRIP env var. I've marked this call in PENDING because I don't think there's anything we can do about this. Ton ---------------------------------------------------------------------- Comment By: Nico Kadel-Garcia (nkadel) Date: 2007-04-20 01:50 Message: Logged In: YES user_id=923047 Originator: NO Dang. There are other fascinating little interactions, that interfere at least with installation as non-root users in various other ways. The DAG RPM's get around this by completely ignoring the "make install" option and doing it manually in the .spec files. It's a shame to have to do that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1703759&group_id=29880 From Thomas at zango.com Mon Apr 23 22:40:52 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Mon, 23 Apr 2007 13:40:52 -0700 Subject: [Nagiosplug-devel] Integrating Nagios::Plugin into the distribution In-Reply-To: References: Message-ID: <804160344192334BB21922E8082EA6C07DA2A1@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net > [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On > Behalf Of Ton Voon > Sent: April 23, 2007 12:25 > To: Nagios Plugin Development Mailing List > Subject: [Nagiosplug-devel] Integrating Nagios::Plugin into > the distribution > > Hi! > > I promised to start this discussion, so apologies for not > doing it earlier. > > I think Nagios::Plugin is at a state where it is good enough > to start using for the plugins in distribution. The main > question is: how? > > The current utils.pm has problems because of the parsing of > the location of this module. We want to fix this so it is not > an issue with N::P. > > If N::P is installed in the perl system libraries, no paths > need changing. If N::P is installed elsewhere, the perl > plugins need to know where to find N::P. > > I think it comes down to two choices: > > 1. Expect N::P to be installed from an external mechanism, > either manually installed via CPAN, or using a OS specific > package. We'd have to make sure the Nagios Plugins requires > these packages (amend various spec files, update REQUIREMENTS > file, etc) > > 2. Install N::P (and other dependent perl modules) in a > (./configure chosen) location. My personal preference is #2, though we may need to rename it slightly to avoid Perl complaining (AFAIK Perl complains when you have a lib with the same name in more than one INC path). The reason of this preference is that we can properly test all Perl plugins with the released version so that we'll avoid bug reports due to newer/older N::P libs and also avoid having to ask which version of N::P users have when they report bugs. IMO this will save us a lot of time in the long run. It is also simpler for the user to just "make install" (which should install the lib locally) and get everything in place and will avoid possible breakages on distro upgrades (i.e. if Perl libdir change). Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From noreply at sourceforge.net Mon Apr 23 23:41:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Apr 2007 14:41:48 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1706207 ] check_by_ssh always fails when host has a banner Message-ID: Bugs item #1706207, was opened at 2007-04-23 17:41 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=1706207&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: MurrayWilson (murraywilson) Assigned to: Nobody/Anonymous (nobody) Summary: check_by_ssh always fails when host has a banner Initial Comment: The check_by_ssh plugin Version (nagios-plugins 1.4.8) 1.41 does not properly use the -S (skip lines) argument. Any host that as a banner will ALWAYS fail. This is due to the code return the STATE_UNKNOWN code if there is any stderr output (chld_err.buflen != 0) regardless of the value of skip. This chan be fixed by changing the code in main() after the call to np_runcmd() that reads: /* UNKNOWN if output found on stderr */ if(chld_err.buflen) { printf(_("Remote command execution failed: %s\n"), chld_err.buflen ? chld_err.buf : _("Unknown error")); return STATE_UNKNOWN; } to also check the value of skip: /* UNKNOWN if output found on stderr */ if(chld_err.buflen && !skip) { printf(_("Remote command execution failed: %s\n"), chld_err.buflen ? chld_err.buf : _("Unknown error")); return STATE_UNKNOWN; } Also, the help text in print_help() indicates that the long version of -S is --skiplines. However, the logopts[] array in process_arguments() specifies that --skip (not skiplines) is the long version of -S. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1706207&group_id=29880 From ton.voon at altinity.com Mon Apr 23 23:47:48 2007 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 23 Apr 2007 22:47:48 +0100 Subject: [Nagiosplug-devel] Integrating Nagios::Plugin into the distribution In-Reply-To: <804160344192334BB21922E8082EA6C07DA2A1@seaex01.180solutions.com> References: <804160344192334BB21922E8082EA6C07DA2A1@seaex01.180solutions.com> Message-ID: <69E18066-69CB-4DD0-BD24-D927BF33015C@altinity.com> On 23 Apr 2007, at 21:40, Thomas Guyot-Sionnest wrote: >> 2. Install N::P (and other dependent perl modules) in a >> (./configure chosen) location. > > My personal preference is #2, though we may need to rename it > slightly to > avoid Perl complaining (AFAIK Perl complains when you have a lib > with the > same name in more than one INC path). Not true. You can have multiple versions of a perl module in @INC, but the first one will be used (like PATH). If you 'use lib "/path/to/ mods"', this is put at the front of @INC. I think tweaking the name would cause more problems. > The reason of this preference is that we can properly test all Perl > plugins > with the released version so that we'll avoid bug reports due to > newer/older > N::P libs and also avoid having to ask which version of N::P users > have when > they report bugs. IMO this will save us a lot of time in the long > run. It is > also simpler for the user to just "make install" (which should > install the > lib locally) and get everything in place and will avoid possible > breakages > on distro upgrades (i.e. if Perl libdir change). Agreed that there is an additional question to ask at support time. You can specify a minimum version of a module via perl ("use Nagios::Plugin 0.15;"), which should help with older versions (but won't help with newer versions that break compatibility - hopefully not very often). Consider the C case - we may check for a minimum version of a library and complain if it is too low - I'd guess we'd do something similar with N::P at configure as well as runtime. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From nagios at proy.org Tue Apr 24 00:00:29 2007 From: nagios at proy.org (Patrick Proy) Date: Tue, 24 Apr 2007 00:00:29 +0200 Subject: [Nagiosplug-devel] Integrating Nagios::Plugin into thedistribution In-Reply-To: <804160344192334BB21922E8082EA6C07DA2A1@seaex01.180solutions.com> References: <804160344192334BB21922E8082EA6C07DA2A1@seaex01.180solutions.com> Message-ID: <007101c785f2$ceb22630$880214ac@telindus.intra> Hi, As a plugin dev I think using a specific directory for Perl module will create the same problem that I had with the config.pm file : the plugin won't run on all systems without changing the include path in the plugin. The easy thing about perl standard lib directory is that the plugin doesn't have to know the system specific directory of the perl modules. I don't know about possible breakages on distro upgrades, but I think Perl should be able handle this. I had quite the same problem with the Net::SNMP library, but setting my own copy in a specific directory ended up with big problems (especially for dependancies). Patrick http://nagios.manubulon.com -----Message d'origine----- De : nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] De la part de Thomas Guyot-Sionnest Envoy? : lundi 23 avril 2007 22:41 ? : Nagios Plugin Development Mailing List Objet : Re: [Nagiosplug-devel] Integrating Nagios::Plugin into thedistribution > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net > [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On Behalf Of > Ton Voon > Sent: April 23, 2007 12:25 > To: Nagios Plugin Development Mailing List > Subject: [Nagiosplug-devel] Integrating Nagios::Plugin into the > distribution > > Hi! > > I promised to start this discussion, so apologies for not doing it > earlier. > > I think Nagios::Plugin is at a state where it is good enough to start > using for the plugins in distribution. The main question is: how? > > The current utils.pm has problems because of the parsing of the > location of this module. We want to fix this so it is not an issue > with N::P. > > If N::P is installed in the perl system libraries, no paths need > changing. If N::P is installed elsewhere, the perl plugins need to > know where to find N::P. > > I think it comes down to two choices: > > 1. Expect N::P to be installed from an external mechanism, either > manually installed via CPAN, or using a OS specific package. We'd have > to make sure the Nagios Plugins requires these packages (amend various > spec files, update REQUIREMENTS file, etc) > > 2. Install N::P (and other dependent perl modules) in a (./configure > chosen) location. My personal preference is #2, though we may need to rename it slightly to avoid Perl complaining (AFAIK Perl complains when you have a lib with the same name in more than one INC path). The reason of this preference is that we can properly test all Perl plugins with the released version so that we'll avoid bug reports due to newer/older N::P libs and also avoid having to ask which version of N::P users have when they report bugs. IMO this will save us a lot of time in the long run. It is also simpler for the user to just "make install" (which should install the lib locally) and get everything in place and will avoid possible breakages on distro upgrades (i.e. if Perl libdir change). Thomas From ton.voon at altinity.com Tue Apr 24 00:00:56 2007 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 23 Apr 2007 23:00:56 +0100 Subject: [Nagiosplug-devel] Prep for 1.4.9 Message-ID: <5CCE319E-5942-4693-91B0-B688FBCB1B9B@altinity.com> Hi! I think a 1.4.9 release is in order since Thomas fixed my mistake of the missing compiles of check_ldap, check_pgsql and check_radius. I have a few things I'd like to add in the next few days, but are low priority: - check_load to divide results by number of cpus - tinderbox_build to do run make install and make install-strip into temporary areas - floorf detection and replacement for Solaris 10 - make http://nagiosplugins.org the main site Anyone have anything else that they want to add in? I'll provisionally say next Monday as the release date. 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 Apr 24 00:02:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Apr 2007 15:02:33 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1706207 ] check_by_ssh always fails when host has a banner Message-ID: Bugs item #1706207, was opened at 2007-04-23 23:41 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1706207&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: Duplicate Priority: 5 Private: No Submitted By: MurrayWilson (murraywilson) Assigned to: Nobody/Anonymous (nobody) Summary: check_by_ssh always fails when host has a banner Initial Comment: The check_by_ssh plugin Version (nagios-plugins 1.4.8) 1.41 does not properly use the -S (skip lines) argument. Any host that as a banner will ALWAYS fail. This is due to the code return the STATE_UNKNOWN code if there is any stderr output (chld_err.buflen != 0) regardless of the value of skip. This chan be fixed by changing the code in main() after the call to np_runcmd() that reads: /* UNKNOWN if output found on stderr */ if(chld_err.buflen) { printf(_("Remote command execution failed: %s\n"), chld_err.buflen ? chld_err.buf : _("Unknown error")); return STATE_UNKNOWN; } to also check the value of skip: /* UNKNOWN if output found on stderr */ if(chld_err.buflen && !skip) { printf(_("Remote command execution failed: %s\n"), chld_err.buflen ? chld_err.buf : _("Unknown error")); return STATE_UNKNOWN; } Also, the help text in print_help() indicates that the long version of -S is --skiplines. However, the logopts[] array in process_arguments() specifies that --skip (not skiplines) is the long version of -S. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-04-24 00:02 Message: Logged In: YES user_id=759506 Originator: NO This has been reported in tracker ID 1675286 and fixed in CVS by adding the new "-E/--skip-stderr" option (next to "-S/--skip-stdout"). See the snapshot at: http://nagiosplug.sourceforge.net/snapshot/ Alternatively, you could also use the "-q" option, which suppresses non-critical output written to stderr by ssh(1) (such as banners). Thanks, Holger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1706207&group_id=29880 From Thomas at zango.com Tue Apr 24 06:10:23 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Mon, 23 Apr 2007 21:10:23 -0700 Subject: [Nagiosplug-devel] Prep for 1.4.9 References: <22bc01c785f4$fb7417a6$249ca9ce@180solutions.com> Message-ID: <804160344192334BB21922E8082EA6C026749E@seaex01.180solutions.com> Was caught as spam; resending from a real computer... -----Original Message----- From: Thomas Guyot-Sionnest Sent: Mon 23-Apr-07 18:15 To: Nagios Plugin Development Mailing List Subject: RE: [Nagiosplug-devel] Prep for 1.4.9 I got a segfault for check_ping on a asprintf (building cmd) on centos submited from the mailing list. Looks like one of the argument passed to asprintf is not properly allocated but I'm not sure which one so I'll need help (works fine on my computer). I'll post all details to the mailing list later this evening... Apart from that I'd like to add stratum check support to check_ntp. It's straightforward so I should be able to do it pretty soon. So unless you want to hurry I'd like to do it. Oh one last thing, we're still waiting for a test script for check_cluster. I'll do it if I don,t get an answer from Matthias. And should we remove the original check_cluster2? Thomas -- Sent from my phone -----Original Message----- From: "Ton Voon" To: "Nagios Plugin Development Mailing List" Sent: 23/04/07 18:02 Subject: [Nagiosplug-devel] Prep for 1.4.9 Hi! I think a 1.4.9 release is in order since Thomas fixed my mistake of the missing compiles of check_ldap, check_pgsql and check_radius. I have a few things I'd like to add in the next few days, but are low priority: - check_load to divide results by number of cpus - tinderbox_build to do run make install and make install-strip into temporary areas - floorf detection and replacement for Solaris 10 - make http://nagiosplugins.org the main site Anyone have anything else that they want to add in? I'll provisionally say next Monday as the release date. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________________ Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel ::: Please include plugins version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null -------------- next part -------------- An HTML attachment was scrubbed... URL: From dermoth at aei.ca Tue Apr 24 06:28:00 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 24 Apr 2007 00:28:00 -0400 Subject: [Nagiosplug-devel] Segfault in check_ping (need help fixing) Message-ID: <462D8750.7040109@aei.ca> Yesterday I assisted sb in a Nagios upgrade and the newer version of check_ping was segfaulting. It happens in a strlen done internally by asprintf on line 128. My guess is that something passed to asprintf is not initialized properly but I'm not sure which one. The guilty line is: #ifdef PING_PACKETS_FIRST # ifdef PING_HAS_TIMEOUT asprintf (&cmd, rawcmd, timeout_interval, max_packets, addresses[i]); # else My two guesses are: 1) cmd == NULL. In some plugins I saw things such as output = strdup (""); [...] asprintf (&output, ... Is this the RightThing(tm) to do? Could it be the cause? 2) mallos/realloc's char **addresses = NULL; [...] addresses = malloc (sizeof(char*) * max_addr); [...] addresses = realloc (addresses, sizeof(char*) * max_addr); I understand the concept of malloc/realloc but when it comes to fancy sizes I always get lost in pointers. Anyone skilled enough could verify that these alloc enough memory? Since I cannot reproduce the segfault I can't test it, and the user reporting this left. More details here: http://www.pastebin.ca/453823 Thanks Thomas From Thomas at zango.com Tue Apr 24 17:39:40 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Tue, 24 Apr 2007 08:39:40 -0700 Subject: [Nagiosplug-devel] Integrating Nagios::Plugin intothedistribution In-Reply-To: <007101c785f2$ceb22630$880214ac@telindus.intra> References: <804160344192334BB21922E8082EA6C07DA2A1@seaex01.180solutions.com> <007101c785f2$ceb22630$880214ac@telindus.intra> Message-ID: <804160344192334BB21922E8082EA6C07DA3F3@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net > [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On > Behalf Of Patrick Proy > Sent: April 23, 2007 18:00 > To: 'Nagios Plugin Development Mailing List' > Subject: Re: [Nagiosplug-devel] Integrating Nagios::Plugin > intothedistribution > > Hi, > > As a plugin dev I think using a specific directory for Perl > module will > create the same problem that I had with the config.pm file : > the plugin > won't run on all systems without changing the include path in > the plugin. I don't think that's an issue as you'll always be able to install Nagios::Plugin system wide. This will only affect plugins installed by the Nagios-plugins package and will ensure good QA over what we distribute. Ton is right, Perl doesn't complain (Anymore? Because I recall seeing warning on duplicate libs in the past). So both can be installed. > I had quite the same problem with the Net::SNMP library, but > setting my own > copy in a specific directory ended up with big problems > (especially for > dependancies). We could install N::P depedencies there as well. Again this won't affect custom plugins they will use system-wide libs. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From rouilj at cs.umb.edu Tue Apr 24 19:14:17 2007 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Tue, 24 Apr 2007 13:14:17 -0400 Subject: [Nagiosplug-devel] Integrating Nagios::Plugin intothedistribution In-Reply-To: Your message of "Tue, 24 Apr 2007 08:39:40 PDT." <804160344192334BB21922E8082EA6C07DA3F3@seaex01.180solutions.com> Message-ID: <200704241714.l3OHEHZ5011398@mx1.cs.umb.edu> In message <804160344192334BB21922E8082EA6C07DA3F3 at seaex01.180solutions.com>, "Thomas Guyot-Sionnest" writes: >> [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On >> Behalf Of Patrick Proy >> As a plugin dev I think using a specific directory for Perl >> module will >> create the same problem that I had with the config.pm file : >> the plugin >> won't run on all systems without changing the include path in >> the plugin. > >I don't think that's an issue as you'll always be able to install >Nagios::Plugin system wide. This will only affect plugins installed by the >Nagios-plugins package and will ensure good QA over what we distribute. Well maybe. I have had to do installs for some customers where you can't by policy add files to the normal perl include paths. So having it be able to look in the nagios plugin tree by default for N::P would be a requirement at those shops. -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. From ton.voon at altinity.com Wed Apr 25 10:32:38 2007 From: ton.voon at altinity.com (Ton Voon) Date: Wed, 25 Apr 2007 09:32:38 +0100 Subject: [Nagiosplug-devel] Integrating Nagios::Plugin into the distribution In-Reply-To: <200704241714.l3OHEHZ5011398@mx1.cs.umb.edu> References: <200704241714.l3OHEHZ5011398@mx1.cs.umb.edu> Message-ID: On 24 Apr 2007, at 18:14, John P. Rouillard wrote: > > In message > <804160344192334BB21922E8082EA6C07DA3F3 at seaex01.180solutions.com>, > "Thomas Guyot-Sionnest" writes: >>> [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On >>> Behalf Of Patrick Proy >>> As a plugin dev I think using a specific directory for Perl >>> module will >>> create the same problem that I had with the config.pm file : >>> the plugin >>> won't run on all systems without changing the include path in >>> the plugin. >> >> I don't think that's an issue as you'll always be able to install >> Nagios::Plugin system wide. This will only affect plugins >> installed by the >> Nagios-plugins package and will ensure good QA over what we >> distribute. > > Well maybe. I have had to do installs for some customers where you > can't by policy add files to the normal perl include paths. So having > it be able to look in the nagios plugin tree by default for N::P would > be a requirement at those shops. Just to reinforce: The idea is that the perl scripts distributed with Nagios Plugins will have the following lines at the top: use FindBin qw($Bin); use lib "$Bin/../lib"; use Nagios::Plugin; This means that: 1) @INC is prefixed with $Bin/../lib, thus pointing to a Nagios Plugins specific directory. $Bin is the directory where the plugin is run from 2) Nagios::Plugin, with dependencies if required, is optionally installed in $Bin/../lib (which would be, by default, /usr/local/ nagios/lib) 3) Nagios::Plugin is sourced from $Bin/../lib or system directories To distribute plugins to target hosts, you will need the plugins in libexec/ and also the contents of lib/ (which also makes sense if we decide to have a dynamically linked C library in future). I can see two potential issues: 1) if root_dir is the top level, plugins have to exist in a lower directory (say, libexec/) and the perl modules have to live in a subdir too (say, lib/). You can't move the plugins into libexec/ local/ and expect them to work 2) I'm not sure what happens with old versions of perl. Thomas thinks there may be @INC warnings, or there could be restrictions in the perl module dependency chain BTW, this is not an intention to rewrite the C plugins - there is a need for C plugins, especially for the lower level system libraries. I believe N::P will lead to faster development of custom plugins. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From benoit.mortier at opensides.be Wed Apr 25 13:19:51 2007 From: benoit.mortier at opensides.be (Benoit Mortier) Date: Wed, 25 Apr 2007 13:19:51 +0200 Subject: [Nagiosplug-devel] CALL FOR PAPERS : The monitoring day at the rmll 2007 Amiens France Message-ID: <200704251319.53494.benoit.mortier@opensides.be> Hello, This Year at the rmll 2007 there is a Monitoring day the 12 july 200 For the people who don't know it, the RMLL are the "LIBRE SOFTWARE MEETING", they are organized each year in a different french city. For 4 days people share knowledge, discuss with other people, look for technical achievement, listen to speakers in various topics in a cool and friendly way. Those 4 days are free to attend for everybody. the website is at http://www.rmll.info/?lang=en I already have the nareto project and oreon project who's going to speak Everybody is invited to take part and we are happy if we would get flooded by as many Papers as possible to make an even better ?as last year :). Have a nice day -- Benoit Mortier CEO www.opensides.be Contributor to Gosa Project : http://gosa.gonicus.de/ Contributeur to Nagios Plugins : http://nagiosplug.sourceforge.net/ From ton.voon at altinity.com Thu Apr 26 00:14:59 2007 From: ton.voon at altinity.com (Ton Voon) Date: Wed, 25 Apr 2007 23:14:59 +0100 Subject: [Nagiosplug-devel] Patch to check_load to cater for multiple CPUs In-Reply-To: <20070417085509.GM161803@CIS.FU-Berlin.DE> References: <36282BFE-6468-4386-A060-646072A75A48@altinity.com> <20070417085509.GM161803@CIS.FU-Berlin.DE> Message-ID: <9167A5A8-B568-4DBA-A4E7-EB08ED78B1F3@altinity.com> On 17 Apr 2007, at 09:55, Holger Weiss wrote: > sysconf(3) is POSIX.1 and should be very portable, but > _SC_NPROCESSORS_CONF isn't, at least NetBSD and IRIX don't know it > (IRIX > knows _SC_NPROC_CONF, I'm not aware of an equivalent on NetBSD). So > yes, we should add an Autoconf check. > Thanks for the advice. I've applied a change now for _SC_NPROCESSORS_CONF with autoconf check, and if it is not available, but I haven't looked into _SC_NPROC_CONF, but that could be easily added. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From ton.voon at altinity.com Thu Apr 26 00:24:26 2007 From: ton.voon at altinity.com (Ton Voon) Date: Wed, 25 Apr 2007 23:24:26 +0100 Subject: [Nagiosplug-devel] Tinderbox tests to include install? In-Reply-To: <20070326112016.GQ44795887@CIS.FU-Berlin.DE> References: <57E08680-71E1-4096-BA52-CA17CDA92DAF@altinity.com> <20070326112016.GQ44795887@CIS.FU-Berlin.DE> Message-ID: <53AA9F2D-D01E-4642-8FC9-18A2CF5C2607@altinity.com> On 26 Mar 2007, at 12:20, Holger Weiss wrote: > * Ton Voon [2007-03-25 15:32]: >> The 1.4.6 release raised quite a few emails re: the po/Makefile.in >> problem on fedora. I was thinking of a "make install DESTDIR=/tmp/ >> np_build.$$" to prove that the plugins are being installed correctly. >> Of course, we'd delete the directory afterwards.... >> >> Is this a good idea? If so, would current build owners object to this >> being done? > > I wouldn't - good idea, IMO. OK - done. Let's see if this shows any useful info. I've also thought that we probably need to keep a list of plugins that get installed each time, so that if this list of plugins gets smaller maybe the configure script has a problem. This may require some admin, so I'm still mulling it over... Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From gavin at openfusion.com.au Fri Apr 27 12:06:04 2007 From: gavin at openfusion.com.au (Gavin Carr) Date: Fri, 27 Apr 2007 20:06:04 +1000 Subject: [Nagiosplug-devel] Integrating Nagios::Plugin into the distribution In-Reply-To: References: Message-ID: <20070427100604.GA11042@openfusion.com.au> Hi Ton, Sorry for the late response to this thread - been out of town for a bit. On Mon, Apr 23, 2007 at 05:25:23PM +0100, Ton Voon wrote: > I think Nagios::Plugin is at a state where it is good enough to start > using for the plugins in distribution. The main question is: how? > > The current utils.pm has problems because of the parsing of the > location of this module. We want to fix this so it is not an issue > with N::P. > > If N::P is installed in the perl system libraries, no paths need > changing. If N::P is installed elsewhere, the perl plugins need to > know where to find N::P. > > I think it comes down to two choices: > > 1. Expect N::P to be installed from an external mechanism, either > manually installed via CPAN, or using a OS specific package. We'd > have to make sure the Nagios Plugins requires these packages (amend > various spec files, update REQUIREMENTS file, etc) > > 2. Install N::P (and other dependent perl modules) in a (./configure > chosen) location. > > (1) is easier, though it pushes responsibility onto packagers. As > N::P and the perl scripts in Nagios Plugins are updated, there is a > dependency on packagers to make the newer version available for us to > require on. > > (2) is harder, though we would have control over what versions are > recommended. > > Ideally we need to support both, so that packagers can include only > the minimum software required for Nagios Plugins, but a "direct > install" case will still work for most users. I really see two separate issues here: a. Do we bundle Nagios::Plugin (and dependent modules) with the standard tarball, and support its installation from there, or do we just do external installation via CPAN or an OS package? b. Do we install Nagios::Plugin to the standard perl library directories, or do we allow and support installation elsewhere (e.g. to a local nagios tree)? It sounds like there's a reasonable consensus on (a) that we do want to bundle N::P. This needs something like your nanocpan, and presumably a reasonably test suite for the perl plugins to ensure that the set of modules we're snapshotting do play nicely together. I'm not sure a good case has been made for (b) yet - to play devil's advocate, why don't we just mandate that N::P and friends, if installed directly, always get installed to the standard perl lib tree? This makes the whole search problem go away. Is there a good case for doing anything else? (I did see John R's comment on site policy that _prevents_ modules being installed to standard perl lib locations, so that's one possible argument. Although that policy just seems too weird to me.) I'll comment separately on the other specifics separately, but wanted to clarify the requirement for (b) first. Cheers, Gavin From ton.voon at altinity.com Fri Apr 27 14:05:51 2007 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 27 Apr 2007 13:05:51 +0100 Subject: [Nagiosplug-devel] Integrating Nagios::Plugin into the distribution In-Reply-To: <20070427100604.GA11042@openfusion.com.au> References: <20070427100604.GA11042@openfusion.com.au> Message-ID: <0560541C-5BA4-4007-8ECF-36C853B63C1A@altinity.com> On 27 Apr 2007, at 11:06, Gavin Carr wrote: > I really see two separate issues here: > > a. Do we bundle Nagios::Plugin (and dependent modules) with the > standard tarball, and support its installation from there, or > do we just do external installation via CPAN or an OS package? We bundle the tar gz files for N::P and dependent modules with the distribution in, say, perl-mods/. I've been looking at Krang, which bundles the perl tarballs with their code (http://www.krangcms.com/docs/building_perl_modules.html). As an aside, they check the individual licences permits them to re- distribute - we should check that too. People that want CPAN or OS packages are free to install themselves. In which case, the configure script would disable the local install if N::P is found in system dir with sufficient version. > b. Do we install Nagios::Plugin to the standard perl library > directories, or do we allow and support installation elsewhere > (e.g. to a local nagios tree)? We always install into a nagios tree, say, /usr/local/nagios/lib. We don't support installation into system dirs - use CPAN or do it manually if you want that (okay, that's probably a bit harsh - I guess we could provide a configure flag, but it is not a priority). If a user decides to install from CPAN or OS packages, obviously that would be placed in system directories. > It sounds like there's a reasonable consensus on (a) that we do > want to bundle N::P. This needs something like your nanocpan, and > presumably a reasonably test suite for the perl plugins to ensure > that the set of modules we're snapshotting do play nicely together. I'm thinking that the nanocpan is going to be based on Krang's techniques. I'd like to make nanocpan generalised so that it can be used outside of Nagios Plugins and can be given back to the perl community. I don't think any additional test suites are required, right? As long as N::P's test suite pass, then the dependent stuff has done its job. The beauty about the snapshoting is that we know for this specific combination of perl modules, N::P will work (because we'd also be running tinderbox builds daily to prove it too). > I'm not sure a good case has been made for (b) yet - to play devil's > advocate, why don't we just mandate that N::P and friends, if > installed directly, always get installed to the standard perl lib > tree? This makes the whole search problem go away. Is there a good > case for doing anything else? I haven't found the search path to be a problem. I guess lower versions of perl may pose a problem - I don't have a handle on this yet. There may need to be some extra work done there to support those lower levels. Installing into system directories affects other people's code. I'd rather not be responsible :) Yes, there's potentially duplication of perl modules. But packagers can tune things so that nagios plugins are installed without the perl modules and they set dependencies for N::P externally. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From Thomas at zango.com Fri Apr 27 15:08:57 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Fri, 27 Apr 2007 06:08:57 -0700 Subject: [Nagiosplug-devel] Integrating Nagios::Plugin into thedistribution In-Reply-To: <0560541C-5BA4-4007-8ECF-36C853B63C1A@altinity.com> References: <20070427100604.GA11042@openfusion.com.au> <0560541C-5BA4-4007-8ECF-36C853B63C1A@altinity.com> Message-ID: <804160344192334BB21922E8082EA6C07DAA33@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net > [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On > Behalf Of Ton Voon > Sent: April 27, 2007 8:06 > To: Nagios Plugin Development Mailing List > Subject: Re: [Nagiosplug-devel] Integrating Nagios::Plugin > into thedistribution > > [...] > > People that want CPAN or OS packages are free to install themselves. > In which case, the configure script would disable the local install > if N::P is found in system dir with sufficient version. I'd rather install it no matter which local version is installed. The local version can be upgraded or downgraded... Also newer versions could possibly contains bugs that are not in any of the distributed Nagios-plugins. The cost is very little, some extra code in a local folder, and it give us much more control over what libraries our plugins are using. I'm not against having configure arguments to use the system N::P and dependent libs however, but I believe this shouldn't be the default. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From gavin at marigoldtech.com Sat Apr 28 14:25:58 2007 From: gavin at marigoldtech.com (Gavin Carr) Date: Sat, 28 Apr 2007 22:25:58 +1000 Subject: [Nagiosplug-devel] Integrating Nagios::Plugin into the distribution In-Reply-To: <0560541C-5BA4-4007-8ECF-36C853B63C1A@altinity.com> References: <20070427100604.GA11042@openfusion.com.au> <0560541C-5BA4-4007-8ECF-36C853B63C1A@altinity.com> Message-ID: <20070428122558.GA14578@openfusion.com.au> On Fri, Apr 27, 2007 at 01:05:51PM +0100, Ton Voon wrote: > On 27 Apr 2007, at 11:06, Gavin Carr wrote: > > b. Do we install Nagios::Plugin to the standard perl library > > directories, or do we allow and support installation elsewhere > > (e.g. to a local nagios tree)? > > We always install into a nagios tree, say, /usr/local/nagios/lib. We > don't support installation into system dirs - use CPAN or do it > manually if you want that (okay, that's probably a bit harsh - I > guess we could provide a configure flag, but it is not a priority). Why? What's the advantage of not using the standard perl library locations? N::P and every other module you're installing _are_ standard CPAN modules, that out-of-the-box (perl Makefile.PL; make; make install) install into the perl lib directories. You're having to jump through extra hoops for them to _not_ install there, and then jump through more hoops for your plugins to work because they aren't there. I don't understand the rational/benefit of all that extra hoopage? I guess I'm seeing the benefit of bundling being not having to jump through setting up the CPAN configuration stuff on every box you want to use N::P on. It sounds like you're seeing the isolation itself as being a benefit? > If a user decides to install from CPAN or OS packages, obviously that > would be placed in system directories. > > It sounds like there's a reasonable consensus on (a) that we do > > want to bundle N::P. This needs something like your nanocpan, and > > presumably a reasonably test suite for the perl plugins to ensure > > that the set of modules we're snapshotting do play nicely together. > > I'm thinking that the nanocpan is going to be based on Krang's > techniques. I'd like to make nanocpan generalised so that it can be > used outside of Nagios Plugins and can be given back to the perl > community. > > I don't think any additional test suites are required, right? As long > as N::P's test suite pass, then the dependent stuff has done its job. I guess that's right. I was thinking we should be testing the end-plugins themselves too, but if the N::P tests are comprehensive enough, we should be covering that off. > The beauty about the snapshoting is that we know for this specific > combination of perl modules, N::P will work (because we'd also be > running tinderbox builds daily to prove it too). > > > I'm not sure a good case has been made for (b) yet - to play devil's > > advocate, why don't we just mandate that N::P and friends, if > > installed directly, always get installed to the standard perl lib > > tree? This makes the whole search problem go away. Is there a good > > case for doing anything else? > > I haven't found the search path to be a problem. I guess lower > versions of perl may pose a problem - I don't have a handle on this > yet. There may need to be some extra work done there to support those > lower levels. It's just a problem in the sense that the plugins won't work without some explicit lib path tweaking. I dislike your FindBin/use lib code on the grounds that it's only required to support a particular deployment decision - you're polluting the plugins with installation policy. (It would be much cleaner, for instance, to see if we can just get PERL5LIB set in the environment if we do go this way). > Installing into system directories affects other people's code. I'd > rather not be responsible :) You're not - it was whoever pressed that install key. ;-) Okay, so you're seeing the whole separate-install thing as a feature, isolating you from screwing up (or being screwed up) someone else's libraries? I guess I'm seeing that risk as relatively small, especially given the modest set of dependencies we have. I'm much more suspicious of the duplication problem. If you end up having multiple versions of the same modules in different locations, you're going to be prone to all kinds of weird problems if you're not careful. Simple example: imagine an N::P from CPAN and a different N::P installed in /usr/local/nagios, and home-grown or third-party perl plugins behaving in very confusing ways dependent on which way the lib path is set up ... Cheers, Gavin From dermoth at aei.ca Sat Apr 28 17:58:47 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Sat, 28 Apr 2007 11:58:47 -0400 Subject: [Nagiosplug-devel] Integrating Nagios::Plugin into the distribution In-Reply-To: <20070428122558.GA14578@openfusion.com.au> References: <20070427100604.GA11042@openfusion.com.au> <0560541C-5BA4-4007-8ECF-36C853B63C1A@altinity.com> <20070428122558.GA14578@openfusion.com.au> Message-ID: <46336F37.3030404@aei.ca> On 28/04/07 08:25 AM, Gavin Carr wrote: > On Fri, Apr 27, 2007 at 01:05:51PM +0100, Ton Voon wrote: > >> Installing into system directories affects other people's code. I'd >> rather not be responsible :) > > You're not - it was whoever pressed that install key. ;-) > > Okay, so you're seeing the whole separate-install thing as a feature, > isolating you from screwing up (or being screwed up) someone else's > libraries? > > I guess I'm seeing that risk as relatively small, especially given the > modest set of dependencies we have. I'm much more suspicious of the > duplication problem. If you end up having multiple versions of the same > modules in different locations, you're going to be prone to all kinds > of weird problems if you're not careful. Simple example: imagine an > N::P from CPAN and a different N::P installed in /usr/local/nagios, and > home-grown or third-party perl plugins behaving in very confusing > ways dependent on which way the lib path is set up ... Have you read my arguments on this? I believe that changes in the CPAN libs should not affect Nagios-plugins and vice-versa. The two problems I see are: 1. Bugs/incompatibilities that could slip in newer version of Nagios-plugins. Since we'll be allowing newer version of N::P to be installed we could get bug reports that only affect certain combinations of packages. 2. Upgrading N::P on systems that have a too old version could possibly break existing plugins that are not part of Nagios-plugins. Some of these plugins may come from sources like Nagiosexchange and their developers might not be offering a fixed version (and not all systems admin write Perl) I don't think there's good chances of having "weird problems" if N::P is in a separate dir. Nagios-plugins Perl plugins will all have the "use lib" instruction to get the packaged N::P, while all other should use the system one (Unless the developer intended to use the local one). In either case it shouldn't be broken though. Thomas From noreply at sourceforge.net Sun Apr 29 04:20:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 Apr 2007 19:20:14 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1433179 ] check_jabber (check_tcp) does not honor --mismatch Message-ID: Bugs item #1433179, was opened at 2006-02-16 13:27 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1433179&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: BuckNaked (mnk26) Assigned to: Thomas Guyot (dermoth) Summary: check_jabber (check_tcp) does not honor --mismatch Initial Comment: expect_mismatch_state is set but is never used anywhere. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-04-28 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-04-14 07:59 Message: Logged In: YES user_id=375623 Originator: NO It does. After deliberately breaking the expect match: $ plugins/check_jabber -H jabber.org JABBER WARNING - Unexpected response from host/socket on port 5222|time=0.217635s;0.000000;0.000000;0.000000;10.000000 $ plugins/check_jabber -H jabber.org --mismatch=crit JABBER CRITICAL - Unexpected response from host/socket on port 5222|time=0.193435s;0.000000;0.000000;0.000000;10.000000 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1433179&group_id=29880 From gavin at openfusion.com.au Sun Apr 29 13:24:24 2007 From: gavin at openfusion.com.au (Gavin Carr) Date: Sun, 29 Apr 2007 21:24:24 +1000 Subject: [Nagiosplug-devel] Integrating Nagios::Plugin into the distribution In-Reply-To: <46336F37.3030404@aei.ca> References: <20070427100604.GA11042@openfusion.com.au> <0560541C-5BA4-4007-8ECF-36C853B63C1A@altinity.com> <20070428122558.GA14578@openfusion.com.au> <46336F37.3030404@aei.ca> Message-ID: <20070429112424.GA22470@openfusion.com.au> On Sat, Apr 28, 2007 at 11:58:47AM -0400, Thomas Guyot-Sionnest wrote: > On 28/04/07 08:25 AM, Gavin Carr wrote: > > On Fri, Apr 27, 2007 at 01:05:51PM +0100, Ton Voon wrote: > >> Installing into system directories affects other people's code. I'd > >> rather not be responsible :) > > > > Okay, so you're seeing the whole separate-install thing as a feature, > > isolating you from screwing up (or being screwed up) someone else's > > libraries? > > > > I guess I'm seeing that risk as relatively small, especially given the > > modest set of dependencies we have. I'm much more suspicious of the > > duplication problem. If you end up having multiple versions of the same > > modules in different locations, you're going to be prone to all kinds > > of weird problems if you're not careful. Simple example: imagine an > > N::P from CPAN and a different N::P installed in /usr/local/nagios, and > > home-grown or third-party perl plugins behaving in very confusing > > ways dependent on which way the lib path is set up ... > > Have you read my arguments on this? I believe that changes in the CPAN > libs should not affect Nagios-plugins and vice-versa. The two problems I > see are: > > 1. Bugs/incompatibilities that could slip in newer version of > Nagios-plugins. Since we'll be allowing newer version of N::P to be > installed we could get bug reports that only affect certain combinations > of packages. Sure. But it's just an extra version number to check. > 2. Upgrading N::P on systems that have a too old version could possibly > break existing plugins that are not part of Nagios-plugins. Some of > these plugins may come from sources like Nagiosexchange and their > developers might not be offering a fixed version (and not all systems > admin write Perl) Again sure, but I think this risk is pretty small. You need a non- backwards-compatible change (I don't believe we've had any so far), and one or more plugins that depend on that behaviour and aren't trivially correctable. > I don't think there's good chances of having "weird problems" if N::P is > in a separate dir. Nagios-plugins Perl plugins will all have the "use > lib" instruction to get the packaged N::P, while all other should use > the system one (unless the developer intended to use the local one). In > either case it shouldn't be broken though. I just think duplication is a bit like denormalising a database schema - it's generally bad practice, but sometimes the benefits make it worthwhile. You and Ton clearly see the benefits there; I think I'm just cautious about the potential costs too. Cheers, Gavin From matthias.eble at mailing.kaufland-informationssysteme.com Mon Apr 30 14:03:47 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Mon, 30 Apr 2007 14:03:47 +0200 Subject: [Nagiosplug-devel] Prep for 1.4.9 In-Reply-To: <804160344192334BB21922E8082EA6C026749E@seaex01.180solutions.com> References: <22bc01c785f4$fb7417a6$249ca9ce@180solutions.com> <804160344192334BB21922E8082EA6C026749E@seaex01.180solutions.com> Message-ID: <4635DB23.6050208@mailing.kaufland-informationssysteme.com> Hi all, > > Oh one last thing, we're still waiting for a test script for > check_cluster. I'll do it if I don,t get an answer from Matthias. And > should we remove the original check_cluster2? i commited the test on saturday.. all tinderbox hosts except poseidon passed 15/15 tests. poseidon shows: ./t/check_cluster....dubious Test returned status 255 (wstat 65280, 0xff00) in the log.. any suggestions? matthias