From hpsekhon at googlemail.com Wed Jan 2 14:12:30 2008 From: hpsekhon at googlemail.com (Hari Sekhon) Date: Wed, 02 Jan 2008 13:12:30 +0000 Subject: [Nagiosplug-devel] Licensing of Official and 3rd Party Plugins Message-ID: <477B8DBE.7020207@googlemail.com> Hi, I was wondering if anyone had any views on the licensing of plugins, I have looked at GPL version 3 and it looks good, really just an update to GPL version 2. So the question is, why not license plugins as GPL version 3 now? I am really asking this in 2 respects: 1. for the Official Plugins 2. for custom plugins released to Nagios Exchange. Basically it comes down to GPLv2 vs GPLv3. Has anyone considered upgrading to the official Nagios code base to the newer GPL? Should I license plugins I write as GPLv3 now instead of GPLv2? Are there any detractions in doing this? -h -- Hari Sekhon From noreply at sourceforge.net Wed Jan 2 15:49:16 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Jan 2008 06:49:16 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1862218 ] check_procs: usage2 does not expect a format string Message-ID: Bugs item #1862218, was opened at 2008-01-02 15:49 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=1862218&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: CVS Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ferenc W?gner (wferi) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs: usage2 does not expect a format string Initial Comment: Hi, See the following error message: $ /usr/lib/nagios/plugins/check_procs -u nosuchuser check_procs: User name %s was not found - nosuchuser Usage:check_procs [...] 1. The '%s' in the error message is superfluous. In CVS, it's at check_procs.c:426, with a similar buglet on line 420. The fix looks dead easy: remove '%s ' from those two lines. 2. On the next line, 'Usage:' should be followed by a space (CVS line 753). Just to make the output prettier. Regards, Feri. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862218&group_id=29880 From noreply at sourceforge.net Wed Jan 2 17:39:33 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Jan 2008 08:39:33 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1862300 ] check_ntp_time segfault in 1.4.11 Message-ID: Bugs item #1862300, was opened at 2008-01-02 11:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862300&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: digitalruin (digitalruin) Assigned to: Nobody/Anonymous (nobody) Summary: check_ntp_time segfault in 1.4.11 Initial Comment: Hi, I'm running 1.4.11 on a Solaris 9 setup and check_ntp_time seems to have a segfault issue. This only happens when running it against an ntp pool, not an individual host. See below: /usr/local/nagios/libexec$ ./check_ntp_time -H 0.us.pool.ntp.org -w 60 -c 120 Segmentation Fault /usr/local/nagios/libexec$ ./check_ntp_time -v -H 0.us.pool.ntp.org -w 60 -c 120 sending request to peer 0 sending request to peer 1 response from peer 0: offset 54.24633014 sending request to peer 0 response from peer 1: offset 54.23421776 . . . response from peer 4: offset 54.23087406 sending request to peer 4 response from peer 4: offset 54.23018897 sending request to peer 4 response from peer 4: offset 54.23138392 Segmentation Fault Here's the truss output: sending request to peer 4 write(1, " s e n d i n g r e q u".., 26) = 26 write(8, "E3\004FA\001\0\0\001\0\0".., 48) = 48 poll(0x00034298, 5, 100) = 1 read(8, " $0104ED\0\0\0\0\0\0\011".., 48) = 48 response from peer 4: offset 54.24180388 write(1, " r e s p o n s e f r o".., 41) = 41 Incurred fault #6, FLTBOUNDS %pc = 0x00015FB4 siginfo: SIGSEGV SEGV_MAPERR addr=0x7FC1E3A4 Received signal #11, SIGSEGV [default] siginfo: SIGSEGV SEGV_MAPERR addr=0x7FC1E3A4 And the traceback: /usr/local/nagios/libexec# dbx /usr/local/nagios/libexec/check_ntp_time Reading check_ntp_time Reading ld.so.1 Reading libresolv.so.2 Reading libm.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libc.so.1 Reading libdl.so.1 Reading libmp.so.2 Reading libc_psr.so.1 (dbx) run -H 0.us.pool.ntp.org -w 60 -c 120 Running: check_ntp_time -H 0.us.pool.ntp.org -w 60 -c 120 (process id 12120) signal SEGV (no mapping at the fault address) in offset_request at line 427 in file "check_ntp_time.c" (dbx) where =>[1] offset_request(host = 0x354b0 "0.us.pool.ntp.org", status = 0xffbffae4), line 427 in "check_ntp_time.c" [2] main(argc = 7, argv = 0xffbffb54), line 554 in "check_ntp_time.c" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862300&group_id=29880 From ecrist at secure-computing.net Wed Jan 2 20:20:33 2008 From: ecrist at secure-computing.net (Eric F Crist) Date: Wed, 2 Jan 2008 13:20:33 -0600 Subject: [Nagiosplug-devel] [Nagios-users] Licensing of Official and 3rd Party Plugins In-Reply-To: <477B8DBE.7020207@googlemail.com> References: <477B8DBE.7020207@googlemail.com> Message-ID: <951D2145-FCA9-47DF-AF69-B52BB7E05DF5@secure-computing.net> You can license your plugin however you choose. The plugins I write are BSD, for instance. On Jan 2, 2008, at 7:12 AM, Hari Sekhon wrote: > Hi, > > I was wondering if anyone had any views on the licensing of plugins, > I have looked at GPL version 3 and it looks good, really just an > update > to GPL version 2. > > So the question is, why not license plugins as GPL version 3 now? > I am really asking this in 2 respects: > > 1. for the Official Plugins > 2. for custom plugins released to Nagios Exchange. > > Basically it comes down to GPLv2 vs GPLv3. > > Has anyone considered upgrading to the official Nagios code base to > the > newer GPL? > > Should I license plugins I write as GPLv3 now instead of GPLv2? Are > there any detractions in doing this? > > > -h > > -- > Hari Sekhon > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Nagios-users mailing list > Nagios-users at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagios-users > ::: Please include Nagios version, plugin version (-v) and OS when > reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null ----- Eric F Crist Secure Computing Networks From hpsekhon at googlemail.com Thu Jan 3 10:47:46 2008 From: hpsekhon at googlemail.com (Hari Sekhon) Date: Thu, 03 Jan 2008 09:47:46 +0000 Subject: [Nagiosplug-devel] [Nagios-users] Licensing of Official and 3rd Party Plugins In-Reply-To: <951D2145-FCA9-47DF-AF69-B52BB7E05DF5@secure-computing.net> References: <477B8DBE.7020207@googlemail.com> <951D2145-FCA9-47DF-AF69-B52BB7E05DF5@secure-computing.net> Message-ID: <477CAF42.5050004@googlemail.com> Eric F Crist wrote: > You can license your plugin however you choose. The plugins I write > are BSD, for instance. Thanks for the reply Eric, but this wasn't really the question. Of course I license my plugins how I want, but the question is really one of GPLv2 and GPLv3. Are there any plans to upgrade the official plugin distribution to GPLv3? Are there any advantages/disadvantages to doing so? Does anyone have any opinions in licensing of 3rd party plugins as GPLv3 instead of GPLv2? -h -- Hari Sekhon From noreply at sourceforge.net Thu Jan 3 13:39:58 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Jan 2008 04:39:58 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1862300 ] check_ntp_time segfault in 1.4.11 Message-ID: Bugs item #1862300, was opened at 2008-01-02 11:39 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862300&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: digitalruin (digitalruin) Assigned to: Nobody/Anonymous (nobody) Summary: check_ntp_time segfault in 1.4.11 Initial Comment: Hi, I'm running 1.4.11 on a Solaris 9 setup and check_ntp_time seems to have a segfault issue. This only happens when running it against an ntp pool, not an individual host. See below: /usr/local/nagios/libexec$ ./check_ntp_time -H 0.us.pool.ntp.org -w 60 -c 120 Segmentation Fault /usr/local/nagios/libexec$ ./check_ntp_time -v -H 0.us.pool.ntp.org -w 60 -c 120 sending request to peer 0 sending request to peer 1 response from peer 0: offset 54.24633014 sending request to peer 0 response from peer 1: offset 54.23421776 . . . response from peer 4: offset 54.23087406 sending request to peer 4 response from peer 4: offset 54.23018897 sending request to peer 4 response from peer 4: offset 54.23138392 Segmentation Fault Here's the truss output: sending request to peer 4 write(1, " s e n d i n g r e q u".., 26) = 26 write(8, "E3\004FA\001\0\0\001\0\0".., 48) = 48 poll(0x00034298, 5, 100) = 1 read(8, " $0104ED\0\0\0\0\0\0\011".., 48) = 48 response from peer 4: offset 54.24180388 write(1, " r e s p o n s e f r o".., 41) = 41 Incurred fault #6, FLTBOUNDS %pc = 0x00015FB4 siginfo: SIGSEGV SEGV_MAPERR addr=0x7FC1E3A4 Received signal #11, SIGSEGV [default] siginfo: SIGSEGV SEGV_MAPERR addr=0x7FC1E3A4 And the traceback: /usr/local/nagios/libexec# dbx /usr/local/nagios/libexec/check_ntp_time Reading check_ntp_time Reading ld.so.1 Reading libresolv.so.2 Reading libm.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libc.so.1 Reading libdl.so.1 Reading libmp.so.2 Reading libc_psr.so.1 (dbx) run -H 0.us.pool.ntp.org -w 60 -c 120 Running: check_ntp_time -H 0.us.pool.ntp.org -w 60 -c 120 (process id 12120) signal SEGV (no mapping at the fault address) in offset_request at line 427 in file "check_ntp_time.c" (dbx) where =>[1] offset_request(host = 0x354b0 "0.us.pool.ntp.org", status = 0xffbffae4), line 427 in "check_ntp_time.c" [2] main(argc = 7, argv = 0xffbffb54), line 554 in "check_ntp_time.c" ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2008-01-03 07:39 Message: Logged In: YES user_id=375623 Originator: NO Hi, I'm the author of check_ntp_time and it's mostly based on check_ntp (written by Sean Finney). The specific place where it segfaults (offset_request function) hasn't been modified so this should apply to check_ntp.c as well. Could you confirm running check_ntp with the same arguments does the same segfault? Also I can't reproduce the bug on my Linux and Solaris boxes and FreeBSD VM. Does it happens all the time? Is it's still happening? To debug further I will need the full verbose output of the plug-in ("-vvv" instead of "-v"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862300&group_id=29880 From noreply at sourceforge.net Thu Jan 3 13:45:18 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Jan 2008 04:45:18 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1862300 ] check_ntp_time segfault in 1.4.11 Message-ID: Bugs item #1862300, was opened at 2008-01-02 11:39 Message generated for change (Settings changed) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862300&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: digitalruin (digitalruin) >Assigned to: Thomas Guyot (dermoth) Summary: check_ntp_time segfault in 1.4.11 Initial Comment: Hi, I'm running 1.4.11 on a Solaris 9 setup and check_ntp_time seems to have a segfault issue. This only happens when running it against an ntp pool, not an individual host. See below: /usr/local/nagios/libexec$ ./check_ntp_time -H 0.us.pool.ntp.org -w 60 -c 120 Segmentation Fault /usr/local/nagios/libexec$ ./check_ntp_time -v -H 0.us.pool.ntp.org -w 60 -c 120 sending request to peer 0 sending request to peer 1 response from peer 0: offset 54.24633014 sending request to peer 0 response from peer 1: offset 54.23421776 . . . response from peer 4: offset 54.23087406 sending request to peer 4 response from peer 4: offset 54.23018897 sending request to peer 4 response from peer 4: offset 54.23138392 Segmentation Fault Here's the truss output: sending request to peer 4 write(1, " s e n d i n g r e q u".., 26) = 26 write(8, "E3\004FA\001\0\0\001\0\0".., 48) = 48 poll(0x00034298, 5, 100) = 1 read(8, " $0104ED\0\0\0\0\0\0\011".., 48) = 48 response from peer 4: offset 54.24180388 write(1, " r e s p o n s e f r o".., 41) = 41 Incurred fault #6, FLTBOUNDS %pc = 0x00015FB4 siginfo: SIGSEGV SEGV_MAPERR addr=0x7FC1E3A4 Received signal #11, SIGSEGV [default] siginfo: SIGSEGV SEGV_MAPERR addr=0x7FC1E3A4 And the traceback: /usr/local/nagios/libexec# dbx /usr/local/nagios/libexec/check_ntp_time Reading check_ntp_time Reading ld.so.1 Reading libresolv.so.2 Reading libm.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libc.so.1 Reading libdl.so.1 Reading libmp.so.2 Reading libc_psr.so.1 (dbx) run -H 0.us.pool.ntp.org -w 60 -c 120 Running: check_ntp_time -H 0.us.pool.ntp.org -w 60 -c 120 (process id 12120) signal SEGV (no mapping at the fault address) in offset_request at line 427 in file "check_ntp_time.c" (dbx) where =>[1] offset_request(host = 0x354b0 "0.us.pool.ntp.org", status = 0xffbffae4), line 427 in "check_ntp_time.c" [2] main(argc = 7, argv = 0xffbffb54), line 554 in "check_ntp_time.c" ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-01-03 07:39 Message: Logged In: YES user_id=375623 Originator: NO Hi, I'm the author of check_ntp_time and it's mostly based on check_ntp (written by Sean Finney). The specific place where it segfaults (offset_request function) hasn't been modified so this should apply to check_ntp.c as well. Could you confirm running check_ntp with the same arguments does the same segfault? Also I can't reproduce the bug on my Linux and Solaris boxes and FreeBSD VM. Does it happens all the time? Is it's still happening? To debug further I will need the full verbose output of the plug-in ("-vvv" instead of "-v"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862300&group_id=29880 From noreply at sourceforge.net Thu Jan 3 17:38:32 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Jan 2008 08:38:32 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1862300 ] check_ntp_time segfault in 1.4.11 Message-ID: Bugs item #1862300, was opened at 2008-01-02 11:39 Message generated for change (Comment added) made by digitalruin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862300&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: digitalruin (digitalruin) Assigned to: Thomas Guyot (dermoth) Summary: check_ntp_time segfault in 1.4.11 Initial Comment: Hi, I'm running 1.4.11 on a Solaris 9 setup and check_ntp_time seems to have a segfault issue. This only happens when running it against an ntp pool, not an individual host. See below: /usr/local/nagios/libexec$ ./check_ntp_time -H 0.us.pool.ntp.org -w 60 -c 120 Segmentation Fault /usr/local/nagios/libexec$ ./check_ntp_time -v -H 0.us.pool.ntp.org -w 60 -c 120 sending request to peer 0 sending request to peer 1 response from peer 0: offset 54.24633014 sending request to peer 0 response from peer 1: offset 54.23421776 . . . response from peer 4: offset 54.23087406 sending request to peer 4 response from peer 4: offset 54.23018897 sending request to peer 4 response from peer 4: offset 54.23138392 Segmentation Fault Here's the truss output: sending request to peer 4 write(1, " s e n d i n g r e q u".., 26) = 26 write(8, "E3\004FA\001\0\0\001\0\0".., 48) = 48 poll(0x00034298, 5, 100) = 1 read(8, " $0104ED\0\0\0\0\0\0\011".., 48) = 48 response from peer 4: offset 54.24180388 write(1, " r e s p o n s e f r o".., 41) = 41 Incurred fault #6, FLTBOUNDS %pc = 0x00015FB4 siginfo: SIGSEGV SEGV_MAPERR addr=0x7FC1E3A4 Received signal #11, SIGSEGV [default] siginfo: SIGSEGV SEGV_MAPERR addr=0x7FC1E3A4 And the traceback: /usr/local/nagios/libexec# dbx /usr/local/nagios/libexec/check_ntp_time Reading check_ntp_time Reading ld.so.1 Reading libresolv.so.2 Reading libm.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libc.so.1 Reading libdl.so.1 Reading libmp.so.2 Reading libc_psr.so.1 (dbx) run -H 0.us.pool.ntp.org -w 60 -c 120 Running: check_ntp_time -H 0.us.pool.ntp.org -w 60 -c 120 (process id 12120) signal SEGV (no mapping at the fault address) in offset_request at line 427 in file "check_ntp_time.c" (dbx) where =>[1] offset_request(host = 0x354b0 "0.us.pool.ntp.org", status = 0xffbffae4), line 427 in "check_ntp_time.c" [2] main(argc = 7, argv = 0xffbffb54), line 554 in "check_ntp_time.c" ---------------------------------------------------------------------- >Comment By: digitalruin (digitalruin) Date: 2008-01-03 11:38 Message: Logged In: YES user_id=1609785 Originator: YES No problem. Yeah it's the same in check_ntp. I actually had it pass once without failing, but I think it was due to the server only having a two or three choices. With full verbose I can see that it segfaults when choosing the best server to go with. If it has xn it segfaults during the decision. So to simplify, no segfault when runnng the check against one ntp server. Possibly no segfault when running it against a pool that only consists of three or four. Always segfaults when hitting a large pool server like ntp.org. Here's the info... I ran it twice with both two different ntp hubs and it failed: # ./check_ntp -vvv -H 1.us.pool.ntp.org -w 60 -c 120 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377653.767585 rxts = 1199377710.512649 txts = 1199377710.512664 offset 56.70649898 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377653.850921 rxts = 1199377710.594606 txts = 1199377710.594627 offset 56.70579767 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377653.927373 rxts = 1199377710.670819 txts = 1199377710.670839 offset 56.70584822 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377654.003221 rxts = 1199377710.747487 txts = 1199377710.747508 offset 56.70499885 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.034637451171875 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.082479 rxts = 1199377710.829896 txts = 1199377710.82992 offset 56.70595193 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.034637451171875 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.166106 rxts = 1199377710.913108 txts = 1199377710.913127 offset 56.70589066 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.034637451171875 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.248994 rxts = 1199377710.996055 txts = 1199377710.996118 offset 56.70593584 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.0346527099609375 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.331923 rxts = 1199377711.078835 txts = 1199377711.078882 offset 56.70586824 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.414673 rxts = 1199377711.154322 txts = 1199377711.154334 offset 56.69950116 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.495628 rxts = 1199377711.234703 txts = 1199377711.234713 offset 56.6990782 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.576271 rxts = 1199377711.31571 txts = 1199377711.315721 offset 56.69919193 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.657396 rxts = 1199377711.396339 txts = 1199377711.39635 offset 56.69902682 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.737869 rxts = 1199377711.4489 txts = 1199377711.448967 offset 56.70623863 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.748154 rxts = 1199377711.45769 txts = 1199377711.457742 offset 56.70598435 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.755922 rxts = 1199377711.466313 txts = 1199377711.466348 offset 56.7064172 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.76451 rxts = 1199377711.473845 txts = 1199377711.47388 offset 56.70550835 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.772819 rxts = 1199377711.483832 txts = 1199377711.483859 offset 56.70550382 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.784468 rxts = 1199377711.496182 txts = 1199377711.496194 offset 56.70548892 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.797513 rxts = 1199377711.508051 txts = 1199377711.508061 offset 56.70531833 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.808561 rxts = 1199377711.522168 txts = 1199377711.52218 offset 56.70665574 best server selected: peer 1273064242 Segmentation Fault (core dumped) Here's the dbx traceback from check_ntp: =>[1] offset_request(host = 0x36aa0 "1.us.pool.ntp.org", status = 0xffbffad4), line 482 in "check_ntp.c" [2] main(argc = 6, argv = 0xffbffb44), line 778 in "check_ntp.c" ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-01-03 07:39 Message: Logged In: YES user_id=375623 Originator: NO Hi, I'm the author of check_ntp_time and it's mostly based on check_ntp (written by Sean Finney). The specific place where it segfaults (offset_request function) hasn't been modified so this should apply to check_ntp.c as well. Could you confirm running check_ntp with the same arguments does the same segfault? Also I can't reproduce the bug on my Linux and Solaris boxes and FreeBSD VM. Does it happens all the time? Is it's still happening? To debug further I will need the full verbose output of the plug-in ("-vvv" instead of "-v"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862300&group_id=29880 From noreply at sourceforge.net Thu Jan 3 17:41:48 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Jan 2008 08:41:48 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1862300 ] check_ntp_time segfault in 1.4.11 Message-ID: Bugs item #1862300, was opened at 2008-01-02 11:39 Message generated for change (Comment added) made by digitalruin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862300&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: digitalruin (digitalruin) Assigned to: Thomas Guyot (dermoth) Summary: check_ntp_time segfault in 1.4.11 Initial Comment: Hi, I'm running 1.4.11 on a Solaris 9 setup and check_ntp_time seems to have a segfault issue. This only happens when running it against an ntp pool, not an individual host. See below: /usr/local/nagios/libexec$ ./check_ntp_time -H 0.us.pool.ntp.org -w 60 -c 120 Segmentation Fault /usr/local/nagios/libexec$ ./check_ntp_time -v -H 0.us.pool.ntp.org -w 60 -c 120 sending request to peer 0 sending request to peer 1 response from peer 0: offset 54.24633014 sending request to peer 0 response from peer 1: offset 54.23421776 . . . response from peer 4: offset 54.23087406 sending request to peer 4 response from peer 4: offset 54.23018897 sending request to peer 4 response from peer 4: offset 54.23138392 Segmentation Fault Here's the truss output: sending request to peer 4 write(1, " s e n d i n g r e q u".., 26) = 26 write(8, "E3\004FA\001\0\0\001\0\0".., 48) = 48 poll(0x00034298, 5, 100) = 1 read(8, " $0104ED\0\0\0\0\0\0\011".., 48) = 48 response from peer 4: offset 54.24180388 write(1, " r e s p o n s e f r o".., 41) = 41 Incurred fault #6, FLTBOUNDS %pc = 0x00015FB4 siginfo: SIGSEGV SEGV_MAPERR addr=0x7FC1E3A4 Received signal #11, SIGSEGV [default] siginfo: SIGSEGV SEGV_MAPERR addr=0x7FC1E3A4 And the traceback: /usr/local/nagios/libexec# dbx /usr/local/nagios/libexec/check_ntp_time Reading check_ntp_time Reading ld.so.1 Reading libresolv.so.2 Reading libm.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libc.so.1 Reading libdl.so.1 Reading libmp.so.2 Reading libc_psr.so.1 (dbx) run -H 0.us.pool.ntp.org -w 60 -c 120 Running: check_ntp_time -H 0.us.pool.ntp.org -w 60 -c 120 (process id 12120) signal SEGV (no mapping at the fault address) in offset_request at line 427 in file "check_ntp_time.c" (dbx) where =>[1] offset_request(host = 0x354b0 "0.us.pool.ntp.org", status = 0xffbffae4), line 427 in "check_ntp_time.c" [2] main(argc = 7, argv = 0xffbffb54), line 554 in "check_ntp_time.c" ---------------------------------------------------------------------- >Comment By: digitalruin (digitalruin) Date: 2008-01-03 11:41 Message: Logged In: YES user_id=1609785 Originator: YES Here, I was able to pull a more detailed traceback with the core dump. Definitely the function that selects the best server: =>[1] best_offset_server(slist = 0x354a8, nservers = 5), line 310 in "check_ntp.c" [2] offset_request(host = 0x36aa0 "1.us.pool.ntp.org", status = 0xffbffb5c), line 477 in "check_ntp.c" [3] main(argc = 8, argv = 0xffbffbcc), line 778 in "check_ntp.c" ---------------------------------------------------------------------- Comment By: digitalruin (digitalruin) Date: 2008-01-03 11:38 Message: Logged In: YES user_id=1609785 Originator: YES No problem. Yeah it's the same in check_ntp. I actually had it pass once without failing, but I think it was due to the server only having a two or three choices. With full verbose I can see that it segfaults when choosing the best server to go with. If it has xn it segfaults during the decision. So to simplify, no segfault when runnng the check against one ntp server. Possibly no segfault when running it against a pool that only consists of three or four. Always segfaults when hitting a large pool server like ntp.org. Here's the info... I ran it twice with both two different ntp hubs and it failed: # ./check_ntp -vvv -H 1.us.pool.ntp.org -w 60 -c 120 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377653.767585 rxts = 1199377710.512649 txts = 1199377710.512664 offset 56.70649898 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377653.850921 rxts = 1199377710.594606 txts = 1199377710.594627 offset 56.70579767 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377653.927373 rxts = 1199377710.670819 txts = 1199377710.670839 offset 56.70584822 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377654.003221 rxts = 1199377710.747487 txts = 1199377710.747508 offset 56.70499885 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.034637451171875 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.082479 rxts = 1199377710.829896 txts = 1199377710.82992 offset 56.70595193 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.034637451171875 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.166106 rxts = 1199377710.913108 txts = 1199377710.913127 offset 56.70589066 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.034637451171875 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.248994 rxts = 1199377710.996055 txts = 1199377710.996118 offset 56.70593584 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.0346527099609375 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.331923 rxts = 1199377711.078835 txts = 1199377711.078882 offset 56.70586824 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.414673 rxts = 1199377711.154322 txts = 1199377711.154334 offset 56.69950116 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.495628 rxts = 1199377711.234703 txts = 1199377711.234713 offset 56.6990782 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.576271 rxts = 1199377711.31571 txts = 1199377711.315721 offset 56.69919193 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.657396 rxts = 1199377711.396339 txts = 1199377711.39635 offset 56.69902682 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.737869 rxts = 1199377711.4489 txts = 1199377711.448967 offset 56.70623863 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.748154 rxts = 1199377711.45769 txts = 1199377711.457742 offset 56.70598435 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.755922 rxts = 1199377711.466313 txts = 1199377711.466348 offset 56.7064172 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.76451 rxts = 1199377711.473845 txts = 1199377711.47388 offset 56.70550835 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.772819 rxts = 1199377711.483832 txts = 1199377711.483859 offset 56.70550382 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.784468 rxts = 1199377711.496182 txts = 1199377711.496194 offset 56.70548892 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.797513 rxts = 1199377711.508051 txts = 1199377711.508061 offset 56.70531833 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.808561 rxts = 1199377711.522168 txts = 1199377711.52218 offset 56.70665574 best server selected: peer 1273064242 Segmentation Fault (core dumped) Here's the dbx traceback from check_ntp: =>[1] offset_request(host = 0x36aa0 "1.us.pool.ntp.org", status = 0xffbffad4), line 482 in "check_ntp.c" [2] main(argc = 6, argv = 0xffbffb44), line 778 in "check_ntp.c" ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-01-03 07:39 Message: Logged In: YES user_id=375623 Originator: NO Hi, I'm the author of check_ntp_time and it's mostly based on check_ntp (written by Sean Finney). The specific place where it segfaults (offset_request function) hasn't been modified so this should apply to check_ntp.c as well. Could you confirm running check_ntp with the same arguments does the same segfault? Also I can't reproduce the bug on my Linux and Solaris boxes and FreeBSD VM. Does it happens all the time? Is it's still happening? To debug further I will need the full verbose output of the plug-in ("-vvv" instead of "-v"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862300&group_id=29880 From noreply at sourceforge.net Fri Jan 4 07:54:03 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Jan 2008 22:54:03 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1862300 ] check_ntp_time segfault in 1.4.11 Message-ID: Bugs item #1862300, was opened at 2008-01-02 11:39 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862300&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: digitalruin (digitalruin) Assigned to: Thomas Guyot (dermoth) Summary: check_ntp_time segfault in 1.4.11 Initial Comment: Hi, I'm running 1.4.11 on a Solaris 9 setup and check_ntp_time seems to have a segfault issue. This only happens when running it against an ntp pool, not an individual host. See below: /usr/local/nagios/libexec$ ./check_ntp_time -H 0.us.pool.ntp.org -w 60 -c 120 Segmentation Fault /usr/local/nagios/libexec$ ./check_ntp_time -v -H 0.us.pool.ntp.org -w 60 -c 120 sending request to peer 0 sending request to peer 1 response from peer 0: offset 54.24633014 sending request to peer 0 response from peer 1: offset 54.23421776 . . . response from peer 4: offset 54.23087406 sending request to peer 4 response from peer 4: offset 54.23018897 sending request to peer 4 response from peer 4: offset 54.23138392 Segmentation Fault Here's the truss output: sending request to peer 4 write(1, " s e n d i n g r e q u".., 26) = 26 write(8, "E3\004FA\001\0\0\001\0\0".., 48) = 48 poll(0x00034298, 5, 100) = 1 read(8, " $0104ED\0\0\0\0\0\0\011".., 48) = 48 response from peer 4: offset 54.24180388 write(1, " r e s p o n s e f r o".., 41) = 41 Incurred fault #6, FLTBOUNDS %pc = 0x00015FB4 siginfo: SIGSEGV SEGV_MAPERR addr=0x7FC1E3A4 Received signal #11, SIGSEGV [default] siginfo: SIGSEGV SEGV_MAPERR addr=0x7FC1E3A4 And the traceback: /usr/local/nagios/libexec# dbx /usr/local/nagios/libexec/check_ntp_time Reading check_ntp_time Reading ld.so.1 Reading libresolv.so.2 Reading libm.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libc.so.1 Reading libdl.so.1 Reading libmp.so.2 Reading libc_psr.so.1 (dbx) run -H 0.us.pool.ntp.org -w 60 -c 120 Running: check_ntp_time -H 0.us.pool.ntp.org -w 60 -c 120 (process id 12120) signal SEGV (no mapping at the fault address) in offset_request at line 427 in file "check_ntp_time.c" (dbx) where =>[1] offset_request(host = 0x354b0 "0.us.pool.ntp.org", status = 0xffbffae4), line 427 in "check_ntp_time.c" [2] main(argc = 7, argv = 0xffbffb54), line 554 in "check_ntp_time.c" ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2008-01-04 01:54 Message: Logged In: YES user_id=375623 Originator: NO > best server selected: peer 1273064242 This is plain wrong. This should be between 0 and 5 and is definitely why you get a segfault. How you end up with that value is mystery though. Can you please apply the attached patch (check_ntp_time.mega_debug.patch) and send again the full output of -vvv? The patch basically trace every operation in best_offset_server and print out what's going on. Thanks File Added: check_ntp_time.mega_debug.patch ---------------------------------------------------------------------- Comment By: digitalruin (digitalruin) Date: 2008-01-03 11:41 Message: Logged In: YES user_id=1609785 Originator: YES Here, I was able to pull a more detailed traceback with the core dump. Definitely the function that selects the best server: =>[1] best_offset_server(slist = 0x354a8, nservers = 5), line 310 in "check_ntp.c" [2] offset_request(host = 0x36aa0 "1.us.pool.ntp.org", status = 0xffbffb5c), line 477 in "check_ntp.c" [3] main(argc = 8, argv = 0xffbffbcc), line 778 in "check_ntp.c" ---------------------------------------------------------------------- Comment By: digitalruin (digitalruin) Date: 2008-01-03 11:38 Message: Logged In: YES user_id=1609785 Originator: YES No problem. Yeah it's the same in check_ntp. I actually had it pass once without failing, but I think it was due to the server only having a two or three choices. With full verbose I can see that it segfaults when choosing the best server to go with. If it has xn it segfaults during the decision. So to simplify, no segfault when runnng the check against one ntp server. Possibly no segfault when running it against a pool that only consists of three or four. Always segfaults when hitting a large pool server like ntp.org. Here's the info... I ran it twice with both two different ntp hubs and it failed: # ./check_ntp -vvv -H 1.us.pool.ntp.org -w 60 -c 120 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377653.767585 rxts = 1199377710.512649 txts = 1199377710.512664 offset 56.70649898 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377653.850921 rxts = 1199377710.594606 txts = 1199377710.594627 offset 56.70579767 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377653.927373 rxts = 1199377710.670819 txts = 1199377710.670839 offset 56.70584822 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377654.003221 rxts = 1199377710.747487 txts = 1199377710.747508 offset 56.70499885 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.034637451171875 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.082479 rxts = 1199377710.829896 txts = 1199377710.82992 offset 56.70595193 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.034637451171875 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.166106 rxts = 1199377710.913108 txts = 1199377710.913127 offset 56.70589066 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.034637451171875 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.248994 rxts = 1199377710.996055 txts = 1199377710.996118 offset 56.70593584 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.0346527099609375 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.331923 rxts = 1199377711.078835 txts = 1199377711.078882 offset 56.70586824 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.414673 rxts = 1199377711.154322 txts = 1199377711.154334 offset 56.69950116 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.495628 rxts = 1199377711.234703 txts = 1199377711.234713 offset 56.6990782 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.576271 rxts = 1199377711.31571 txts = 1199377711.315721 offset 56.69919193 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.657396 rxts = 1199377711.396339 txts = 1199377711.39635 offset 56.69902682 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.737869 rxts = 1199377711.4489 txts = 1199377711.448967 offset 56.70623863 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.748154 rxts = 1199377711.45769 txts = 1199377711.457742 offset 56.70598435 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.755922 rxts = 1199377711.466313 txts = 1199377711.466348 offset 56.7064172 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.76451 rxts = 1199377711.473845 txts = 1199377711.47388 offset 56.70550835 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.772819 rxts = 1199377711.483832 txts = 1199377711.483859 offset 56.70550382 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.784468 rxts = 1199377711.496182 txts = 1199377711.496194 offset 56.70548892 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.797513 rxts = 1199377711.508051 txts = 1199377711.508061 offset 56.70531833 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.808561 rxts = 1199377711.522168 txts = 1199377711.52218 offset 56.70665574 best server selected: peer 1273064242 Segmentation Fault (core dumped) Here's the dbx traceback from check_ntp: =>[1] offset_request(host = 0x36aa0 "1.us.pool.ntp.org", status = 0xffbffad4), line 482 in "check_ntp.c" [2] main(argc = 6, argv = 0xffbffb44), line 778 in "check_ntp.c" ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-01-03 07:39 Message: Logged In: YES user_id=375623 Originator: NO Hi, I'm the author of check_ntp_time and it's mostly based on check_ntp (written by Sean Finney). The specific place where it segfaults (offset_request function) hasn't been modified so this should apply to check_ntp.c as well. Could you confirm running check_ntp with the same arguments does the same segfault? Also I can't reproduce the bug on my Linux and Solaris boxes and FreeBSD VM. Does it happens all the time? Is it's still happening? To debug further I will need the full verbose output of the plug-in ("-vvv" instead of "-v"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862300&group_id=29880 From jzobel at heute-morgen.de Thu Jan 3 22:52:18 2008 From: jzobel at heute-morgen.de (Joachim Zobel) Date: Thu, 03 Jan 2008 22:52:18 +0100 Subject: [Nagiosplug-devel] check_mysql --check-slave segfaults with mysql 4.0.x Message-ID: <1199397139.3927.18.camel@test.asus> Hi. Since MySQLs SHOW SLAVE STATUS comes without the Seconds_Behind_Master field for (approximately) 4.0.x, check_mysql --check-slave segfaults for these versions. A rather trivial patch is attached. Sincerely, Joachim -------------- next part -------------- A non-text attachment was scrubbed... Name: check_mysql.c.diff Type: text/x-patch Size: 912 bytes Desc: not available URL: From noreply at sourceforge.net Fri Jan 4 20:28:07 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Jan 2008 11:28:07 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1862300 ] check_ntp_time segfault in 1.4.11 Message-ID: Bugs item #1862300, was opened at 2008-01-02 11:39 Message generated for change (Comment added) made by digitalruin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862300&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: digitalruin (digitalruin) Assigned to: Thomas Guyot (dermoth) Summary: check_ntp_time segfault in 1.4.11 Initial Comment: Hi, I'm running 1.4.11 on a Solaris 9 setup and check_ntp_time seems to have a segfault issue. This only happens when running it against an ntp pool, not an individual host. See below: /usr/local/nagios/libexec$ ./check_ntp_time -H 0.us.pool.ntp.org -w 60 -c 120 Segmentation Fault /usr/local/nagios/libexec$ ./check_ntp_time -v -H 0.us.pool.ntp.org -w 60 -c 120 sending request to peer 0 sending request to peer 1 response from peer 0: offset 54.24633014 sending request to peer 0 response from peer 1: offset 54.23421776 . . . response from peer 4: offset 54.23087406 sending request to peer 4 response from peer 4: offset 54.23018897 sending request to peer 4 response from peer 4: offset 54.23138392 Segmentation Fault Here's the truss output: sending request to peer 4 write(1, " s e n d i n g r e q u".., 26) = 26 write(8, "E3\004FA\001\0\0\001\0\0".., 48) = 48 poll(0x00034298, 5, 100) = 1 read(8, " $0104ED\0\0\0\0\0\0\011".., 48) = 48 response from peer 4: offset 54.24180388 write(1, " r e s p o n s e f r o".., 41) = 41 Incurred fault #6, FLTBOUNDS %pc = 0x00015FB4 siginfo: SIGSEGV SEGV_MAPERR addr=0x7FC1E3A4 Received signal #11, SIGSEGV [default] siginfo: SIGSEGV SEGV_MAPERR addr=0x7FC1E3A4 And the traceback: /usr/local/nagios/libexec# dbx /usr/local/nagios/libexec/check_ntp_time Reading check_ntp_time Reading ld.so.1 Reading libresolv.so.2 Reading libm.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libc.so.1 Reading libdl.so.1 Reading libmp.so.2 Reading libc_psr.so.1 (dbx) run -H 0.us.pool.ntp.org -w 60 -c 120 Running: check_ntp_time -H 0.us.pool.ntp.org -w 60 -c 120 (process id 12120) signal SEGV (no mapping at the fault address) in offset_request at line 427 in file "check_ntp_time.c" (dbx) where =>[1] offset_request(host = 0x354b0 "0.us.pool.ntp.org", status = 0xffbffae4), line 427 in "check_ntp_time.c" [2] main(argc = 7, argv = 0xffbffb54), line 554 in "check_ntp_time.c" ---------------------------------------------------------------------- >Comment By: digitalruin (digitalruin) Date: 2008-01-04 14:28 Message: Logged In: YES user_id=1609785 Originator: YES Here you go : # ./check_ntp_time -vvv -H 1.pool.ntp.org -w 120 -c 300 Found 5 peers to check sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0445709228515625 rtdisp = 0.0609893798828125 refid = c63c16f0 refts = 1199472719.993338 origts = 1199474568.474856 rxts = 1199474627.965969 txts = 1199474627.966372 offset 59.46767855 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0445709228515625 rtdisp = 0.0609893798828125 refid = c63c16f0 refts = 1199472719.993338 origts = 1199474568.528016 rxts = 1199474628.018613 txts = 1199474628.01866 offset 59.46698618 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0445709228515625 rtdisp = 0.0609893798828125 refid = c63c16f0 refts = 1199472719.993338 origts = 1199474568.580226 rxts = 1199474628.071063 txts = 1199474628.071103 offset 59.4676069 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0445709228515625 rtdisp = 0.0609893798828125 refid = c63c16f0 refts = 1199472719.993338 origts = 1199474568.627356 rxts = 1199474628.118044 txts = 1199474628.118088 offset 59.46739721 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0011444091796875 rtdisp = 0.04412841796875 refid = 40490009 refts = 1199473765.176361 origts = 1199474568.674596 rxts = 1199474628.163931 txts = 1199474628.163948 offset 59.46385014 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0011444091796875 rtdisp = 0.0441436767578125 refid = 40490009 refts = 1199473765.176361 origts = 1199474568.726196 rxts = 1199474628.215072 txts = 1199474628.215088 offset 59.46364021 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0011444091796875 rtdisp = 0.0441436767578125 refid = 40490009 refts = 1199473765.176361 origts = 1199474568.77732 rxts = 1199474628.26508 txts = 1199474628.265097 offset 59.46305585 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0011444091796875 rtdisp = 0.0441436767578125 refid = 40490009 refts = 1199473765.176361 origts = 1199474568.827371 rxts = 1199474628.319556 txts = 1199474628.319573 offset 59.46525288 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.01885986328125 rtdisp = 0.0413818359375 refid = d1510907 refts = 1199473265.973837 origts = 1199474568.881858 rxts = 1199474628.396212 txts = 1199474628.396236 offset 59.47221529 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.01885986328125 rtdisp = 0.0413818359375 refid = d1510907 refts = 1199473265.973837 origts = 1199474568.966791 rxts = 1199474628.480412 txts = 1199474628.480432 offset 59.4719218 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.01885986328125 rtdisp = 0.0413818359375 refid = d1510907 refts = 1199473265.973837 origts = 1199474569.050913 rxts = 1199474628.564735 txts = 1199474628.564755 offset 59.47202778 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.01885986328125 rtdisp = 0.0413818359375 refid = d1510907 refts = 1199473265.973837 origts = 1199474569.135167 rxts = 1199474628.648808 txts = 1199474628.648838 offset 59.47195649 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0023040771484375 rtdisp = 0.02984619140625 refid = d133a1ee refts = 1199473719.765392 origts = 1199474569.219201 rxts = 1199474628.696106 txts = 1199474628.696119 offset 59.47111976 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0023040771484375 rtdisp = 0.02984619140625 refid = d133a1ee refts = 1199473719.765392 origts = 1199474569.231406 rxts = 1199474628.708094 txts = 1199474628.708102 offset 59.47123277 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0023040771484375 rtdisp = 0.02984619140625 refid = d133a1ee refts = 1199473719.765392 origts = 1199474569.242943 rxts = 1199474628.719963 txts = 1199474628.719971 offset 59.4704082 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0023040771484375 rtdisp = 0.02984619140625 refid = d133a1ee refts = 1199473719.765392 origts = 1199474569.257685 rxts = 1199474628.734954 txts = 1199474628.734963 offset 59.47152829 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 3 poll = 16 precision = 9.53674e-07 rtdelay = 0.12030029296875 rtdisp = 0.0667724609375 refid = d04cf473 refts = 1199473596.941478 origts = 1199474569.269815 rxts = 1199474628.795154 txts = 1199474628.795205 offset 59.46338224 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 3 poll = 16 precision = 9.53674e-07 rtdelay = 0.12030029296875 rtdisp = 0.0667877197265625 refid = d04cf473 refts = 1199473596.941478 origts = 1199474569.39442 rxts = 1199474628.920017 txts = 1199474628.920062 offset 59.46323884 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 3 poll = 16 precision = 9.53674e-07 rtdelay = 0.12030029296875 rtdisp = 0.0667877197265625 refid = d04cf473 refts = 1199473596.941478 origts = 1199474569.519803 rxts = 1199474629.045887 txts = 1199474629.045933 offset 59.46334183 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 3 poll = 16 precision = 9.53674e-07 rtdelay = 0.12030029296875 rtdisp = 0.0667877197265625 refid = d04cf473 refts = 1199473596.941478 origts = 1199474569.645956 rxts = 1199474629.173512 txts = 1199474629.173553 offset 59.46439874 best_offset_server() line 253: nservers=5 best_offset_server() line 257: cserver=0 best_offset_server() line 298: candidates[0]=0 (csize=0) best_offset_server() line 257: cserver=1 best_offset_server() line 269: slist[1].stratum <= slist[0].stratum best_offset_server() line 273: slist[1].rtdisp <= slist[0].rtdisp best_offset_server() line 277: slist[1].rtdelay < slist[0].rtdelay best_offset_server() line 291: candidates[5]=candidates[5-1] (i=0, csize=1) best_offset_server() line 291: candidates[4]=candidates[4-1] (i=0, csize=1) best_offset_server() line 291: candidates[3]=candidates[3-1] (i=0, csize=1) best_offset_server() line 291: candidates[2]=candidates[2-1] (i=0, csize=1) best_offset_server() line 291: candidates[1]=candidates[1-1] (i=0, csize=1) best_offset_server() line 298: candidates[0]=-246736175 (csize=1) best_offset_server() line 257: cserver=-246736174 Segmentation Fault (core dumped) ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-01-04 01:54 Message: Logged In: YES user_id=375623 Originator: NO > best server selected: peer 1273064242 This is plain wrong. This should be between 0 and 5 and is definitely why you get a segfault. How you end up with that value is mystery though. Can you please apply the attached patch (check_ntp_time.mega_debug.patch) and send again the full output of -vvv? The patch basically trace every operation in best_offset_server and print out what's going on. Thanks File Added: check_ntp_time.mega_debug.patch ---------------------------------------------------------------------- Comment By: digitalruin (digitalruin) Date: 2008-01-03 11:41 Message: Logged In: YES user_id=1609785 Originator: YES Here, I was able to pull a more detailed traceback with the core dump. Definitely the function that selects the best server: =>[1] best_offset_server(slist = 0x354a8, nservers = 5), line 310 in "check_ntp.c" [2] offset_request(host = 0x36aa0 "1.us.pool.ntp.org", status = 0xffbffb5c), line 477 in "check_ntp.c" [3] main(argc = 8, argv = 0xffbffbcc), line 778 in "check_ntp.c" ---------------------------------------------------------------------- Comment By: digitalruin (digitalruin) Date: 2008-01-03 11:38 Message: Logged In: YES user_id=1609785 Originator: YES No problem. Yeah it's the same in check_ntp. I actually had it pass once without failing, but I think it was due to the server only having a two or three choices. With full verbose I can see that it segfaults when choosing the best server to go with. If it has xn it segfaults during the decision. So to simplify, no segfault when runnng the check against one ntp server. Possibly no segfault when running it against a pool that only consists of three or four. Always segfaults when hitting a large pool server like ntp.org. Here's the info... I ran it twice with both two different ntp hubs and it failed: # ./check_ntp -vvv -H 1.us.pool.ntp.org -w 60 -c 120 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377653.767585 rxts = 1199377710.512649 txts = 1199377710.512664 offset 56.70649898 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377653.850921 rxts = 1199377710.594606 txts = 1199377710.594627 offset 56.70579767 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377653.927373 rxts = 1199377710.670819 txts = 1199377710.670839 offset 56.70584822 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377654.003221 rxts = 1199377710.747487 txts = 1199377710.747508 offset 56.70499885 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.034637451171875 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.082479 rxts = 1199377710.829896 txts = 1199377710.82992 offset 56.70595193 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.034637451171875 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.166106 rxts = 1199377710.913108 txts = 1199377710.913127 offset 56.70589066 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.034637451171875 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.248994 rxts = 1199377710.996055 txts = 1199377710.996118 offset 56.70593584 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.0346527099609375 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.331923 rxts = 1199377711.078835 txts = 1199377711.078882 offset 56.70586824 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.414673 rxts = 1199377711.154322 txts = 1199377711.154334 offset 56.69950116 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.495628 rxts = 1199377711.234703 txts = 1199377711.234713 offset 56.6990782 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.576271 rxts = 1199377711.31571 txts = 1199377711.315721 offset 56.69919193 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.657396 rxts = 1199377711.396339 txts = 1199377711.39635 offset 56.69902682 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.737869 rxts = 1199377711.4489 txts = 1199377711.448967 offset 56.70623863 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.748154 rxts = 1199377711.45769 txts = 1199377711.457742 offset 56.70598435 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.755922 rxts = 1199377711.466313 txts = 1199377711.466348 offset 56.7064172 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.76451 rxts = 1199377711.473845 txts = 1199377711.47388 offset 56.70550835 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.772819 rxts = 1199377711.483832 txts = 1199377711.483859 offset 56.70550382 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.784468 rxts = 1199377711.496182 txts = 1199377711.496194 offset 56.70548892 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.797513 rxts = 1199377711.508051 txts = 1199377711.508061 offset 56.70531833 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.808561 rxts = 1199377711.522168 txts = 1199377711.52218 offset 56.70665574 best server selected: peer 1273064242 Segmentation Fault (core dumped) Here's the dbx traceback from check_ntp: =>[1] offset_request(host = 0x36aa0 "1.us.pool.ntp.org", status = 0xffbffad4), line 482 in "check_ntp.c" [2] main(argc = 6, argv = 0xffbffb44), line 778 in "check_ntp.c" ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-01-03 07:39 Message: Logged In: YES user_id=375623 Originator: NO Hi, I'm the author of check_ntp_time and it's mostly based on check_ntp (written by Sean Finney). The specific place where it segfaults (offset_request function) hasn't been modified so this should apply to check_ntp.c as well. Could you confirm running check_ntp with the same arguments does the same segfault? Also I can't reproduce the bug on my Linux and Solaris boxes and FreeBSD VM. Does it happens all the time? Is it's still happening? To debug further I will need the full verbose output of the plug-in ("-vvv" instead of "-v"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862300&group_id=29880 From noreply at sourceforge.net Fri Jan 4 22:37:55 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Jan 2008 13:37:55 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1864225 ] check_procs under SunOS 5.10 broken Message-ID: Bugs item #1864225, was opened at 2008-01-04 22:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1864225&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs under SunOS 5.10 broken Initial Comment: Hi, i just compiled the 4.11 plugins on a $ uname -a SunOS spnb51 5.10 Generic_118833-24 sun4v sparc SUNW,Sun-Fire-T200 and found that check_procs does not work correctly. $ ps -ef | grep cron root 15100 1 0 Nov 08 ? 1:06 /usr/sbin/cron $ /usr/ucb/ps -alxwwn | grep cron 0 0 15100 1 0 59 20 2784 1048 60015774482 S ? 1:06 /usr/sbin/cron Cron is running, but.... check_procs -w :10 -c 1: -C cron PROCS CRITICAL: 0 processes with command name '/usr/sbin/cron' Running check-procs with -vvv shows, that it uses /usr/ucb/ps -alxwwn and actually parses the right line proc#=0 uid=0 vsz=2784 rss=1048 pid=15100 ppid=1 pcpu=0.00 stat=S etime= prog= args=/usr/sbin/cron but as you see, prog is empty and what should be prog is recognized as argument. Please change the configure.in (the buggy lines in configure are 24967 ff) so that it reads: ac_cv_ps_varlist="&procuid,&procpid,&procppid,&procpcpu,&procvsz,&procrs s,procstat,procprog,&pos" ac_cv_ps_command="/usr/ucb/ps -alxwwn" ac_cv_ps_format="%*s %d %d %d %d %*d %*d %d %d%*[ 0123456789abcdef]%[OSR ZT]%*s %*s %s %n" ac_cv_ps_cols=9 (add procprog to the varlist, add a %s at the end of format and increase cols) Then it looks good: $ check_procs -w :10 -c 1: -C cron PROCS OK: 1 process with command name 'cron' Greetings from Munich, Gerhard ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1864225&group_id=29880 From noreply at sourceforge.net Fri Jan 4 23:32:45 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Jan 2008 14:32:45 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1862218 ] check_procs: usage2 does not expect a format string Message-ID: Bugs item #1862218, was opened at 2008-01-02 15:49 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862218&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: Ferenc W?gner (wferi) >Assigned to: Matthias Eble (psychotrahe) Summary: check_procs: usage2 does not expect a format string Initial Comment: Hi, See the following error message: $ /usr/lib/nagios/plugins/check_procs -u nosuchuser check_procs: User name %s was not found - nosuchuser Usage:check_procs [...] 1. The '%s' in the error message is superfluous. In CVS, it's at check_procs.c:426, with a similar buglet on line 420. The fix looks dead easy: remove '%s ' from those two lines. 2. On the next line, 'Usage:' should be followed by a space (CVS line 753). Just to make the output prettier. Regards, Feri. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2008-01-04 23:32 Message: Logged In: YES user_id=1694341 Originator: NO Hi Ferenc, thanks for your report, this is fixed in svn, now. Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862218&group_id=29880 From noreply at sourceforge.net Sat Jan 5 00:13:15 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Jan 2008 15:13:15 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1852188 ] Check_by_ssh exit code always 0 Message-ID: Bugs item #1852188, was opened at 2007-12-17 10:39 Message generated for change (Settings changed) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1852188&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: Duplicate Priority: 5 Private: No Submitted By: ADW (alain_dewit) Assigned to: Nobody/Anonymous (nobody) Summary: Check_by_ssh exit code always 0 Initial Comment: The "check_by_ssh" plugin report always an exit status/code of 0 when it should return a value of "2". Should be the same for the other exit code values. Plugin compiled from nagios-plugins-1.4.7.tar.gz on a RedHat Fedora Core Intel system. Best regards ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1852188&group_id=29880 From dermoth at aei.ca Sat Jan 5 00:23:27 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Fri, 04 Jan 2008 18:23:27 -0500 Subject: [Nagiosplug-devel] Nagios::Plugin perl module integrated into SVN In-Reply-To: <477E0DF5.4000607@mailing.kaufland-informationssysteme.com> References: <4ABE8CAF-6D2F-416A-AABA-75D99469945C@altinity.com> <20070915151720.GM6828@CIS.FU-Berlin.DE> <7FDE0ADE-370C-46C2-9DE3-1AD95880F477@altinity.com> <46ECC4BD.4050902@aei.ca> <477E0DF5.4000607@mailing.kaufland-informationssysteme.com> Message-ID: <477EBFEF.4070502@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/01/08 05:44 AM, Matthias Eble wrote: > Ton Voon schrieb: >> On 16 Sep 2007, at 06:53, Thomas Guyot-Sionnest wrote: >> >>> On a side note I just written a Perl plugin for checking M$ SQL >>> databases (attached). It fully uses N::P, including thresholds and >>> performance data (and it's awesome how easy it is now!). Strangely >>> right >>> after that I noticed there is a bash check_mssql in /contrib so I >>> thought maybe we could include mine as a replacement. I believe it's >>> also a good example of a N::P plugin. >> >> I'd definitely want an example plugin to include. >> >> I've had a quick look through yours (as much as I can without a mssql >> server) and it looks good. I notice that the contrib version has >> number of users in the output - could that be added (don't worry >> about thresholds for that yet)? Then we can remove the contrib version. >> >>> If we don't include it I'll upload it to NagiosExchange. >> >> Also, if you want it distributed in the core distribution, could you >> set the copyright as Nagios Plugins Development Team (you can list >> yourself as the original author). If you want to retain personal >> copyright, which is your entitlement, then it should be hosted on >> NagiosExchange. > > Hi Thomas, > > have you thought about including this plugin? > I guess it's this one: > http://www.nagiosexchange.org/Others.152.0.html?&tx_netnagext_pi1[p_view]=1150 > > right? Yes. It turns out the connection string it too driver-specific to make it a general purpose plugin. I'll drop the general usage and new drivers will be added on demand, though it will be a child's play to add them. I also think unresponsive dbs return UNKNOWN (or maybe I fixed it already...). The behavior will be optional. I'm probably going to use it in a production environment very soon, so ll get these issues fixed ASAP. For the future, some thing that I might find interesting are: 1. Ability to serialize queries and their thresholds just like check_disk do for partitions. The most complicated part will be parsing the command-line options. I think maybe we should have special options in N::P to leave some options to the programmer (N::P would just ignore them and leave them in order in @ARGV, something like that. Since it could break backward-compatibility (requirement to specify the thresholds before the query) this should be though well first. 2. Ability to fetch specific rows and columns. I have some nice ideas about this but it can wait... While we're at it, there's another script I wrote that could probably fit well in Nagios-Plugins. It's not using N::P yet but I'll be glad to integrate it if it's accepted. It's an Rsync check I wrote some time ago; I'm thinking of it because I just fixed a bug today and enchanced it a bit (though it still need some polishing) :) http://www.nagiosexchange.org/Misc.54.0.html?&tx_netnagext_pi1[p_view]=587 Or we can go the hard way and write one from scratch in C that talks the Rsync protocol (There would be some interesting advantages)! Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHfr/v6dZ+Kt5BchYRAvRPAKCNncur4hRg5cZybKXSBs9focMMNgCg+0Jc B9OdP2OJSdBeVpSgHLaByoA= =SZKJ -----END PGP SIGNATURE----- From noreply at sourceforge.net Sat Jan 5 00:38:31 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Jan 2008 15:38:31 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1852198 ] Check_by_ssh exit code always 0 Message-ID: Bugs item #1852198, was opened at 2007-12-17 10:56 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1852198&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: ADW (alain_dewit) Assigned to: Nobody/Anonymous (nobody) Summary: Check_by_ssh exit code always 0 Initial Comment: The "check_by_ssh" plugin report always an exit status/code of 0 when it should return a value of "2". Should be the same for the other exit code values. Plugin compiled from nagios-plugins-1.4.7.tar.gz on a RedHat Fedora Core Intel system. Best regards ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2008-01-05 00:38 Message: Logged In: YES user_id=1694341 Originator: NO Hello alain, I've looked into this issue and can reproduce the described behaviour.. But: check_by_ssh's -f argument simply adds -f to the ssh call. With -f, ssh immediately returns, even if the remote command is still running. Actually there is no exit code at this point. However, check_by_ssh waits for the command output, IMO because it reads from the output file descriptor which is left open until the remote command execution is done. But this is a side effect. Note that /usr/bin/ssh -f 127.0.0.1 'exit 2' ;echo $? also returns 0. I'd thus say check_by_ssh -f works as desi(gn|r)ed I cannot imagine what -f should be good for though. But we should at least place a note in --help. Any other comments? Matthias ---------------------------------------------------------------------- Comment By: ADW (alain_dewit) Date: 2007-12-17 12:11 Message: Logged In: YES user_id=1961631 Originator: YES I forgot to say that the problem only occur when using the "-f" (fork) option. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1852198&group_id=29880 From noreply at sourceforge.net Sat Jan 5 00:56:19 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Jan 2008 15:56:19 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1776916 ] Configure nagios-plugins inside vserver hangs Message-ID: Bugs item #1776916, was opened at 2007-08-18 18:12 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1776916&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: norbert (norbertklein) Assigned to: Nobody/Anonymous (nobody) Summary: Configure nagios-plugins inside vserver hangs Initial Comment: nagios-plugins-1.4.9 ./configure Gentoo Tested on x86 AMD64 gcc Configure nagios-plugins hangs inside vserver environment (or any other environment without IP 127.0.0.1) as soon as the configure script tries to check the ICMP syntax. Reproducible: Always Gentoo output: checking for ps... /bin/ps checking for ps syntax... /bin/ps axwo 'stat uid pid ppid vsz rss pcpu comm args' checking for ping... /bin/ping checking for ping6... /bin/ping6 checking for ICMP ping syntax... ctrl-c /usr/portage/net-analyzer/nagios-plugins/nagios-plugins-1.4.9.ebuild: src_compile aborted; exiting. The reason is that 127.0.0.1 is hardcoded as localhost IP inside the configure script. This is done for checking ICMP syntax and nslookup syntax. But vservers don't have this IP. The following files contain 127.0.0.1 hardcoded: configure.in check_dig.c check_pgsql.c check_smtp.c check_tcp.c check_ups.c I tested these five checks inside a vserver environment and check_dig was the only one which didn't work. As far as I understand the code the reason is that check_dig calls the program dig which fails in case of 127.0.0.1. The others use system calls for their operations. To fix it I modified configure.in and used the hostname in check_dig.c. I attached a patch for the two mentioned files. For Gentoo you find a modified ebuild below which contains the patchs as well. I tested it on two different Gentoo machines and it worked for me. http://www.acodedb.com/download/linux/nagios-plugins.tgz ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2008-01-05 00:56 Message: Logged In: YES user_id=1694341 Originator: NO why not using 127.0.0.1 as default and simply add a configure parameter where a valid ip/hostname can be set? ---------------------------------------------------------------------- Comment By: norbert (norbertklein) Date: 2007-12-16 10:34 Message: Logged In: YES user_id=1870307 Originator: YES Hi Ton unfortunately you can never be sure that "localhost" or "127.0.0.1" is reachable in a vserver. The point is that in the downloadable vserver templates I have seen so far, the file /etc/hosts always contains the typical record "127.0.0.1 localhost". This is obvious because the actual IP you will use for the vserver is unknown. If you use localhost in configure.in you assume that the maintainer of the vserver has set localhost in /etc/hosts to a valid IP. So maybe the easiest solution is to use localhost as you have suggested along with a warning or break off if it isn't reachable. You could additionally add some lines which check the first IP of the first network interface if localhost is unavailable. For ipv6, replacing ::1 with localhost should be the same, the standard /etc/hosts contains an ipv6 record for localhost and configure.in handles ipv6 with ping6. Norbert ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2007-12-13 23:28 Message: Logged In: YES user_id=664364 Originator: NO Norbert, Thanks for the report. Would using "localhost" be okay in configure.in? What impact would this have in IPv4 or IPv6 environments? Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1776916&group_id=29880 From noreply at sourceforge.net Sat Jan 5 01:07:17 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Jan 2008 16:07:17 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1862300 ] check_ntp_time segfault in 1.4.11 Message-ID: Bugs item #1862300, was opened at 2008-01-02 11:39 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862300&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: digitalruin (digitalruin) Assigned to: Thomas Guyot (dermoth) Summary: check_ntp_time segfault in 1.4.11 Initial Comment: Hi, I'm running 1.4.11 on a Solaris 9 setup and check_ntp_time seems to have a segfault issue. This only happens when running it against an ntp pool, not an individual host. See below: /usr/local/nagios/libexec$ ./check_ntp_time -H 0.us.pool.ntp.org -w 60 -c 120 Segmentation Fault /usr/local/nagios/libexec$ ./check_ntp_time -v -H 0.us.pool.ntp.org -w 60 -c 120 sending request to peer 0 sending request to peer 1 response from peer 0: offset 54.24633014 sending request to peer 0 response from peer 1: offset 54.23421776 . . . response from peer 4: offset 54.23087406 sending request to peer 4 response from peer 4: offset 54.23018897 sending request to peer 4 response from peer 4: offset 54.23138392 Segmentation Fault Here's the truss output: sending request to peer 4 write(1, " s e n d i n g r e q u".., 26) = 26 write(8, "E3\004FA\001\0\0\001\0\0".., 48) = 48 poll(0x00034298, 5, 100) = 1 read(8, " $0104ED\0\0\0\0\0\0\011".., 48) = 48 response from peer 4: offset 54.24180388 write(1, " r e s p o n s e f r o".., 41) = 41 Incurred fault #6, FLTBOUNDS %pc = 0x00015FB4 siginfo: SIGSEGV SEGV_MAPERR addr=0x7FC1E3A4 Received signal #11, SIGSEGV [default] siginfo: SIGSEGV SEGV_MAPERR addr=0x7FC1E3A4 And the traceback: /usr/local/nagios/libexec# dbx /usr/local/nagios/libexec/check_ntp_time Reading check_ntp_time Reading ld.so.1 Reading libresolv.so.2 Reading libm.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libc.so.1 Reading libdl.so.1 Reading libmp.so.2 Reading libc_psr.so.1 (dbx) run -H 0.us.pool.ntp.org -w 60 -c 120 Running: check_ntp_time -H 0.us.pool.ntp.org -w 60 -c 120 (process id 12120) signal SEGV (no mapping at the fault address) in offset_request at line 427 in file "check_ntp_time.c" (dbx) where =>[1] offset_request(host = 0x354b0 "0.us.pool.ntp.org", status = 0xffbffae4), line 427 in "check_ntp_time.c" [2] main(argc = 7, argv = 0xffbffb54), line 554 in "check_ntp_time.c" ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2008-01-04 19:07 Message: Logged In: YES user_id=375623 Originator: NO I got it. "int candidates[5]" is a 5-integer array, candidates[0] to candidates[4]. At line 277 (check_ntp_time v1861 (nagios-plugins 1.4.11)) where the function reorders the candidates it starts at candidates[5] which is out of bounds. In your case it was overwriting cserver putting random data in it. The attached patch should fix it; can you confirm? Thanks for your help in debugging this. This is greatly appreciated. File Added: check_ntp_time.best_offset_server_fix.patch ---------------------------------------------------------------------- Comment By: digitalruin (digitalruin) Date: 2008-01-04 14:28 Message: Logged In: YES user_id=1609785 Originator: YES Here you go : # ./check_ntp_time -vvv -H 1.pool.ntp.org -w 120 -c 300 Found 5 peers to check sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0445709228515625 rtdisp = 0.0609893798828125 refid = c63c16f0 refts = 1199472719.993338 origts = 1199474568.474856 rxts = 1199474627.965969 txts = 1199474627.966372 offset 59.46767855 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0445709228515625 rtdisp = 0.0609893798828125 refid = c63c16f0 refts = 1199472719.993338 origts = 1199474568.528016 rxts = 1199474628.018613 txts = 1199474628.01866 offset 59.46698618 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0445709228515625 rtdisp = 0.0609893798828125 refid = c63c16f0 refts = 1199472719.993338 origts = 1199474568.580226 rxts = 1199474628.071063 txts = 1199474628.071103 offset 59.4676069 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0445709228515625 rtdisp = 0.0609893798828125 refid = c63c16f0 refts = 1199472719.993338 origts = 1199474568.627356 rxts = 1199474628.118044 txts = 1199474628.118088 offset 59.46739721 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0011444091796875 rtdisp = 0.04412841796875 refid = 40490009 refts = 1199473765.176361 origts = 1199474568.674596 rxts = 1199474628.163931 txts = 1199474628.163948 offset 59.46385014 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0011444091796875 rtdisp = 0.0441436767578125 refid = 40490009 refts = 1199473765.176361 origts = 1199474568.726196 rxts = 1199474628.215072 txts = 1199474628.215088 offset 59.46364021 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0011444091796875 rtdisp = 0.0441436767578125 refid = 40490009 refts = 1199473765.176361 origts = 1199474568.77732 rxts = 1199474628.26508 txts = 1199474628.265097 offset 59.46305585 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0011444091796875 rtdisp = 0.0441436767578125 refid = 40490009 refts = 1199473765.176361 origts = 1199474568.827371 rxts = 1199474628.319556 txts = 1199474628.319573 offset 59.46525288 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.01885986328125 rtdisp = 0.0413818359375 refid = d1510907 refts = 1199473265.973837 origts = 1199474568.881858 rxts = 1199474628.396212 txts = 1199474628.396236 offset 59.47221529 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.01885986328125 rtdisp = 0.0413818359375 refid = d1510907 refts = 1199473265.973837 origts = 1199474568.966791 rxts = 1199474628.480412 txts = 1199474628.480432 offset 59.4719218 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.01885986328125 rtdisp = 0.0413818359375 refid = d1510907 refts = 1199473265.973837 origts = 1199474569.050913 rxts = 1199474628.564735 txts = 1199474628.564755 offset 59.47202778 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.01885986328125 rtdisp = 0.0413818359375 refid = d1510907 refts = 1199473265.973837 origts = 1199474569.135167 rxts = 1199474628.648808 txts = 1199474628.648838 offset 59.47195649 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0023040771484375 rtdisp = 0.02984619140625 refid = d133a1ee refts = 1199473719.765392 origts = 1199474569.219201 rxts = 1199474628.696106 txts = 1199474628.696119 offset 59.47111976 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0023040771484375 rtdisp = 0.02984619140625 refid = d133a1ee refts = 1199473719.765392 origts = 1199474569.231406 rxts = 1199474628.708094 txts = 1199474628.708102 offset 59.47123277 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0023040771484375 rtdisp = 0.02984619140625 refid = d133a1ee refts = 1199473719.765392 origts = 1199474569.242943 rxts = 1199474628.719963 txts = 1199474628.719971 offset 59.4704082 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0023040771484375 rtdisp = 0.02984619140625 refid = d133a1ee refts = 1199473719.765392 origts = 1199474569.257685 rxts = 1199474628.734954 txts = 1199474628.734963 offset 59.47152829 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 3 poll = 16 precision = 9.53674e-07 rtdelay = 0.12030029296875 rtdisp = 0.0667724609375 refid = d04cf473 refts = 1199473596.941478 origts = 1199474569.269815 rxts = 1199474628.795154 txts = 1199474628.795205 offset 59.46338224 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 3 poll = 16 precision = 9.53674e-07 rtdelay = 0.12030029296875 rtdisp = 0.0667877197265625 refid = d04cf473 refts = 1199473596.941478 origts = 1199474569.39442 rxts = 1199474628.920017 txts = 1199474628.920062 offset 59.46323884 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 3 poll = 16 precision = 9.53674e-07 rtdelay = 0.12030029296875 rtdisp = 0.0667877197265625 refid = d04cf473 refts = 1199473596.941478 origts = 1199474569.519803 rxts = 1199474629.045887 txts = 1199474629.045933 offset 59.46334183 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 3 poll = 16 precision = 9.53674e-07 rtdelay = 0.12030029296875 rtdisp = 0.0667877197265625 refid = d04cf473 refts = 1199473596.941478 origts = 1199474569.645956 rxts = 1199474629.173512 txts = 1199474629.173553 offset 59.46439874 best_offset_server() line 253: nservers=5 best_offset_server() line 257: cserver=0 best_offset_server() line 298: candidates[0]=0 (csize=0) best_offset_server() line 257: cserver=1 best_offset_server() line 269: slist[1].stratum <= slist[0].stratum best_offset_server() line 273: slist[1].rtdisp <= slist[0].rtdisp best_offset_server() line 277: slist[1].rtdelay < slist[0].rtdelay best_offset_server() line 291: candidates[5]=candidates[5-1] (i=0, csize=1) best_offset_server() line 291: candidates[4]=candidates[4-1] (i=0, csize=1) best_offset_server() line 291: candidates[3]=candidates[3-1] (i=0, csize=1) best_offset_server() line 291: candidates[2]=candidates[2-1] (i=0, csize=1) best_offset_server() line 291: candidates[1]=candidates[1-1] (i=0, csize=1) best_offset_server() line 298: candidates[0]=-246736175 (csize=1) best_offset_server() line 257: cserver=-246736174 Segmentation Fault (core dumped) ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-01-04 01:54 Message: Logged In: YES user_id=375623 Originator: NO > best server selected: peer 1273064242 This is plain wrong. This should be between 0 and 5 and is definitely why you get a segfault. How you end up with that value is mystery though. Can you please apply the attached patch (check_ntp_time.mega_debug.patch) and send again the full output of -vvv? The patch basically trace every operation in best_offset_server and print out what's going on. Thanks File Added: check_ntp_time.mega_debug.patch ---------------------------------------------------------------------- Comment By: digitalruin (digitalruin) Date: 2008-01-03 11:41 Message: Logged In: YES user_id=1609785 Originator: YES Here, I was able to pull a more detailed traceback with the core dump. Definitely the function that selects the best server: =>[1] best_offset_server(slist = 0x354a8, nservers = 5), line 310 in "check_ntp.c" [2] offset_request(host = 0x36aa0 "1.us.pool.ntp.org", status = 0xffbffb5c), line 477 in "check_ntp.c" [3] main(argc = 8, argv = 0xffbffbcc), line 778 in "check_ntp.c" ---------------------------------------------------------------------- Comment By: digitalruin (digitalruin) Date: 2008-01-03 11:38 Message: Logged In: YES user_id=1609785 Originator: YES No problem. Yeah it's the same in check_ntp. I actually had it pass once without failing, but I think it was due to the server only having a two or three choices. With full verbose I can see that it segfaults when choosing the best server to go with. If it has xn it segfaults during the decision. So to simplify, no segfault when runnng the check against one ntp server. Possibly no segfault when running it against a pool that only consists of three or four. Always segfaults when hitting a large pool server like ntp.org. Here's the info... I ran it twice with both two different ntp hubs and it failed: # ./check_ntp -vvv -H 1.us.pool.ntp.org -w 60 -c 120 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377653.767585 rxts = 1199377710.512649 txts = 1199377710.512664 offset 56.70649898 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377653.850921 rxts = 1199377710.594606 txts = 1199377710.594627 offset 56.70579767 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377653.927373 rxts = 1199377710.670819 txts = 1199377710.670839 offset 56.70584822 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377654.003221 rxts = 1199377710.747487 txts = 1199377710.747508 offset 56.70499885 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.034637451171875 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.082479 rxts = 1199377710.829896 txts = 1199377710.82992 offset 56.70595193 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.034637451171875 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.166106 rxts = 1199377710.913108 txts = 1199377710.913127 offset 56.70589066 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.034637451171875 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.248994 rxts = 1199377710.996055 txts = 1199377710.996118 offset 56.70593584 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.0346527099609375 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.331923 rxts = 1199377711.078835 txts = 1199377711.078882 offset 56.70586824 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.414673 rxts = 1199377711.154322 txts = 1199377711.154334 offset 56.69950116 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.495628 rxts = 1199377711.234703 txts = 1199377711.234713 offset 56.6990782 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.576271 rxts = 1199377711.31571 txts = 1199377711.315721 offset 56.69919193 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.657396 rxts = 1199377711.396339 txts = 1199377711.39635 offset 56.69902682 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.737869 rxts = 1199377711.4489 txts = 1199377711.448967 offset 56.70623863 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.748154 rxts = 1199377711.45769 txts = 1199377711.457742 offset 56.70598435 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.755922 rxts = 1199377711.466313 txts = 1199377711.466348 offset 56.7064172 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.76451 rxts = 1199377711.473845 txts = 1199377711.47388 offset 56.70550835 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.772819 rxts = 1199377711.483832 txts = 1199377711.483859 offset 56.70550382 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.784468 rxts = 1199377711.496182 txts = 1199377711.496194 offset 56.70548892 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.797513 rxts = 1199377711.508051 txts = 1199377711.508061 offset 56.70531833 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.808561 rxts = 1199377711.522168 txts = 1199377711.52218 offset 56.70665574 best server selected: peer 1273064242 Segmentation Fault (core dumped) Here's the dbx traceback from check_ntp: =>[1] offset_request(host = 0x36aa0 "1.us.pool.ntp.org", status = 0xffbffad4), line 482 in "check_ntp.c" [2] main(argc = 6, argv = 0xffbffb44), line 778 in "check_ntp.c" ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-01-03 07:39 Message: Logged In: YES user_id=375623 Originator: NO Hi, I'm the author of check_ntp_time and it's mostly based on check_ntp (written by Sean Finney). The specific place where it segfaults (offset_request function) hasn't been modified so this should apply to check_ntp.c as well. Could you confirm running check_ntp with the same arguments does the same segfault? Also I can't reproduce the bug on my Linux and Solaris boxes and FreeBSD VM. Does it happens all the time? Is it's still happening? To debug further I will need the full verbose output of the plug-in ("-vvv" instead of "-v"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862300&group_id=29880 From noreply at sourceforge.net Sat Jan 5 01:08:46 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Jan 2008 16:08:46 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1862300 ] check_ntp_time segfault in 1.4.11 Message-ID: Bugs item #1862300, was opened at 2008-01-02 11:39 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862300&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: digitalruin (digitalruin) Assigned to: Thomas Guyot (dermoth) Summary: check_ntp_time segfault in 1.4.11 Initial Comment: Hi, I'm running 1.4.11 on a Solaris 9 setup and check_ntp_time seems to have a segfault issue. This only happens when running it against an ntp pool, not an individual host. See below: /usr/local/nagios/libexec$ ./check_ntp_time -H 0.us.pool.ntp.org -w 60 -c 120 Segmentation Fault /usr/local/nagios/libexec$ ./check_ntp_time -v -H 0.us.pool.ntp.org -w 60 -c 120 sending request to peer 0 sending request to peer 1 response from peer 0: offset 54.24633014 sending request to peer 0 response from peer 1: offset 54.23421776 . . . response from peer 4: offset 54.23087406 sending request to peer 4 response from peer 4: offset 54.23018897 sending request to peer 4 response from peer 4: offset 54.23138392 Segmentation Fault Here's the truss output: sending request to peer 4 write(1, " s e n d i n g r e q u".., 26) = 26 write(8, "E3\004FA\001\0\0\001\0\0".., 48) = 48 poll(0x00034298, 5, 100) = 1 read(8, " $0104ED\0\0\0\0\0\0\011".., 48) = 48 response from peer 4: offset 54.24180388 write(1, " r e s p o n s e f r o".., 41) = 41 Incurred fault #6, FLTBOUNDS %pc = 0x00015FB4 siginfo: SIGSEGV SEGV_MAPERR addr=0x7FC1E3A4 Received signal #11, SIGSEGV [default] siginfo: SIGSEGV SEGV_MAPERR addr=0x7FC1E3A4 And the traceback: /usr/local/nagios/libexec# dbx /usr/local/nagios/libexec/check_ntp_time Reading check_ntp_time Reading ld.so.1 Reading libresolv.so.2 Reading libm.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libc.so.1 Reading libdl.so.1 Reading libmp.so.2 Reading libc_psr.so.1 (dbx) run -H 0.us.pool.ntp.org -w 60 -c 120 Running: check_ntp_time -H 0.us.pool.ntp.org -w 60 -c 120 (process id 12120) signal SEGV (no mapping at the fault address) in offset_request at line 427 in file "check_ntp_time.c" (dbx) where =>[1] offset_request(host = 0x354b0 "0.us.pool.ntp.org", status = 0xffbffae4), line 427 in "check_ntp_time.c" [2] main(argc = 7, argv = 0xffbffb54), line 554 in "check_ntp_time.c" ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2008-01-04 19:08 Message: Logged In: YES user_id=375623 Originator: NO P.S.: Apply the last patch against a fresh copy of check_ntp_time.c from Nagios-plugins 1.4.11. ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-01-04 19:07 Message: Logged In: YES user_id=375623 Originator: NO I got it. "int candidates[5]" is a 5-integer array, candidates[0] to candidates[4]. At line 277 (check_ntp_time v1861 (nagios-plugins 1.4.11)) where the function reorders the candidates it starts at candidates[5] which is out of bounds. In your case it was overwriting cserver putting random data in it. The attached patch should fix it; can you confirm? Thanks for your help in debugging this. This is greatly appreciated. File Added: check_ntp_time.best_offset_server_fix.patch ---------------------------------------------------------------------- Comment By: digitalruin (digitalruin) Date: 2008-01-04 14:28 Message: Logged In: YES user_id=1609785 Originator: YES Here you go : # ./check_ntp_time -vvv -H 1.pool.ntp.org -w 120 -c 300 Found 5 peers to check sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0445709228515625 rtdisp = 0.0609893798828125 refid = c63c16f0 refts = 1199472719.993338 origts = 1199474568.474856 rxts = 1199474627.965969 txts = 1199474627.966372 offset 59.46767855 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0445709228515625 rtdisp = 0.0609893798828125 refid = c63c16f0 refts = 1199472719.993338 origts = 1199474568.528016 rxts = 1199474628.018613 txts = 1199474628.01866 offset 59.46698618 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0445709228515625 rtdisp = 0.0609893798828125 refid = c63c16f0 refts = 1199472719.993338 origts = 1199474568.580226 rxts = 1199474628.071063 txts = 1199474628.071103 offset 59.4676069 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0445709228515625 rtdisp = 0.0609893798828125 refid = c63c16f0 refts = 1199472719.993338 origts = 1199474568.627356 rxts = 1199474628.118044 txts = 1199474628.118088 offset 59.46739721 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0011444091796875 rtdisp = 0.04412841796875 refid = 40490009 refts = 1199473765.176361 origts = 1199474568.674596 rxts = 1199474628.163931 txts = 1199474628.163948 offset 59.46385014 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0011444091796875 rtdisp = 0.0441436767578125 refid = 40490009 refts = 1199473765.176361 origts = 1199474568.726196 rxts = 1199474628.215072 txts = 1199474628.215088 offset 59.46364021 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0011444091796875 rtdisp = 0.0441436767578125 refid = 40490009 refts = 1199473765.176361 origts = 1199474568.77732 rxts = 1199474628.26508 txts = 1199474628.265097 offset 59.46305585 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0011444091796875 rtdisp = 0.0441436767578125 refid = 40490009 refts = 1199473765.176361 origts = 1199474568.827371 rxts = 1199474628.319556 txts = 1199474628.319573 offset 59.46525288 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.01885986328125 rtdisp = 0.0413818359375 refid = d1510907 refts = 1199473265.973837 origts = 1199474568.881858 rxts = 1199474628.396212 txts = 1199474628.396236 offset 59.47221529 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.01885986328125 rtdisp = 0.0413818359375 refid = d1510907 refts = 1199473265.973837 origts = 1199474568.966791 rxts = 1199474628.480412 txts = 1199474628.480432 offset 59.4719218 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.01885986328125 rtdisp = 0.0413818359375 refid = d1510907 refts = 1199473265.973837 origts = 1199474569.050913 rxts = 1199474628.564735 txts = 1199474628.564755 offset 59.47202778 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.01885986328125 rtdisp = 0.0413818359375 refid = d1510907 refts = 1199473265.973837 origts = 1199474569.135167 rxts = 1199474628.648808 txts = 1199474628.648838 offset 59.47195649 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0023040771484375 rtdisp = 0.02984619140625 refid = d133a1ee refts = 1199473719.765392 origts = 1199474569.219201 rxts = 1199474628.696106 txts = 1199474628.696119 offset 59.47111976 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0023040771484375 rtdisp = 0.02984619140625 refid = d133a1ee refts = 1199473719.765392 origts = 1199474569.231406 rxts = 1199474628.708094 txts = 1199474628.708102 offset 59.47123277 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0023040771484375 rtdisp = 0.02984619140625 refid = d133a1ee refts = 1199473719.765392 origts = 1199474569.242943 rxts = 1199474628.719963 txts = 1199474628.719971 offset 59.4704082 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0023040771484375 rtdisp = 0.02984619140625 refid = d133a1ee refts = 1199473719.765392 origts = 1199474569.257685 rxts = 1199474628.734954 txts = 1199474628.734963 offset 59.47152829 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 3 poll = 16 precision = 9.53674e-07 rtdelay = 0.12030029296875 rtdisp = 0.0667724609375 refid = d04cf473 refts = 1199473596.941478 origts = 1199474569.269815 rxts = 1199474628.795154 txts = 1199474628.795205 offset 59.46338224 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 3 poll = 16 precision = 9.53674e-07 rtdelay = 0.12030029296875 rtdisp = 0.0667877197265625 refid = d04cf473 refts = 1199473596.941478 origts = 1199474569.39442 rxts = 1199474628.920017 txts = 1199474628.920062 offset 59.46323884 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 3 poll = 16 precision = 9.53674e-07 rtdelay = 0.12030029296875 rtdisp = 0.0667877197265625 refid = d04cf473 refts = 1199473596.941478 origts = 1199474569.519803 rxts = 1199474629.045887 txts = 1199474629.045933 offset 59.46334183 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 3 poll = 16 precision = 9.53674e-07 rtdelay = 0.12030029296875 rtdisp = 0.0667877197265625 refid = d04cf473 refts = 1199473596.941478 origts = 1199474569.645956 rxts = 1199474629.173512 txts = 1199474629.173553 offset 59.46439874 best_offset_server() line 253: nservers=5 best_offset_server() line 257: cserver=0 best_offset_server() line 298: candidates[0]=0 (csize=0) best_offset_server() line 257: cserver=1 best_offset_server() line 269: slist[1].stratum <= slist[0].stratum best_offset_server() line 273: slist[1].rtdisp <= slist[0].rtdisp best_offset_server() line 277: slist[1].rtdelay < slist[0].rtdelay best_offset_server() line 291: candidates[5]=candidates[5-1] (i=0, csize=1) best_offset_server() line 291: candidates[4]=candidates[4-1] (i=0, csize=1) best_offset_server() line 291: candidates[3]=candidates[3-1] (i=0, csize=1) best_offset_server() line 291: candidates[2]=candidates[2-1] (i=0, csize=1) best_offset_server() line 291: candidates[1]=candidates[1-1] (i=0, csize=1) best_offset_server() line 298: candidates[0]=-246736175 (csize=1) best_offset_server() line 257: cserver=-246736174 Segmentation Fault (core dumped) ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-01-04 01:54 Message: Logged In: YES user_id=375623 Originator: NO > best server selected: peer 1273064242 This is plain wrong. This should be between 0 and 5 and is definitely why you get a segfault. How you end up with that value is mystery though. Can you please apply the attached patch (check_ntp_time.mega_debug.patch) and send again the full output of -vvv? The patch basically trace every operation in best_offset_server and print out what's going on. Thanks File Added: check_ntp_time.mega_debug.patch ---------------------------------------------------------------------- Comment By: digitalruin (digitalruin) Date: 2008-01-03 11:41 Message: Logged In: YES user_id=1609785 Originator: YES Here, I was able to pull a more detailed traceback with the core dump. Definitely the function that selects the best server: =>[1] best_offset_server(slist = 0x354a8, nservers = 5), line 310 in "check_ntp.c" [2] offset_request(host = 0x36aa0 "1.us.pool.ntp.org", status = 0xffbffb5c), line 477 in "check_ntp.c" [3] main(argc = 8, argv = 0xffbffbcc), line 778 in "check_ntp.c" ---------------------------------------------------------------------- Comment By: digitalruin (digitalruin) Date: 2008-01-03 11:38 Message: Logged In: YES user_id=1609785 Originator: YES No problem. Yeah it's the same in check_ntp. I actually had it pass once without failing, but I think it was due to the server only having a two or three choices. With full verbose I can see that it segfaults when choosing the best server to go with. If it has xn it segfaults during the decision. So to simplify, no segfault when runnng the check against one ntp server. Possibly no segfault when running it against a pool that only consists of three or four. Always segfaults when hitting a large pool server like ntp.org. Here's the info... I ran it twice with both two different ntp hubs and it failed: # ./check_ntp -vvv -H 1.us.pool.ntp.org -w 60 -c 120 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377653.767585 rxts = 1199377710.512649 txts = 1199377710.512664 offset 56.70649898 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377653.850921 rxts = 1199377710.594606 txts = 1199377710.594627 offset 56.70579767 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377653.927373 rxts = 1199377710.670819 txts = 1199377710.670839 offset 56.70584822 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377654.003221 rxts = 1199377710.747487 txts = 1199377710.747508 offset 56.70499885 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.034637451171875 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.082479 rxts = 1199377710.829896 txts = 1199377710.82992 offset 56.70595193 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.034637451171875 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.166106 rxts = 1199377710.913108 txts = 1199377710.913127 offset 56.70589066 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.034637451171875 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.248994 rxts = 1199377710.996055 txts = 1199377710.996118 offset 56.70593584 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.0346527099609375 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.331923 rxts = 1199377711.078835 txts = 1199377711.078882 offset 56.70586824 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.414673 rxts = 1199377711.154322 txts = 1199377711.154334 offset 56.69950116 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.495628 rxts = 1199377711.234703 txts = 1199377711.234713 offset 56.6990782 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.576271 rxts = 1199377711.31571 txts = 1199377711.315721 offset 56.69919193 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.657396 rxts = 1199377711.396339 txts = 1199377711.39635 offset 56.69902682 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.737869 rxts = 1199377711.4489 txts = 1199377711.448967 offset 56.70623863 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.748154 rxts = 1199377711.45769 txts = 1199377711.457742 offset 56.70598435 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.755922 rxts = 1199377711.466313 txts = 1199377711.466348 offset 56.7064172 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.76451 rxts = 1199377711.473845 txts = 1199377711.47388 offset 56.70550835 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.772819 rxts = 1199377711.483832 txts = 1199377711.483859 offset 56.70550382 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.784468 rxts = 1199377711.496182 txts = 1199377711.496194 offset 56.70548892 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.797513 rxts = 1199377711.508051 txts = 1199377711.508061 offset 56.70531833 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.808561 rxts = 1199377711.522168 txts = 1199377711.52218 offset 56.70665574 best server selected: peer 1273064242 Segmentation Fault (core dumped) Here's the dbx traceback from check_ntp: =>[1] offset_request(host = 0x36aa0 "1.us.pool.ntp.org", status = 0xffbffad4), line 482 in "check_ntp.c" [2] main(argc = 6, argv = 0xffbffb44), line 778 in "check_ntp.c" ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-01-03 07:39 Message: Logged In: YES user_id=375623 Originator: NO Hi, I'm the author of check_ntp_time and it's mostly based on check_ntp (written by Sean Finney). The specific place where it segfaults (offset_request function) hasn't been modified so this should apply to check_ntp.c as well. Could you confirm running check_ntp with the same arguments does the same segfault? Also I can't reproduce the bug on my Linux and Solaris boxes and FreeBSD VM. Does it happens all the time? Is it's still happening? To debug further I will need the full verbose output of the plug-in ("-vvv" instead of "-v"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862300&group_id=29880 From noreply at sourceforge.net Sat Jan 5 01:13:49 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Jan 2008 16:13:49 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1864225 ] check_procs under SunOS 5.10 broken Message-ID: Bugs item #1864225, was opened at 2008-01-04 22:37 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1864225&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs under SunOS 5.10 broken Initial Comment: Hi, i just compiled the 4.11 plugins on a $ uname -a SunOS spnb51 5.10 Generic_118833-24 sun4v sparc SUNW,Sun-Fire-T200 and found that check_procs does not work correctly. $ ps -ef | grep cron root 15100 1 0 Nov 08 ? 1:06 /usr/sbin/cron $ /usr/ucb/ps -alxwwn | grep cron 0 0 15100 1 0 59 20 2784 1048 60015774482 S ? 1:06 /usr/sbin/cron Cron is running, but.... check_procs -w :10 -c 1: -C cron PROCS CRITICAL: 0 processes with command name '/usr/sbin/cron' Running check-procs with -vvv shows, that it uses /usr/ucb/ps -alxwwn and actually parses the right line proc#=0 uid=0 vsz=2784 rss=1048 pid=15100 ppid=1 pcpu=0.00 stat=S etime= prog= args=/usr/sbin/cron but as you see, prog is empty and what should be prog is recognized as argument. Please change the configure.in (the buggy lines in configure are 24967 ff) so that it reads: ac_cv_ps_varlist="&procuid,&procpid,&procppid,&procpcpu,&procvsz,&procrs s,procstat,procprog,&pos" ac_cv_ps_command="/usr/ucb/ps -alxwwn" ac_cv_ps_format="%*s %d %d %d %d %*d %*d %d %d%*[ 0123456789abcdef]%[OSR ZT]%*s %*s %s %n" ac_cv_ps_cols=9 (add procprog to the varlist, add a %s at the end of format and increase cols) Then it looks good: $ check_procs -w :10 -c 1: -C cron PROCS OK: 1 process with command name 'cron' Greetings from Munich, Gerhard ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2008-01-05 01:13 Message: Logged In: YES user_id=1694341 Originator: NO Hi Gerhard, Are you sure this is valid for all operating systems where uname -s returns SunOS? I guess this (mis-)behaviour is not new in 1.4.11, right? Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1864225&group_id=29880 From noreply at sourceforge.net Sat Jan 5 02:01:06 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Jan 2008 17:01:06 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1864225 ] check_procs under SunOS 5.10 broken Message-ID: Bugs item #1864225, was opened at 2008-01-04 22:37 Message generated for change (Comment added) made by lausser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1864225&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs under SunOS 5.10 broken Initial Comment: Hi, i just compiled the 4.11 plugins on a $ uname -a SunOS spnb51 5.10 Generic_118833-24 sun4v sparc SUNW,Sun-Fire-T200 and found that check_procs does not work correctly. $ ps -ef | grep cron root 15100 1 0 Nov 08 ? 1:06 /usr/sbin/cron $ /usr/ucb/ps -alxwwn | grep cron 0 0 15100 1 0 59 20 2784 1048 60015774482 S ? 1:06 /usr/sbin/cron Cron is running, but.... check_procs -w :10 -c 1: -C cron PROCS CRITICAL: 0 processes with command name '/usr/sbin/cron' Running check-procs with -vvv shows, that it uses /usr/ucb/ps -alxwwn and actually parses the right line proc#=0 uid=0 vsz=2784 rss=1048 pid=15100 ppid=1 pcpu=0.00 stat=S etime= prog= args=/usr/sbin/cron but as you see, prog is empty and what should be prog is recognized as argument. Please change the configure.in (the buggy lines in configure are 24967 ff) so that it reads: ac_cv_ps_varlist="&procuid,&procpid,&procppid,&procpcpu,&procvsz,&procrs s,procstat,procprog,&pos" ac_cv_ps_command="/usr/ucb/ps -alxwwn" ac_cv_ps_format="%*s %d %d %d %d %*d %*d %d %d%*[ 0123456789abcdef]%[OSR ZT]%*s %*s %s %n" ac_cv_ps_cols=9 (add procprog to the varlist, add a %s at the end of format and increase cols) Then it looks good: $ check_procs -w :10 -c 1: -C cron PROCS OK: 1 process with command name 'cron' Greetings from Munich, Gerhard ---------------------------------------------------------------------- >Comment By: gerhard lausser (lausser) Date: 2008-01-05 02:01 Message: Logged In: YES user_id=613416 Originator: YES Hi Matthias, the last release i compiled on this machine was 1.4.2 and at that time configure decided to use /usr/bin/ps. I can try a 1.4.10 tomorrow but i am sure, it is also broken. I currently look at configure.in line 519. Particularly noticeable is the missing procprog variable in the ac_cv_ps_format. As one can see in the egrep line above, there _is_ a COMMAND field in the output, but the sscanf will not catch it. Gerhard p.s. this ps_format is not used for SunOS in general, only for SunOS whose /usr/ucb/ps -alxwwn shows the expected output format. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-01-05 01:13 Message: Logged In: YES user_id=1694341 Originator: NO Hi Gerhard, Are you sure this is valid for all operating systems where uname -s returns SunOS? I guess this (mis-)behaviour is not new in 1.4.11, right? Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1864225&group_id=29880 From noreply at sourceforge.net Sat Jan 5 02:07:49 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Jan 2008 17:07:49 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1724052 ] check_dns: sort address data Message-ID: Patches item #1724052, was opened at 2007-05-23 12:27 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1724052&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: Matthias Urlichs (smurf) >Assigned to: Matthias Eble (psychotrahe) Summary: check_dns: sort address data Initial Comment: DNs reports multiple addresses in random order. Therefore, sort them (for checking with "-a"). ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2008-01-05 02:07 Message: Logged In: YES user_id=1694341 Originator: NO Hi Matthias, this is now applied to svn. Thanks for your patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1724052&group_id=29880 From noreply at sourceforge.net Sat Jan 5 02:08:20 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Jan 2008 17:08:20 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1724055 ] check_dns: does not sort address data Message-ID: Bugs item #1724055, was opened at 2007-05-23 12:29 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1724055&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: Accepted Priority: 5 Private: No Submitted By: Matthias Urlichs (smurf) >Assigned to: Matthias Eble (psychotrahe) Summary: check_dns: does not sort address data Initial Comment: DNS reports adreses in random order. Therefore, the "-a" option to check_dns, which is supposed to verify that the data returned is what's expected, is worse than useless for multi-homed systems. Patch 1724052 has a fix. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-01-05 02:08 Message: Logged In: YES user_id=1694341 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=1724055&group_id=29880 From noreply at sourceforge.net Sat Jan 5 02:08:49 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Jan 2008 17:08:49 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1724055 ] check_dns: does not sort address data Message-ID: Bugs item #1724055, was opened at 2007-05-23 12:29 Message generated for change (Settings changed) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1724055&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: Accepted Priority: 5 Private: No Submitted By: Matthias Urlichs (smurf) Assigned to: Matthias Eble (psychotrahe) Summary: check_dns: does not sort address data Initial Comment: DNS reports adreses in random order. Therefore, the "-a" option to check_dns, which is supposed to verify that the data returned is what's expected, is worse than useless for multi-homed systems. Patch 1724052 has a fix. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-01-05 02:08 Message: Logged In: YES user_id=1694341 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=1724055&group_id=29880 From noreply at sourceforge.net Sat Jan 5 02:16:42 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Jan 2008 17:16:42 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1852201 ] check_dns: added -o option to sort returned addresses Message-ID: Patches item #1852201, was opened at 2007-12-17 11:02 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1852201&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Thiago Figueiro (thiagocsf) Assigned to: Nobody/Anonymous (nobody) Summary: check_dns: added -o option to sort returned addresses Initial Comment: On round-robin setups, DNS queries will return addresses on a different order on each request. This renders the -a option useless. The attached patch will add option -o to sort the returned addresses, making -a option useful again. For more info, please see http://microrants.blogspot.com/2007/11/checking-your-round-robin-dns-with.html Patch against Plugin Version (-V output): 1.4.10 Plugin Name: check_dns Example Plugin Commandline: check_dns -H google.com.au -o -a 72.14.203.104,72.14.207.104,72.14.235.104 Tested on operating system: Debian Etch, Solaris 10 Tested on architecture: i686, sparc Tested with compiler: gcc 4.2.3, Sun's crazy-ass compiler (can't remember the version) ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2008-01-05 02:16 Message: Logged In: YES user_id=1694341 Originator: NO Hi Thiago, thanks for your patch, I've just applied another patch from the tracker to svn that does nearly the same thing. With the other one -o isn't needed at all since addresses can be sorted any time. Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1852201&group_id=29880 From noreply at sourceforge.net Sat Jan 5 04:32:06 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Jan 2008 19:32:06 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1862300 ] check_ntp_time segfault in 1.4.11 Message-ID: Bugs item #1862300, was opened at 2008-01-02 11:39 Message generated for change (Comment added) made by digitalruin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862300&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: digitalruin (digitalruin) Assigned to: Thomas Guyot (dermoth) Summary: check_ntp_time segfault in 1.4.11 Initial Comment: Hi, I'm running 1.4.11 on a Solaris 9 setup and check_ntp_time seems to have a segfault issue. This only happens when running it against an ntp pool, not an individual host. See below: /usr/local/nagios/libexec$ ./check_ntp_time -H 0.us.pool.ntp.org -w 60 -c 120 Segmentation Fault /usr/local/nagios/libexec$ ./check_ntp_time -v -H 0.us.pool.ntp.org -w 60 -c 120 sending request to peer 0 sending request to peer 1 response from peer 0: offset 54.24633014 sending request to peer 0 response from peer 1: offset 54.23421776 . . . response from peer 4: offset 54.23087406 sending request to peer 4 response from peer 4: offset 54.23018897 sending request to peer 4 response from peer 4: offset 54.23138392 Segmentation Fault Here's the truss output: sending request to peer 4 write(1, " s e n d i n g r e q u".., 26) = 26 write(8, "E3\004FA\001\0\0\001\0\0".., 48) = 48 poll(0x00034298, 5, 100) = 1 read(8, " $0104ED\0\0\0\0\0\0\011".., 48) = 48 response from peer 4: offset 54.24180388 write(1, " r e s p o n s e f r o".., 41) = 41 Incurred fault #6, FLTBOUNDS %pc = 0x00015FB4 siginfo: SIGSEGV SEGV_MAPERR addr=0x7FC1E3A4 Received signal #11, SIGSEGV [default] siginfo: SIGSEGV SEGV_MAPERR addr=0x7FC1E3A4 And the traceback: /usr/local/nagios/libexec# dbx /usr/local/nagios/libexec/check_ntp_time Reading check_ntp_time Reading ld.so.1 Reading libresolv.so.2 Reading libm.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libc.so.1 Reading libdl.so.1 Reading libmp.so.2 Reading libc_psr.so.1 (dbx) run -H 0.us.pool.ntp.org -w 60 -c 120 Running: check_ntp_time -H 0.us.pool.ntp.org -w 60 -c 120 (process id 12120) signal SEGV (no mapping at the fault address) in offset_request at line 427 in file "check_ntp_time.c" (dbx) where =>[1] offset_request(host = 0x354b0 "0.us.pool.ntp.org", status = 0xffbffae4), line 427 in "check_ntp_time.c" [2] main(argc = 7, argv = 0xffbffb54), line 554 in "check_ntp_time.c" ---------------------------------------------------------------------- >Comment By: digitalruin (digitalruin) Date: 2008-01-04 22:32 Message: Logged In: YES user_id=1609785 Originator: YES Works great! Thanks for the fix. Just remember that it still exists in the other ntp plugins based off of the original check_ntp code. I'm not sure if that maintainer is checking this, but you might want to let them know ;) ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-01-04 19:08 Message: Logged In: YES user_id=375623 Originator: NO P.S.: Apply the last patch against a fresh copy of check_ntp_time.c from Nagios-plugins 1.4.11. ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-01-04 19:07 Message: Logged In: YES user_id=375623 Originator: NO I got it. "int candidates[5]" is a 5-integer array, candidates[0] to candidates[4]. At line 277 (check_ntp_time v1861 (nagios-plugins 1.4.11)) where the function reorders the candidates it starts at candidates[5] which is out of bounds. In your case it was overwriting cserver putting random data in it. The attached patch should fix it; can you confirm? Thanks for your help in debugging this. This is greatly appreciated. File Added: check_ntp_time.best_offset_server_fix.patch ---------------------------------------------------------------------- Comment By: digitalruin (digitalruin) Date: 2008-01-04 14:28 Message: Logged In: YES user_id=1609785 Originator: YES Here you go : # ./check_ntp_time -vvv -H 1.pool.ntp.org -w 120 -c 300 Found 5 peers to check sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0445709228515625 rtdisp = 0.0609893798828125 refid = c63c16f0 refts = 1199472719.993338 origts = 1199474568.474856 rxts = 1199474627.965969 txts = 1199474627.966372 offset 59.46767855 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0445709228515625 rtdisp = 0.0609893798828125 refid = c63c16f0 refts = 1199472719.993338 origts = 1199474568.528016 rxts = 1199474628.018613 txts = 1199474628.01866 offset 59.46698618 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0445709228515625 rtdisp = 0.0609893798828125 refid = c63c16f0 refts = 1199472719.993338 origts = 1199474568.580226 rxts = 1199474628.071063 txts = 1199474628.071103 offset 59.4676069 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0445709228515625 rtdisp = 0.0609893798828125 refid = c63c16f0 refts = 1199472719.993338 origts = 1199474568.627356 rxts = 1199474628.118044 txts = 1199474628.118088 offset 59.46739721 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0011444091796875 rtdisp = 0.04412841796875 refid = 40490009 refts = 1199473765.176361 origts = 1199474568.674596 rxts = 1199474628.163931 txts = 1199474628.163948 offset 59.46385014 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0011444091796875 rtdisp = 0.0441436767578125 refid = 40490009 refts = 1199473765.176361 origts = 1199474568.726196 rxts = 1199474628.215072 txts = 1199474628.215088 offset 59.46364021 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0011444091796875 rtdisp = 0.0441436767578125 refid = 40490009 refts = 1199473765.176361 origts = 1199474568.77732 rxts = 1199474628.26508 txts = 1199474628.265097 offset 59.46305585 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0011444091796875 rtdisp = 0.0441436767578125 refid = 40490009 refts = 1199473765.176361 origts = 1199474568.827371 rxts = 1199474628.319556 txts = 1199474628.319573 offset 59.46525288 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.01885986328125 rtdisp = 0.0413818359375 refid = d1510907 refts = 1199473265.973837 origts = 1199474568.881858 rxts = 1199474628.396212 txts = 1199474628.396236 offset 59.47221529 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.01885986328125 rtdisp = 0.0413818359375 refid = d1510907 refts = 1199473265.973837 origts = 1199474568.966791 rxts = 1199474628.480412 txts = 1199474628.480432 offset 59.4719218 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.01885986328125 rtdisp = 0.0413818359375 refid = d1510907 refts = 1199473265.973837 origts = 1199474569.050913 rxts = 1199474628.564735 txts = 1199474628.564755 offset 59.47202778 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.01885986328125 rtdisp = 0.0413818359375 refid = d1510907 refts = 1199473265.973837 origts = 1199474569.135167 rxts = 1199474628.648808 txts = 1199474628.648838 offset 59.47195649 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0023040771484375 rtdisp = 0.02984619140625 refid = d133a1ee refts = 1199473719.765392 origts = 1199474569.219201 rxts = 1199474628.696106 txts = 1199474628.696119 offset 59.47111976 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0023040771484375 rtdisp = 0.02984619140625 refid = d133a1ee refts = 1199473719.765392 origts = 1199474569.231406 rxts = 1199474628.708094 txts = 1199474628.708102 offset 59.47123277 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0023040771484375 rtdisp = 0.02984619140625 refid = d133a1ee refts = 1199473719.765392 origts = 1199474569.242943 rxts = 1199474628.719963 txts = 1199474628.719971 offset 59.4704082 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0023040771484375 rtdisp = 0.02984619140625 refid = d133a1ee refts = 1199473719.765392 origts = 1199474569.257685 rxts = 1199474628.734954 txts = 1199474628.734963 offset 59.47152829 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 3 poll = 16 precision = 9.53674e-07 rtdelay = 0.12030029296875 rtdisp = 0.0667724609375 refid = d04cf473 refts = 1199473596.941478 origts = 1199474569.269815 rxts = 1199474628.795154 txts = 1199474628.795205 offset 59.46338224 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 3 poll = 16 precision = 9.53674e-07 rtdelay = 0.12030029296875 rtdisp = 0.0667877197265625 refid = d04cf473 refts = 1199473596.941478 origts = 1199474569.39442 rxts = 1199474628.920017 txts = 1199474628.920062 offset 59.46323884 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 3 poll = 16 precision = 9.53674e-07 rtdelay = 0.12030029296875 rtdisp = 0.0667877197265625 refid = d04cf473 refts = 1199473596.941478 origts = 1199474569.519803 rxts = 1199474629.045887 txts = 1199474629.045933 offset 59.46334183 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 3 poll = 16 precision = 9.53674e-07 rtdelay = 0.12030029296875 rtdisp = 0.0667877197265625 refid = d04cf473 refts = 1199473596.941478 origts = 1199474569.645956 rxts = 1199474629.173512 txts = 1199474629.173553 offset 59.46439874 best_offset_server() line 253: nservers=5 best_offset_server() line 257: cserver=0 best_offset_server() line 298: candidates[0]=0 (csize=0) best_offset_server() line 257: cserver=1 best_offset_server() line 269: slist[1].stratum <= slist[0].stratum best_offset_server() line 273: slist[1].rtdisp <= slist[0].rtdisp best_offset_server() line 277: slist[1].rtdelay < slist[0].rtdelay best_offset_server() line 291: candidates[5]=candidates[5-1] (i=0, csize=1) best_offset_server() line 291: candidates[4]=candidates[4-1] (i=0, csize=1) best_offset_server() line 291: candidates[3]=candidates[3-1] (i=0, csize=1) best_offset_server() line 291: candidates[2]=candidates[2-1] (i=0, csize=1) best_offset_server() line 291: candidates[1]=candidates[1-1] (i=0, csize=1) best_offset_server() line 298: candidates[0]=-246736175 (csize=1) best_offset_server() line 257: cserver=-246736174 Segmentation Fault (core dumped) ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-01-04 01:54 Message: Logged In: YES user_id=375623 Originator: NO > best server selected: peer 1273064242 This is plain wrong. This should be between 0 and 5 and is definitely why you get a segfault. How you end up with that value is mystery though. Can you please apply the attached patch (check_ntp_time.mega_debug.patch) and send again the full output of -vvv? The patch basically trace every operation in best_offset_server and print out what's going on. Thanks File Added: check_ntp_time.mega_debug.patch ---------------------------------------------------------------------- Comment By: digitalruin (digitalruin) Date: 2008-01-03 11:41 Message: Logged In: YES user_id=1609785 Originator: YES Here, I was able to pull a more detailed traceback with the core dump. Definitely the function that selects the best server: =>[1] best_offset_server(slist = 0x354a8, nservers = 5), line 310 in "check_ntp.c" [2] offset_request(host = 0x36aa0 "1.us.pool.ntp.org", status = 0xffbffb5c), line 477 in "check_ntp.c" [3] main(argc = 8, argv = 0xffbffbcc), line 778 in "check_ntp.c" ---------------------------------------------------------------------- Comment By: digitalruin (digitalruin) Date: 2008-01-03 11:38 Message: Logged In: YES user_id=1609785 Originator: YES No problem. Yeah it's the same in check_ntp. I actually had it pass once without failing, but I think it was due to the server only having a two or three choices. With full verbose I can see that it segfaults when choosing the best server to go with. If it has xn it segfaults during the decision. So to simplify, no segfault when runnng the check against one ntp server. Possibly no segfault when running it against a pool that only consists of three or four. Always segfaults when hitting a large pool server like ntp.org. Here's the info... I ran it twice with both two different ntp hubs and it failed: # ./check_ntp -vvv -H 1.us.pool.ntp.org -w 60 -c 120 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377653.767585 rxts = 1199377710.512649 txts = 1199377710.512664 offset 56.70649898 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377653.850921 rxts = 1199377710.594606 txts = 1199377710.594627 offset 56.70579767 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377653.927373 rxts = 1199377710.670819 txts = 1199377710.670839 offset 56.70584822 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377654.003221 rxts = 1199377710.747487 txts = 1199377710.747508 offset 56.70499885 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.034637451171875 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.082479 rxts = 1199377710.829896 txts = 1199377710.82992 offset 56.70595193 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.034637451171875 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.166106 rxts = 1199377710.913108 txts = 1199377710.913127 offset 56.70589066 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.034637451171875 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.248994 rxts = 1199377710.996055 txts = 1199377710.996118 offset 56.70593584 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.0346527099609375 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.331923 rxts = 1199377711.078835 txts = 1199377711.078882 offset 56.70586824 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.414673 rxts = 1199377711.154322 txts = 1199377711.154334 offset 56.69950116 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.495628 rxts = 1199377711.234703 txts = 1199377711.234713 offset 56.6990782 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.576271 rxts = 1199377711.31571 txts = 1199377711.315721 offset 56.69919193 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.657396 rxts = 1199377711.396339 txts = 1199377711.39635 offset 56.69902682 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.737869 rxts = 1199377711.4489 txts = 1199377711.448967 offset 56.70623863 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.748154 rxts = 1199377711.45769 txts = 1199377711.457742 offset 56.70598435 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.755922 rxts = 1199377711.466313 txts = 1199377711.466348 offset 56.7064172 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.76451 rxts = 1199377711.473845 txts = 1199377711.47388 offset 56.70550835 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.772819 rxts = 1199377711.483832 txts = 1199377711.483859 offset 56.70550382 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.784468 rxts = 1199377711.496182 txts = 1199377711.496194 offset 56.70548892 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.797513 rxts = 1199377711.508051 txts = 1199377711.508061 offset 56.70531833 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.808561 rxts = 1199377711.522168 txts = 1199377711.52218 offset 56.70665574 best server selected: peer 1273064242 Segmentation Fault (core dumped) Here's the dbx traceback from check_ntp: =>[1] offset_request(host = 0x36aa0 "1.us.pool.ntp.org", status = 0xffbffad4), line 482 in "check_ntp.c" [2] main(argc = 6, argv = 0xffbffb44), line 778 in "check_ntp.c" ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-01-03 07:39 Message: Logged In: YES user_id=375623 Originator: NO Hi, I'm the author of check_ntp_time and it's mostly based on check_ntp (written by Sean Finney). The specific place where it segfaults (offset_request function) hasn't been modified so this should apply to check_ntp.c as well. Could you confirm running check_ntp with the same arguments does the same segfault? Also I can't reproduce the bug on my Linux and Solaris boxes and FreeBSD VM. Does it happens all the time? Is it's still happening? To debug further I will need the full verbose output of the plug-in ("-vvv" instead of "-v"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862300&group_id=29880 From noreply at sourceforge.net Sat Jan 5 10:46:33 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Jan 2008 01:46:33 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1864404 ] check_smtp --starttls miscalculates timezones Message-ID: Bugs item #1864404, was opened at 2008-01-05 04:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1864404&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: David Miller (justdave72) Assigned to: Nobody/Anonymous (nobody) Summary: check_smtp --starttls miscalculates timezones Initial Comment: check_smtp (nagios-plugins 1.4.9) 1.59 When running check_smtp with --starttls or -S, the certificate expiration time retrieved from the certificate is always expressed in GMT, but check_smtp compares it to the local timezone instead of GMT. For example, I'm in -0800 and my certificate expired a couple hours ago, but check_smtp claims "WARNING - Certificate expires today (01/05/2008 05:40)." instead of a CRITICAL that it's already expired. Time on the server is Sat Jan 5 01:44:42 PST 2008 (which is 09:44 GMT, past the expiration time) openssl s_client tells me: Verify return code: 10 (certificate has expired) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1864404&group_id=29880 From noreply at sourceforge.net Sat Jan 5 15:06:24 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Jan 2008 06:06:24 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1862300 ] check_ntp_time segfault in 1.4.11 Message-ID: Bugs item #1862300, was opened at 2008-01-02 11:39 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862300&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: digitalruin (digitalruin) Assigned to: Thomas Guyot (dermoth) Summary: check_ntp_time segfault in 1.4.11 Initial Comment: Hi, I'm running 1.4.11 on a Solaris 9 setup and check_ntp_time seems to have a segfault issue. This only happens when running it against an ntp pool, not an individual host. See below: /usr/local/nagios/libexec$ ./check_ntp_time -H 0.us.pool.ntp.org -w 60 -c 120 Segmentation Fault /usr/local/nagios/libexec$ ./check_ntp_time -v -H 0.us.pool.ntp.org -w 60 -c 120 sending request to peer 0 sending request to peer 1 response from peer 0: offset 54.24633014 sending request to peer 0 response from peer 1: offset 54.23421776 . . . response from peer 4: offset 54.23087406 sending request to peer 4 response from peer 4: offset 54.23018897 sending request to peer 4 response from peer 4: offset 54.23138392 Segmentation Fault Here's the truss output: sending request to peer 4 write(1, " s e n d i n g r e q u".., 26) = 26 write(8, "E3\004FA\001\0\0\001\0\0".., 48) = 48 poll(0x00034298, 5, 100) = 1 read(8, " $0104ED\0\0\0\0\0\0\011".., 48) = 48 response from peer 4: offset 54.24180388 write(1, " r e s p o n s e f r o".., 41) = 41 Incurred fault #6, FLTBOUNDS %pc = 0x00015FB4 siginfo: SIGSEGV SEGV_MAPERR addr=0x7FC1E3A4 Received signal #11, SIGSEGV [default] siginfo: SIGSEGV SEGV_MAPERR addr=0x7FC1E3A4 And the traceback: /usr/local/nagios/libexec# dbx /usr/local/nagios/libexec/check_ntp_time Reading check_ntp_time Reading ld.so.1 Reading libresolv.so.2 Reading libm.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libc.so.1 Reading libdl.so.1 Reading libmp.so.2 Reading libc_psr.so.1 (dbx) run -H 0.us.pool.ntp.org -w 60 -c 120 Running: check_ntp_time -H 0.us.pool.ntp.org -w 60 -c 120 (process id 12120) signal SEGV (no mapping at the fault address) in offset_request at line 427 in file "check_ntp_time.c" (dbx) where =>[1] offset_request(host = 0x354b0 "0.us.pool.ntp.org", status = 0xffbffae4), line 427 in "check_ntp_time.c" [2] main(argc = 7, argv = 0xffbffb54), line 554 in "check_ntp_time.c" ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2008-01-05 09:06 Message: Logged In: YES user_id=375623 Originator: NO The patch apply cleanly to the check_ntp.c as well; just specify the file on the command line like this: patch -p0 plugins/check_ntp.c best server selected: peer 1273064242 This is plain wrong. This should be between 0 and 5 and is definitely why you get a segfault. How you end up with that value is mystery though. Can you please apply the attached patch (check_ntp_time.mega_debug.patch) and send again the full output of -vvv? The patch basically trace every operation in best_offset_server and print out what's going on. Thanks File Added: check_ntp_time.mega_debug.patch ---------------------------------------------------------------------- Comment By: digitalruin (digitalruin) Date: 2008-01-03 11:41 Message: Logged In: YES user_id=1609785 Originator: YES Here, I was able to pull a more detailed traceback with the core dump. Definitely the function that selects the best server: =>[1] best_offset_server(slist = 0x354a8, nservers = 5), line 310 in "check_ntp.c" [2] offset_request(host = 0x36aa0 "1.us.pool.ntp.org", status = 0xffbffb5c), line 477 in "check_ntp.c" [3] main(argc = 8, argv = 0xffbffbcc), line 778 in "check_ntp.c" ---------------------------------------------------------------------- Comment By: digitalruin (digitalruin) Date: 2008-01-03 11:38 Message: Logged In: YES user_id=1609785 Originator: YES No problem. Yeah it's the same in check_ntp. I actually had it pass once without failing, but I think it was due to the server only having a two or three choices. With full verbose I can see that it segfaults when choosing the best server to go with. If it has xn it segfaults during the decision. So to simplify, no segfault when runnng the check against one ntp server. Possibly no segfault when running it against a pool that only consists of three or four. Always segfaults when hitting a large pool server like ntp.org. Here's the info... I ran it twice with both two different ntp hubs and it failed: # ./check_ntp -vvv -H 1.us.pool.ntp.org -w 60 -c 120 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377653.767585 rxts = 1199377710.512649 txts = 1199377710.512664 offset 56.70649898 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377653.850921 rxts = 1199377710.594606 txts = 1199377710.594627 offset 56.70579767 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377653.927373 rxts = 1199377710.670819 txts = 1199377710.670839 offset 56.70584822 sending request to peer 0 response from peer 0: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.02667236328125 rtdisp = 0.0340576171875 refid = 4524e00f refts = 1199377286.33416 origts = 1199377654.003221 rxts = 1199377710.747487 txts = 1199377710.747508 offset 56.70499885 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.034637451171875 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.082479 rxts = 1199377710.829896 txts = 1199377710.82992 offset 56.70595193 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.034637451171875 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.166106 rxts = 1199377710.913108 txts = 1199377710.913127 offset 56.70589066 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.034637451171875 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.248994 rxts = 1199377710.996055 txts = 1199377710.996118 offset 56.70593584 sending request to peer 1 response from peer 1: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 1.90735e-06 rtdelay = 0.011322021484375 rtdisp = 0.0346527099609375 refid = d8dafeca refts = 1199376447.026551 origts = 1199377654.331923 rxts = 1199377711.078835 txts = 1199377711.078882 offset 56.70586824 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.414673 rxts = 1199377711.154322 txts = 1199377711.154334 offset 56.69950116 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.495628 rxts = 1199377711.234703 txts = 1199377711.234713 offset 56.6990782 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.576271 rxts = 1199377711.31571 txts = 1199377711.315721 offset 56.69919193 sending request to peer 2 response from peer 2: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.008636474609375 rtdisp = 0.0222625732421875 refid = 84ef0106 refts = 1199377322.977451 origts = 1199377654.657396 rxts = 1199377711.396339 txts = 1199377711.39635 offset 56.69902682 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.737869 rxts = 1199377711.4489 txts = 1199377711.448967 offset 56.70623863 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.748154 rxts = 1199377711.45769 txts = 1199377711.457742 offset 56.70598435 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.755922 rxts = 1199377711.466313 txts = 1199377711.466348 offset 56.7064172 sending request to peer 3 response from peer 3: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0074005126953125 rtdisp = 0.028106689453125 refid = 121a0469 refts = 1199376997.261332 origts = 1199377654.76451 rxts = 1199377711.473845 txts = 1199377711.47388 offset 56.70550835 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.772819 rxts = 1199377711.483832 txts = 1199377711.483859 offset 56.70550382 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.784468 rxts = 1199377711.496182 txts = 1199377711.496194 offset 56.70548892 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.797513 rxts = 1199377711.508051 txts = 1199377711.508061 offset 56.70531833 sending request to peer 4 response from peer 4: packet contents: flags: 0x24 li=0 (0x00) vn=4 (0x20) mode=4 (0x04) stratum = 2 poll = 16 precision = 9.53674e-07 rtdelay = 0.0049896240234375 rtdisp = 0.0347747802734375 refid = d133a1ee refts = 1199376808.487007 origts = 1199377654.808561 rxts = 1199377711.522168 txts = 1199377711.52218 offset 56.70665574 best server selected: peer 1273064242 Segmentation Fault (core dumped) Here's the dbx traceback from check_ntp: =>[1] offset_request(host = 0x36aa0 "1.us.pool.ntp.org", status = 0xffbffad4), line 482 in "check_ntp.c" [2] main(argc = 6, argv = 0xffbffb44), line 778 in "check_ntp.c" ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-01-03 07:39 Message: Logged In: YES user_id=375623 Originator: NO Hi, I'm the author of check_ntp_time and it's mostly based on check_ntp (written by Sean Finney). The specific place where it segfaults (offset_request function) hasn't been modified so this should apply to check_ntp.c as well. Could you confirm running check_ntp with the same arguments does the same segfault? Also I can't reproduce the bug on my Linux and Solaris boxes and FreeBSD VM. Does it happens all the time? Is it's still happening? To debug further I will need the full verbose output of the plug-in ("-vvv" instead of "-v"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1862300&group_id=29880 From noreply at sourceforge.net Sat Jan 5 15:45:29 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Jan 2008 06:45:29 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1864501 ] check_procs under SunOS 5.10 broken Message-ID: Bugs item #1864501, was opened at 2008-01-05 15:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1864501&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs under SunOS 5.10 broken Initial Comment: Hi, i just compiled the 4.11 plugins on a $ uname -a SunOS spnb51 5.10 Generic_118833-24 sun4v sparc SUNW,Sun-Fire-T200 and found that check_procs does not work correctly. $ ps -ef | grep cron root 15100 1 0 Nov 08 ? 1:06 /usr/sbin/cron $ /usr/ucb/ps -alxwwn | grep cron 0 0 15100 1 0 59 20 2784 1048 60015774482 S ? 1:06 /usr/sbin/cron Cron is running, but.... check_procs -w :10 -c 1: -C cron PROCS CRITICAL: 0 processes with command name '/usr/sbin/cron' Running check-procs with -vvv shows, that it uses /usr/ucb/ps -alxwwn and actually parses the right line proc#=0 uid=0 vsz=2784 rss=1048 pid=15100 ppid=1 pcpu=0.00 stat=S etime= prog= args=/usr/sbin/cron but as you see, prog is empty and what should be prog is recognized as argument. Please change the configure.in (the buggy lines in configure are 24967 ff) so that it reads: ac_cv_ps_varlist="&procuid,&procpid,&procppid,&procpcpu,&procvsz,&procrs s,procstat,procprog,&pos" ac_cv_ps_command="/usr/ucb/ps -alxwwn" ac_cv_ps_format="%*s %d %d %d %d %*d %*d %d %d%*[ 0123456789abcdef]%[OSR ZT]%*s %*s %s %n" ac_cv_ps_cols=9 (add procprog to the varlist, add a %s at the end of format and increase cols) Then it looks good: $ check_procs -w :10 -c 1: -C cron PROCS OK: 1 process with command name 'cron' Greetings from Munich, Gerhard ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1864501&group_id=29880 From noreply at sourceforge.net Sat Jan 5 15:47:02 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Jan 2008 06:47:02 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1864501 ] check_procs under SunOS 5.10 broken Message-ID: Bugs item #1864501, was opened at 2008-01-05 15:45 Message generated for change (Settings changed) made by lausser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1864501&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None >Status: Deleted Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs under SunOS 5.10 broken Initial Comment: Hi, i just compiled the 4.11 plugins on a $ uname -a SunOS spnb51 5.10 Generic_118833-24 sun4v sparc SUNW,Sun-Fire-T200 and found that check_procs does not work correctly. $ ps -ef | grep cron root 15100 1 0 Nov 08 ? 1:06 /usr/sbin/cron $ /usr/ucb/ps -alxwwn | grep cron 0 0 15100 1 0 59 20 2784 1048 60015774482 S ? 1:06 /usr/sbin/cron Cron is running, but.... check_procs -w :10 -c 1: -C cron PROCS CRITICAL: 0 processes with command name '/usr/sbin/cron' Running check-procs with -vvv shows, that it uses /usr/ucb/ps -alxwwn and actually parses the right line proc#=0 uid=0 vsz=2784 rss=1048 pid=15100 ppid=1 pcpu=0.00 stat=S etime= prog= args=/usr/sbin/cron but as you see, prog is empty and what should be prog is recognized as argument. Please change the configure.in (the buggy lines in configure are 24967 ff) so that it reads: ac_cv_ps_varlist="&procuid,&procpid,&procppid,&procpcpu,&procvsz,&procrs s,procstat,procprog,&pos" ac_cv_ps_command="/usr/ucb/ps -alxwwn" ac_cv_ps_format="%*s %d %d %d %d %*d %*d %d %d%*[ 0123456789abcdef]%[OSR ZT]%*s %*s %s %n" ac_cv_ps_cols=9 (add procprog to the varlist, add a %s at the end of format and increase cols) Then it looks good: $ check_procs -w :10 -c 1: -C cron PROCS OK: 1 process with command name 'cron' Greetings from Munich, Gerhard ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1864501&group_id=29880 From noreply at sourceforge.net Sat Jan 5 15:47:34 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Jan 2008 06:47:34 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1864501 ] check_procs under SunOS 5.10 broken Message-ID: Bugs item #1864501, was opened at 2008-01-05 15:45 Message generated for change (Comment added) made by lausser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1864501&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None Status: Deleted Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs under SunOS 5.10 broken Initial Comment: Hi, i just compiled the 4.11 plugins on a $ uname -a SunOS spnb51 5.10 Generic_118833-24 sun4v sparc SUNW,Sun-Fire-T200 and found that check_procs does not work correctly. $ ps -ef | grep cron root 15100 1 0 Nov 08 ? 1:06 /usr/sbin/cron $ /usr/ucb/ps -alxwwn | grep cron 0 0 15100 1 0 59 20 2784 1048 60015774482 S ? 1:06 /usr/sbin/cron Cron is running, but.... check_procs -w :10 -c 1: -C cron PROCS CRITICAL: 0 processes with command name '/usr/sbin/cron' Running check-procs with -vvv shows, that it uses /usr/ucb/ps -alxwwn and actually parses the right line proc#=0 uid=0 vsz=2784 rss=1048 pid=15100 ppid=1 pcpu=0.00 stat=S etime= prog= args=/usr/sbin/cron but as you see, prog is empty and what should be prog is recognized as argument. Please change the configure.in (the buggy lines in configure are 24967 ff) so that it reads: ac_cv_ps_varlist="&procuid,&procpid,&procppid,&procpcpu,&procvsz,&procrs s,procstat,procprog,&pos" ac_cv_ps_command="/usr/ucb/ps -alxwwn" ac_cv_ps_format="%*s %d %d %d %d %*d %*d %d %d%*[ 0123456789abcdef]%[OSR ZT]%*s %*s %s %n" ac_cv_ps_cols=9 (add procprog to the varlist, add a %s at the end of format and increase cols) Then it looks good: $ check_procs -w :10 -c 1: -C cron PROCS OK: 1 process with command name 'cron' Greetings from Munich, Gerhard ---------------------------------------------------------------------- >Comment By: gerhard lausser (lausser) Date: 2008-01-05 15:47 Message: Logged In: YES user_id=613416 Originator: YES Scheisse, wie krieg ich einen doppelten Eintrag wieder raus? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1864501&group_id=29880 From noreply at sourceforge.net Sat Jan 5 17:18:16 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Jan 2008 08:18:16 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1864550 ] check_swap: unresolved symbol when compiling under hpux11.11 Message-ID: Patches item #1864550, was opened at 2008-01-05 17:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1864550&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_swap: unresolved symbol when compiling under hpux11.11 Initial Comment: Hi, i tried to build plugins-1.4.11 on a hp-ux 11.11 machine, but it failed with: -1.4.11/plugins -lm ../lib/libnagiosplug.a ../gl/libgnu.a /usr/ccs/bin/ld: Unsatisfied symbols: floorf (first referenced in check_swap.o) (code) collect2: ld returned 1 exit status It looks like floorf is not known to this OS. I propose to replace the warn_size_bytes = floorf(warn_size_bytes); with warn_size_bytes = (float) floor(warn_size_bytes); which converts double to float. Attached is a patch which let me build the plugins successfully. Greetings from Munich, Gerhard ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1864550&group_id=29880 From noreply at sourceforge.net Sat Jan 5 19:08:51 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Jan 2008 10:08:51 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1864550 ] check_swap: unresolved symbol when compiling under hpux11.11 Message-ID: Patches item #1864550, was opened at 2008-01-05 17:18 Message generated for change (Comment added) made by lausser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1864550&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_swap: unresolved symbol when compiling under hpux11.11 Initial Comment: Hi, i tried to build plugins-1.4.11 on a hp-ux 11.11 machine, but it failed with: -1.4.11/plugins -lm ../lib/libnagiosplug.a ../gl/libgnu.a /usr/ccs/bin/ld: Unsatisfied symbols: floorf (first referenced in check_swap.o) (code) collect2: ld returned 1 exit status It looks like floorf is not known to this OS. I propose to replace the warn_size_bytes = floorf(warn_size_bytes); with warn_size_bytes = (float) floor(warn_size_bytes); which converts double to float. Attached is a patch which let me build the plugins successfully. Greetings from Munich, Gerhard ---------------------------------------------------------------------- >Comment By: gerhard lausser (lausser) Date: 2008-01-05 19:08 Message: Logged In: YES user_id=613416 Originator: YES Update: The same happens with AIX5.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1864550&group_id=29880 From noreply at sourceforge.net Sat Jan 5 19:35:49 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Jan 2008 10:35:49 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1864550 ] check_swap: unresolved symbol when compiling under hpux11.11 Message-ID: Patches item #1864550, was opened at 2008-01-05 17:18 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1864550&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_swap: unresolved symbol when compiling under hpux11.11 Initial Comment: Hi, i tried to build plugins-1.4.11 on a hp-ux 11.11 machine, but it failed with: -1.4.11/plugins -lm ../lib/libnagiosplug.a ../gl/libgnu.a /usr/ccs/bin/ld: Unsatisfied symbols: floorf (first referenced in check_swap.o) (code) collect2: ld returned 1 exit status It looks like floorf is not known to this OS. I propose to replace the warn_size_bytes = floorf(warn_size_bytes); with warn_size_bytes = (float) floor(warn_size_bytes); which converts double to float. Attached is a patch which let me build the plugins successfully. Greetings from Munich, Gerhard ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2008-01-05 19:35 Message: Logged In: YES user_id=1694341 Originator: NO Hi Gerhard, there already were some problems with floorf in the past. I guess it was used in check disk. As a workaround an own floorf function is defined in plugins/common.h but only for sun systems. There are two possibilities now: 1st: apply the changes as you suggested, remove floorf function in common.h and add a hint to developer guidelines to never use floorf again since it's not portable 2nd: add floorf detection to autoconf and forget about the portability issue Google claims that floorf is also not available on AIX and HP-UX (as you described). So I followed the comment in common.h and included floorf detection in configure.in. It'd be great if you could test if this fix works for you as well. We can then discuss which way we'll implement. Matthias $ svn diff configure.in plugins/common.h Index: configure.in =================================================================== --- configure.in (revision 1884) +++ configure.in (working copy) @@ -151,6 +151,7 @@ dnl check for math-related functions needing -lm AC_CHECK_HEADERS(math.h) AC_CHECK_LIB(m,floor,MATHLIBS="-lm") +AC_CHECK_LIB(m,floorf,[AC_DEFINE(HAVE_FLOORF,1,[Define HAVE_FLOORF if floorf is available])]) AC_SUBST(MATHLIBS) dnl Check for libtap, to run perl-like tests Index: plugins/common.h =================================================================== --- plugins/common.h (revision 1884) +++ plugins/common.h (working copy) @@ -186,8 +186,7 @@ }; #endif -/* Solaris does not have floorf, but floor works. Should probably be in configure */ -#if defined(__sun) || defined(__sun__) +#if !HAVE_FLOORF static inline float floorf (float x) { return floor(x); } #endif ---------------------------------------------------------------------- Comment By: gerhard lausser (lausser) Date: 2008-01-05 19:08 Message: Logged In: YES user_id=613416 Originator: YES Update: The same happens with AIX5.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1864550&group_id=29880 From noreply at sourceforge.net Sat Jan 5 21:18:18 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Jan 2008 12:18:18 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1864550 ] check_swap: unresolved symbol when compiling under hpux11.11 Message-ID: Patches item #1864550, was opened at 2008-01-05 17:18 Message generated for change (Comment added) made by lausser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1864550&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_swap: unresolved symbol when compiling under hpux11.11 Initial Comment: Hi, i tried to build plugins-1.4.11 on a hp-ux 11.11 machine, but it failed with: -1.4.11/plugins -lm ../lib/libnagiosplug.a ../gl/libgnu.a /usr/ccs/bin/ld: Unsatisfied symbols: floorf (first referenced in check_swap.o) (code) collect2: ld returned 1 exit status It looks like floorf is not known to this OS. I propose to replace the warn_size_bytes = floorf(warn_size_bytes); with warn_size_bytes = (float) floor(warn_size_bytes); which converts double to float. Attached is a patch which let me build the plugins successfully. Greetings from Munich, Gerhard ---------------------------------------------------------------------- >Comment By: gerhard lausser (lausser) Date: 2008-01-05 21:18 Message: Logged In: YES user_id=613416 Originator: YES It compiled successfully under hpux11.11 and after 2 hours of nearly becoming crazy finally powerpc-ibm-aix5.1.0.0. The problem with AIX5.1 was that even the "static inline float floorf...." was included (i checked it with a #error directive), in the end it still aborted with "unresolved floorf..". I think it is the GCC4.0.0 i found on this machine. After i removed the "inline" so that i had "static float floorf (float x) { return floor(x); }" it compiled without problems. I still prefer your solution Nr.2, but i strongly recommend to take the "inline" out, because i am sure, machines with these outdated OSes also have outdated compilers installed. Gerhard (with a lot more grey hair now) ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-01-05 19:35 Message: Logged In: YES user_id=1694341 Originator: NO Hi Gerhard, there already were some problems with floorf in the past. I guess it was used in check disk. As a workaround an own floorf function is defined in plugins/common.h but only for sun systems. There are two possibilities now: 1st: apply the changes as you suggested, remove floorf function in common.h and add a hint to developer guidelines to never use floorf again since it's not portable 2nd: add floorf detection to autoconf and forget about the portability issue Google claims that floorf is also not available on AIX and HP-UX (as you described). So I followed the comment in common.h and included floorf detection in configure.in. It'd be great if you could test if this fix works for you as well. We can then discuss which way we'll implement. Matthias $ svn diff configure.in plugins/common.h Index: configure.in =================================================================== --- configure.in (revision 1884) +++ configure.in (working copy) @@ -151,6 +151,7 @@ dnl check for math-related functions needing -lm AC_CHECK_HEADERS(math.h) AC_CHECK_LIB(m,floor,MATHLIBS="-lm") +AC_CHECK_LIB(m,floorf,[AC_DEFINE(HAVE_FLOORF,1,[Define HAVE_FLOORF if floorf is available])]) AC_SUBST(MATHLIBS) dnl Check for libtap, to run perl-like tests Index: plugins/common.h =================================================================== --- plugins/common.h (revision 1884) +++ plugins/common.h (working copy) @@ -186,8 +186,7 @@ }; #endif -/* Solaris does not have floorf, but floor works. Should probably be in configure */ -#if defined(__sun) || defined(__sun__) +#if !HAVE_FLOORF static inline float floorf (float x) { return floor(x); } #endif ---------------------------------------------------------------------- Comment By: gerhard lausser (lausser) Date: 2008-01-05 19:08 Message: Logged In: YES user_id=613416 Originator: YES Update: The same happens with AIX5.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1864550&group_id=29880 From noreply at sourceforge.net Sat Jan 5 23:37:36 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Jan 2008 14:37:36 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1864550 ] check_swap: unresolved symbol when compiling under hpux11.11 Message-ID: Patches item #1864550, was opened at 2008-01-05 17:18 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1864550&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_swap: unresolved symbol when compiling under hpux11.11 Initial Comment: Hi, i tried to build plugins-1.4.11 on a hp-ux 11.11 machine, but it failed with: -1.4.11/plugins -lm ../lib/libnagiosplug.a ../gl/libgnu.a /usr/ccs/bin/ld: Unsatisfied symbols: floorf (first referenced in check_swap.o) (code) collect2: ld returned 1 exit status It looks like floorf is not known to this OS. I propose to replace the warn_size_bytes = floorf(warn_size_bytes); with warn_size_bytes = (float) floor(warn_size_bytes); which converts double to float. Attached is a patch which let me build the plugins successfully. Greetings from Munich, Gerhard ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2008-01-05 23:37 Message: Logged In: YES user_id=1694341 Originator: NO I wouldn't mind removing inline, too. I'll commit this if nobody shows any objections in the next days. and.. hope that's not you ^^ http://images.buycostumes.com/mgen/merchandiser/21890.jpg ---------------------------------------------------------------------- Comment By: gerhard lausser (lausser) Date: 2008-01-05 21:18 Message: Logged In: YES user_id=613416 Originator: YES It compiled successfully under hpux11.11 and after 2 hours of nearly becoming crazy finally powerpc-ibm-aix5.1.0.0. The problem with AIX5.1 was that even the "static inline float floorf...." was included (i checked it with a #error directive), in the end it still aborted with "unresolved floorf..". I think it is the GCC4.0.0 i found on this machine. After i removed the "inline" so that i had "static float floorf (float x) { return floor(x); }" it compiled without problems. I still prefer your solution Nr.2, but i strongly recommend to take the "inline" out, because i am sure, machines with these outdated OSes also have outdated compilers installed. Gerhard (with a lot more grey hair now) ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-01-05 19:35 Message: Logged In: YES user_id=1694341 Originator: NO Hi Gerhard, there already were some problems with floorf in the past. I guess it was used in check disk. As a workaround an own floorf function is defined in plugins/common.h but only for sun systems. There are two possibilities now: 1st: apply the changes as you suggested, remove floorf function in common.h and add a hint to developer guidelines to never use floorf again since it's not portable 2nd: add floorf detection to autoconf and forget about the portability issue Google claims that floorf is also not available on AIX and HP-UX (as you described). So I followed the comment in common.h and included floorf detection in configure.in. It'd be great if you could test if this fix works for you as well. We can then discuss which way we'll implement. Matthias $ svn diff configure.in plugins/common.h Index: configure.in =================================================================== --- configure.in (revision 1884) +++ configure.in (working copy) @@ -151,6 +151,7 @@ dnl check for math-related functions needing -lm AC_CHECK_HEADERS(math.h) AC_CHECK_LIB(m,floor,MATHLIBS="-lm") +AC_CHECK_LIB(m,floorf,[AC_DEFINE(HAVE_FLOORF,1,[Define HAVE_FLOORF if floorf is available])]) AC_SUBST(MATHLIBS) dnl Check for libtap, to run perl-like tests Index: plugins/common.h =================================================================== --- plugins/common.h (revision 1884) +++ plugins/common.h (working copy) @@ -186,8 +186,7 @@ }; #endif -/* Solaris does not have floorf, but floor works. Should probably be in configure */ -#if defined(__sun) || defined(__sun__) +#if !HAVE_FLOORF static inline float floorf (float x) { return floor(x); } #endif ---------------------------------------------------------------------- Comment By: gerhard lausser (lausser) Date: 2008-01-05 19:08 Message: Logged In: YES user_id=613416 Originator: YES Update: The same happens with AIX5.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1864550&group_id=29880 From noreply at sourceforge.net Sat Jan 5 23:52:59 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Jan 2008 14:52:59 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1547070 ] HP-UX 11.23/parisc & 1.4.3 Message-ID: Bugs item #1547070, was opened at 2006-08-26 11:10 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1547070&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: NeoM (neomagic) Assigned to: Ton Voon (tonvoon) Summary: HP-UX 11.23/parisc & 1.4.3 Initial Comment: i try to compile nagios-plugins (1.4.3) on HP-UX 11i v2 (or 11.23) / parisc and get two quirks: * compilation of check_swap if gcc -DLOCALEDIR=\"/opt/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/opt/openssl/include -I/opt/openssl/include -Wall -g -O2 -MT check_swap.o -MD -MP -MF ".deps/check_swap.Tpo" -c -o check_swap.o check_swap.c; \ then mv -f ".deps/check_swap.Tpo" ".deps/check_swap.Po"; else rm -f ".deps/check_swap.Tpo"; exit 1; fi check_swap.c: In function `main': check_swap.c:55: warning: unused variable `tmp_mb' check_swap.c: In function `process_arguments': check_swap.c:396: warning: implicit declaration of function `floorf' /bin/sh ../libtool --mode=link --tag=CC gcc -Wall -g -O2 -L. -R/opt/openssl/lib -o check_swap check_swap.o -lm utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a popen.o -lintl -lgen -lssl -lcrypto gcc -Wall -g -O2 -o check_swap check_swap.o utils.o popen.o -L/export/tmp/nrpe/nagios-plugins-1.4.3/plugins -lm ../lib/libnagiosplug.a ../lib/libcoreutils.a /usr/local/lib/libintl.sl -L/usr/local/lib /usr/local/lib/libiconv.sl -lc -lgen -lssl -lcrypto -Wl,+b -Wl,/usr/local/lib:/opt/openssl/lib /usr/ccs/bin/ld: Unsatisfied symbols: floorf (first referenced in check_swap.o) (code) collect2: ld returned 1 exit status *** Error exit code 1 even with a good configure: checking for swap... no checking for swapinfo... /usr/sbin/swapinfo checking for /usr/sbin/swapinfo format... using HP-UX format swapinfo checking for lsps... no checking for sys/stat.h... (cached) yes checking sys/param.h usability... yes checking sys/param.h presence... yes checking for sys/param.h... yes checking for sys/swap.h... yes checking whether swapctl is declared... no checking for swaptbl_t... no checking for swapent_t... no checking for struct swapent.se_nblks... no * execution of check_disk # /opt/nagios/libexec/check_disk -w 20 -c 10 -p / -p /tmp -p /usr -p /var INPUT ERROR: C_IDFP (0.000000) should be less than W_IDFP (0.0) and both should be between zero and 100 percent, inclusive for / INPUT ERROR: C_IDFP (0.000000) should be less than W_IDFP (0.0) and both should be between zero and 100 percent, inclusive for /tmp INPUT ERROR: C_IDFP (4391739930864948500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.000000) should be less than W_IDFP (3862472858398281400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.0) and both should be between zero and 100 percent, inclusive for /usr INPUT ERROR: C_IDFP (21143572731146757000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.000000) should be less than W_IDFP (14255999733776453000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.0) and both should be between zero and 100 percent, inclusive for /var check_disk: Could not parse arguments Usage: check_disk -w limit -c limit [-p path | -x device] [-t timeout][-m] [-e] [-W limit] [-K limit] [-v] [-q] # bdf Filesystem kbytes used avail %used Mounted on /dev/vg00/lvol0 819200 336688 478792 41% / /dev/vg00/lvol1 8192000 1667256 6473832 20% /var /dev/vg00/lvol2 5242880 2185480 3033560 42% /usr /dev/vg00/lvol3 1048576 184120 857952 18% /tmp [...] ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2008-01-05 23:52 Message: Logged In: YES user_id=1694341 Originator: NO as #1864550 shows, floorf in check_swap is still a problem. possible solutions are being discussed there. closing this item. ---------------------------------------------------------------------- Comment By: NeoM (neomagic) Date: 2007-09-30 19:34 Message: Logged In: YES user_id=209976 Originator: YES sorry. i do not have anymore access to an hp-ux box, so i can't validate this. if someone else could ... thanks ton ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2007-09-29 02:04 Message: Logged In: YES user_id=664364 Originator: NO NeoM, Thanks for the report. I think this has been fixed in SVN HEAD. Please try the snapshot at http://nagiosplug.sf.net/snapshot. I've marked this call as pending so the call will automatically close. Please set to open if it is still an issue. Ton ---------------------------------------------------------------------- Comment By: Jay Lucky (mordecai) Date: 2006-09-27 19:43 Message: Logged In: YES user_id=47867 I came across this problem as well. The compile error on check_swap is because HPUX doesn't have floorf, so you can edit the plugins/common.h file and enable the inline substitution that's been done for Sun. /* Solaris does not have floorf, but floor works. Should probably be in configure */ /* Neither does HPUX! And yes, it should be in configure? */ #if defined(__sun) || defined(__sun__) || defined(__hpux) || defined(__hpux__) static inline float floorf (float x) { return floor(x); } #endif Probably a dirty hack, but it works... As for check_disk, the CVS version works fine for me. There appear to be signifigant differences in the 1.4.3 release tarball and the CVS source tree for this plug-in. Go with a current CVS tree if you want to get this working under HPUX. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1547070&group_id=29880 From noreply at sourceforge.net Sun Jan 6 01:12:01 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Jan 2008 16:12:01 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1498923 ] nagios-plugins-1.4.3 check_ldap build error on Solaris 9 Message-ID: Bugs item #1498923, was opened at 2006-06-01 17:15 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1498923&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: Sergei Haramundanis (volsh) Assigned to: Matthias Eble (psychotrahe) Summary: nagios-plugins-1.4.3 check_ldap build error on Solaris 9 Initial Comment: I get this build error during compilation of check_ldap on Solaris 9: ============================== if gcc -DLOCALEDIR=\"/usr/local/nagios2/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include/ldap -I/usr/local/ssl/include -I/usr/local/ssl/include -Wall -g -O2 -MT check_ldap.o -MD -MP -MF ".deps/check_ldap.Tpo" -c -o check_ldap.o check_ldap.c; \ then mv -f ".deps/check_ldap.Tpo" ".deps/check_ldap.Po"; else rm -f ".deps/check_ldap.Tpo"; exit 1; fi check_ldap.c: In function `main': check_ldap.c:145: warning: too many arguments for format check_ldap.c:161: warning: implicit declaration of function `ldap_start_tls_s' check_ldap.c:84: warning: unused variable `tls' /bin/bash ../libtool --mode=link --tag=CC gcc -Wall -g -O2 -L. -R/usr/local/ssl/lib -o check_ldap check_ldap.o netutils.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -lnsl -lsocket -lresolv -lldap -llber ../intl/libintl.a -liconv -lgen -lsocket -lssl -lcrypto gcc -Wall -g -O2 -o .libs/check_ldap check_ldap.o netutils.o utils.o -L/usr/local/nagios2/nagios-plugins-1.4.3/plugins ../lib/libnagiosplug.a ../lib/libcoreutils.a -lnsl -lresolv -lldap /opt/sfw/lib/.libs/liblber.so ../intl/libintl.a /usr/local/lib/libiconv.so -L/usr/local/lib -L/usr/lib -L/usr/openwin/lib -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib -lgen -lsocket -lssl -lcrypto -R/opt/sfw/lib -R/usr/local/lib -R/usr/local/ssl/lib gcc: /opt/sfw/lib/.libs/liblber.so: No such file or directory *** Error code 1 make: Fatal error: Command failed for target `check_ldap' Current working directory /usr/local/nagios2/nagios-plugins-1.4.3/plugins *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /usr/local/nagios2/nagios-plugins-1.4.3/plugins *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /usr/local/nagios2/nagios-plugins-1.4.3 *** Error code 1 make: Fatal error: Command failed for target `all' ============================== It looks like the liblber.so specification is off as it currently exists in /opt/sfw/lib on the host I am building this on. For some reason ".libs/" is getting in the path for this library. I looked for a possible mishap in the makefiles but could not find any. Please make this a priority as I need to upgrade to nagios-plugins-1.4.3 from netsaint-plugins-1.2.9-4 a.s.a.p. Thanks. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-01-06 01:12 Message: Logged In: YES user_id=1694341 Originator: NO this problem is now fixed in cvs. thank you for your report. ---------------------------------------------------------------------- Comment By: Sergei Haramundanis (volsh) Date: 2007-06-21 21:33 Message: Logged In: YES user_id=1356237 Originator: YES psychotrahe: note that this is still an issue w/nagios-plugins-1.4.9 and the workaround I provided is still the fix for it ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-21 08:24 Message: Logged In: YES user_id=1694341 Originator: NO #ifndef LDAP_OPT_SUCCESS # define LDAP_OPT_SUCCESS LDAP_SUCCESS #endif seems to be a good fix on the first view. I'll recheck and try this on our solaris box. ---------------------------------------------------------------------- Comment By: Sergei Haramundanis (volsh) Date: 2006-06-01 17:28 Message: Logged In: YES user_id=1356237 Note, originally, check_ldap failed with the following error: ============================== if gcc -DLOCALEDIR=\"/usr/local/nagios2/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include/ldap -I/usr/local/ssl/include -I/usr/local/ssl/include -Wall -g -O2 -MT check_ldap.o -MD -MP -MF ".deps/check_ldap.Tpo" -c -o check_ldap.o check_ldap.c; \ then mv -f ".deps/check_ldap.Tpo" ".deps/check_ldap.Po"; else rm -f ".deps/check_ldap.Tpo"; exit 1; fi check_ldap.c: In function `main': check_ldap.c:120: error: `LDAP_OPT_SUCCESS' undeclared (first use in this function) check_ldap.c:120: error: (Each undeclared identifier is reported only once check_ldap.c:120: error: for each function it appears in.) check_ldap.c:141: warning: too many arguments for format check_ldap.c:157: warning: implicit declaration of function `ldap_start_tls_s' check_ldap.c:80: warning: unused variable `tls' *** Error code 1 make: Fatal error: Command failed for target `check_ldap.o' Current working directory /usr/local/nagios2/nagios-plugins-1.4.3/plugins *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /usr/local/nagios2/nagios-plugins-1.4.3/plugins *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /usr/local/nagios2/nagios-plugins-1.4.3 *** Error code 1 make: Fatal error: Command failed for target `all' ============================== The workaround for this is to edit ./nagios-plugins-1.4.3/plugins/check_ldap.c and add the following after the includes section at the top of the source file: #ifndef LDAP_OPT_SUCCESS # define LDAP_OPT_SUCCESS LDAP_SUCCESS #endif ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1498923&group_id=29880 From dermoth at aei.ca Sun Jan 6 08:25:19 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Sun, 06 Jan 2008 02:25:19 -0500 Subject: [Nagiosplug-devel] [Fwd: [Nagiosplug-checkins] SF.net SVN: nagiosplug: [1889] nagiosplug/trunk/lib/tests/test_cmd.c] Message-ID: <4780825F.4010804@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just a note about this, On all tested systems (Ubuntu, FreeBSD, Solaris) /bin/sh returned 2 except for Solaris where it returned 1. Also Bash is installed on Solaris and Ubuntu and using /bin/bash returned 127. All shells tested returned 127 when calling a non-existent file from within the shell though. If we want to specifically test the return status I suggest we do it as a separate test, like doing something like: strcpy(command, "/bin/sh -c 'exit 7'"); result = cmd_run (command, &chld_out, &chld_err, 0); ok (result == 7, "Get return code 7 from /bin/sh"); Which seems to work well on all shells tested Thomas - -------- Original Message -------- Subject: [Nagiosplug-checkins] SF.net SVN: nagiosplug: [1889] nagiosplug/trunk/lib/tests/test_cmd.c Date: Sat, 05 Jan 2008 23:04:10 -0800 From: dermoth at users.sourceforge.net Reply-To: nagiosplug-devel at lists.sourceforge.net To: nagiosplug-checkins at lists.sourceforge.net Revision: 1889 http://nagiosplug.svn.sourceforge.net/nagiosplug/?rev=1889&view=rev Author: dermoth Date: 2008-01-05 23:04:10 -0800 (Sat, 05 Jan 2008) Log Message: - ----------- Fix tinderbox breakage Modified Paths: - -------------- nagiosplug/trunk/lib/tests/test_cmd.c Modified: nagiosplug/trunk/lib/tests/test_cmd.c =================================================================== - --- nagiosplug/trunk/lib/tests/test_cmd.c 2008-01-06 00:10:49 UTC (rev 1888) +++ nagiosplug/trunk/lib/tests/test_cmd.c 2008-01-06 07:04:10 UTC (rev 1889) @@ -202,7 +202,7 @@ ok (chld_err.lines == 1, "...but does give an error line"); ok (strstr(chld_err.line[0],"non-existant-file") != NULL, "And missing filename is in error message"); - - ok (result == 127, "Get return code 127 from /bin/sh"); + ok (result != 0, "Get non-zero return code from /bin/sh"); /* ensure everything is empty again */ This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. - ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Nagiosplug-checkins mailing list Nagiosplug-checkins at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagiosplug-checkins -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHgIJf6dZ+Kt5BchYRAgnHAJwJQKLCoeq1bV920XFOnoCTE5mDvACeJVQf abBfZskBd7bfWXxhNTmhhpI= =MmPC -----END PGP SIGNATURE----- From noreply at sourceforge.net Sun Jan 6 15:09:46 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Jan 2008 06:09:46 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1865082 ] check_http with -H does not allow IPv6-address Message-ID: Bugs item #1865082, was opened at 2008-01-06 15:09 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=1865082&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: neufeind (neufeind) Assigned to: Nobody/Anonymous (nobody) Summary: check_http with -H does not allow IPv6-address Initial Comment: checked with 1.4.9, however according to changelogs shouldn't have changed until 1.4.11 While other plugins work fine simply giving an IPv6-address instead of a hostname this does not seem to work for check_http. The normal commands.cfg uses -H, so I tripped into this problem. Using -I (explicitly saying it's an IP) works fine with an IPv6-address. It seems that check_http gets confused by the colons and interprets part of the IPv6-adress as a port-number. Unfortunately it's also not possible to use IPv6-adress-notation in brackets ( [1::2] ) to workaround this problem. Since everybody can edit his commands.cfg to use -I instead of -H I wouldn't say this is a showstopper. However do you think parsing of the hostname/IP could be changed so IPv6-adresses are allowed? For using a port-number instead of 80 there is another parameter available, so I doubt people use example.com:80 when calling the plugin (though you never know, for sure). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1865082&group_id=29880 From ton.voon at altinity.com Sun Jan 6 18:02:54 2008 From: ton.voon at altinity.com (Ton Voon) Date: Sun, 6 Jan 2008 17:02:54 +0000 Subject: [Nagiosplug-devel] [Fwd: [Nagiosplug-checkins] SF.net SVN: nagiosplug: [1889] nagiosplug/trunk/lib/tests/test_cmd.c] In-Reply-To: <4780825F.4010804@aei.ca> References: <4780825F.4010804@aei.ca> Message-ID: Hi Thomas, On 6 Jan 2008, at 07:25, Thomas Guyot-Sionnest wrote: > If we want to specifically test the return status I suggest we do it > as > a separate test, like doing something like: > > strcpy(command, "/bin/sh -c 'exit 7'"); > result = cmd_run (command, &chld_out, &chld_err, 0); > ok (result == 7, "Get return code 7 from /bin/sh"); > > Which seems to work well on all shells tested That looks like a decent compromise. Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From noreply at sourceforge.net Sun Jan 6 23:09:29 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Jan 2008 14:09:29 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1864550 ] check_swap: unresolved symbol when compiling under hpux11.11 Message-ID: Patches item #1864550, was opened at 2008-01-05 17:18 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1864550&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_swap: unresolved symbol when compiling under hpux11.11 Initial Comment: Hi, i tried to build plugins-1.4.11 on a hp-ux 11.11 machine, but it failed with: -1.4.11/plugins -lm ../lib/libnagiosplug.a ../gl/libgnu.a /usr/ccs/bin/ld: Unsatisfied symbols: floorf (first referenced in check_swap.o) (code) collect2: ld returned 1 exit status It looks like floorf is not known to this OS. I propose to replace the warn_size_bytes = floorf(warn_size_bytes); with warn_size_bytes = (float) floor(warn_size_bytes); which converts double to float. Attached is a patch which let me build the plugins successfully. Greetings from Munich, Gerhard ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2008-01-06 23:09 Message: Logged In: YES user_id=1694341 Originator: NO Hi all, short update on this one. adding floorf detection in configure.in won't fix #1480574 either. I browsed the gnulib git repository and found out that floor(f) was added to gnulib in october. So we'll probably end with either adding floorf.c to gl/ or simply avoiding floorf calls. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-01-05 23:37 Message: Logged In: YES user_id=1694341 Originator: NO I wouldn't mind removing inline, too. I'll commit this if nobody shows any objections in the next days. and.. hope that's not you ^^ http://images.buycostumes.com/mgen/merchandiser/21890.jpg ---------------------------------------------------------------------- Comment By: gerhard lausser (lausser) Date: 2008-01-05 21:18 Message: Logged In: YES user_id=613416 Originator: YES It compiled successfully under hpux11.11 and after 2 hours of nearly becoming crazy finally powerpc-ibm-aix5.1.0.0. The problem with AIX5.1 was that even the "static inline float floorf...." was included (i checked it with a #error directive), in the end it still aborted with "unresolved floorf..". I think it is the GCC4.0.0 i found on this machine. After i removed the "inline" so that i had "static float floorf (float x) { return floor(x); }" it compiled without problems. I still prefer your solution Nr.2, but i strongly recommend to take the "inline" out, because i am sure, machines with these outdated OSes also have outdated compilers installed. Gerhard (with a lot more grey hair now) ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-01-05 19:35 Message: Logged In: YES user_id=1694341 Originator: NO Hi Gerhard, there already were some problems with floorf in the past. I guess it was used in check disk. As a workaround an own floorf function is defined in plugins/common.h but only for sun systems. There are two possibilities now: 1st: apply the changes as you suggested, remove floorf function in common.h and add a hint to developer guidelines to never use floorf again since it's not portable 2nd: add floorf detection to autoconf and forget about the portability issue Google claims that floorf is also not available on AIX and HP-UX (as you described). So I followed the comment in common.h and included floorf detection in configure.in. It'd be great if you could test if this fix works for you as well. We can then discuss which way we'll implement. Matthias $ svn diff configure.in plugins/common.h Index: configure.in =================================================================== --- configure.in (revision 1884) +++ configure.in (working copy) @@ -151,6 +151,7 @@ dnl check for math-related functions needing -lm AC_CHECK_HEADERS(math.h) AC_CHECK_LIB(m,floor,MATHLIBS="-lm") +AC_CHECK_LIB(m,floorf,[AC_DEFINE(HAVE_FLOORF,1,[Define HAVE_FLOORF if floorf is available])]) AC_SUBST(MATHLIBS) dnl Check for libtap, to run perl-like tests Index: plugins/common.h =================================================================== --- plugins/common.h (revision 1884) +++ plugins/common.h (working copy) @@ -186,8 +186,7 @@ }; #endif -/* Solaris does not have floorf, but floor works. Should probably be in configure */ -#if defined(__sun) || defined(__sun__) +#if !HAVE_FLOORF static inline float floorf (float x) { return floor(x); } #endif ---------------------------------------------------------------------- Comment By: gerhard lausser (lausser) Date: 2008-01-05 19:08 Message: Logged In: YES user_id=613416 Originator: YES Update: The same happens with AIX5.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1864550&group_id=29880 From noreply at sourceforge.net Mon Jan 7 03:13:13 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Jan 2008 18:13:13 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1865082 ] check_http with -H does not allow IPv6-address Message-ID: Bugs item #1865082, was opened at 2008-01-06 15:09 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1865082&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: Release (specify) >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: neufeind (neufeind) Assigned to: Nobody/Anonymous (nobody) Summary: check_http with -H does not allow IPv6-address Initial Comment: checked with 1.4.9, however according to changelogs shouldn't have changed until 1.4.11 While other plugins work fine simply giving an IPv6-address instead of a hostname this does not seem to work for check_http. The normal commands.cfg uses -H, so I tripped into this problem. Using -I (explicitly saying it's an IP) works fine with an IPv6-address. It seems that check_http gets confused by the colons and interprets part of the IPv6-adress as a port-number. Unfortunately it's also not possible to use IPv6-adress-notation in brackets ( [1::2] ) to workaround this problem. Since everybody can edit his commands.cfg to use -I instead of -H I wouldn't say this is a showstopper. However do you think parsing of the hostname/IP could be changed so IPv6-adresses are allowed? For using a port-number instead of 80 there is another parameter available, so I doubt people use example.com:80 when calling the plugin (though you never know, for sure). ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2008-01-07 03:13 Message: Logged In: YES user_id=759506 Originator: NO Thank you for the hint, I fixed this in SVN. "-H" now accepts IPv6 addresses with and without brackets, brackets are only necessary to specify "[IPv6]:port". (The "-H example.com:80" notation is needed to generate a "Host: example.com:80" header, this cannot be done with "--port".) Thanks again, Holger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1865082&group_id=29880 From hpsekhon at googlemail.com Mon Jan 7 14:53:46 2008 From: hpsekhon at googlemail.com (Hari Sekhon) Date: Mon, 07 Jan 2008 13:53:46 +0000 Subject: [Nagiosplug-devel] NRPE Authentication/Authorization?? DEVS PLEASE READ Message-ID: <47822EEA.3080807@googlemail.com> Hi, Recent expanded usage of my NRPE daemons has gotten me thinking about better authentication and authorization. It seems that NRPE is quite lacking in authentication (there is none!). Most of us work around this deficiency by wrapping it xinetd to restrict IP addresses to the monitoring server(s) (at least I do). However this does not really solve anything. There are two problems with even just IP limiting NRPE calls. Firstly, IP Spoofing. Secondly, what if there is more than 1 user account on a server? Any user or developer who has an account on any IP authorized machine can issue NRPE calls to any server running NRPE. This is a real problem if you want to use NRPE to issue remote restarts or take any remedial action that you want to control. Even just the data leakage issue can be quite serious. So... Is there any chance we can have authentication added to NRPE like we do with NSCA where you must have at the very least a shared secret? Going one step further, is it possible to have separate credentials limited to separate calls? This would be most helpful for event handlers... or for different monitoring servers or user accounts. Thanks -h -- Hari Sekhon From mike at primaledge.ca Tue Jan 8 00:01:40 2008 From: mike at primaledge.ca (mike) Date: Mon, 7 Jan 2008 15:01:40 -0800 Subject: [Nagiosplug-devel] patch for check_by_ssh passive mode Message-ID: <668670f40801071501j6f38a70bo228c90544d4460b0@mail.gmail.com> The current one doesn't really work. It basically did nothing if there was a \n anywhere in the command output (most commands return a \n at the end :) This makes it better by writing the last output line (up to the \n) in the log, and doesn't abort if one of the commands has an error. Still isn't perfect but it's usable. Enjoy, Mike --- check_by_ssh.c.orig 2007-09-23 05:26:03.000000000 -0700 +++ check_by_ssh.c 2008-01-07 14:59:42.000000000 -0800 @@ -100,7 +100,7 @@ main (int argc, char **argv) skip_stderr = chld_err.lines; /* UNKNOWN if (non-skipped) output found on stderr */ - if(chld_err.lines > skip_stderr) { + if(!passive && chld_err.lines > skip_stderr) { printf (_("Remote command execution failed: %s\n"), chld_err.line[skip_stderr]); return STATE_UNKNOWN; @@ -133,16 +133,14 @@ main (int argc, char **argv) commands = 0; for(i = skip_stdout; i < chld_out.lines; i++) { status_text = strstr (chld_out.line[i], "STATUS CODE: "); - if (status_text == NULL) { - printf ("%s", chld_out.line[i]); - return result; - } if (service[commands] && status_text && sscanf (status_text, "STATUS CODE: %d", &cresult) == 1) { - fprintf (fp, "[%d] PROCESS_SERVICE_CHECK_RESULT;%s;%s;%d;%s\n", - (int) local_time, host_shortname, service[commands++], - cresult, chld_out.line[i]); + fprintf (fp, "[%d] PROCESS_SERVICE_CHECK_RESULT;%s;%s;%d;", + (int) local_time, host_shortname, service[commands++], cresult); + if (cresult == 0) fprintf (fp, "%s\n", chld_out.line[i-1]); + else if(chld_err.lines > skip_stderr) + fprintf (fp, "%s\n", chld_err.line[skip_stderr]); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo at bier.homeip.net Tue Jan 8 09:16:16 2008 From: flo at bier.homeip.net (Florian Gleixner) Date: Tue, 08 Jan 2008 09:16:16 +0100 Subject: [Nagiosplug-devel] NRPE Authentication/Authorization?? DEVS PLEASE READ In-Reply-To: <47822EEA.3080807@googlemail.com> References: <47822EEA.3080807@googlemail.com> Message-ID: <47833150.200@bier.homeip.net> Hari Sekhon schrieb: ... > > So... > > Is there any chance we can have authentication added to NRPE like we do > with NSCA where you must have at the very least a shared secret? > I vote for this too. check_by_ssh can be an alternative sometimes, but sometimes it is not desireable to have the nagios server full ssh access to the monitored machine. > Going one step further, is it possible to have separate credentials > limited to separate calls? This would be most helpful for event > handlers... or for different monitoring servers or user accounts. > Here one could live with a workaround: setup different nrpe services on different tcp ports and you can use different configs and access controls for each nrpe service. Flo From Alexander.Leidinger at ext.publications.europa.eu Tue Jan 8 11:51:34 2008 From: Alexander.Leidinger at ext.publications.europa.eu (Alexander Leidinger) Date: Tue, 08 Jan 2008 11:51:34 +0100 Subject: [Nagiosplug-devel] nagios-plugins 1.4.11 compile problems on Solaris 10 (+workarounds) Message-ID: <1199789494.21087.35.camel@phoenix> Hi, I compiled nagios plugins 1.4.11 on Solaris 10 with the Sun Studio compiler/tools. I encountered the following problems. Error 1: --snip-- Undefined first referenced symbol in file floor check_apt.o --snip-- My workaround: --snip-- vi plugins/Makefile search LIBS = ... add -lm in the end --snip-- Error 2: The same for plugins-root/Makefile (floor in check_dhcp.o) Note: configure checks for floor and tells it finds it in libm. MATHLIBS in the Makefile contains libm, but it seems it is not used for check_apt. Warning you should maybe have a loot at: ---snip--- Manifying blib/man3/Test::Tutorial.3 Use of uninitialized value in concatenation (.) or string at ../tools/build_perl_modules line 77. ---snip--- Bye, Alexander. From dermoth at aei.ca Tue Jan 8 11:55:27 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 08 Jan 2008 05:55:27 -0500 Subject: [Nagiosplug-devel] check_dns broken in CVS Message-ID: <4783569F.4090308@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Result of last commit to it... $ svn log check_dns.c|head - ------------------------------------------------------------------------ r1886 | psychotrahe | 2008-01-04 20:06:36 -0500 (Fri, 04 Jan 2008) | 2 lines check_dns now sorts addresses for -a support with multiple address replies (Matthias Urlichs #1724052) $ svn up -r1885 check_dns.c U check_dns.c Updated to revision 1885. $ make -q $ ./check_dns -H 206.123.6.183 -a web.aei.ca. -t 5 DNS CRITICAL - '/usr/sbin/nslookup -sil' msg parsing exited with no address $ svn up -rHEAD check_dns.c U check_dns.c Updated to revision 1897. $ make -q $ ./check_dns -H 206.123.6.183 -a web.aei.ca. -t 5 DNS CRITICAL - '/usr/sbin/nslookup -sil' msg parsing exited with no address $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHg1af6dZ+Kt5BchYRAibRAKD/DmX8KFLwAQYUmkg8EYWCBg6t0QCdFeBN sDYrP1LLi+mA3FUJN9tZTMU= =jQTd -----END PGP SIGNATURE----- From noreply at sourceforge.net Tue Jan 8 12:01:23 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Jan 2008 03:01:23 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1864550 ] check_swap: unresolved symbol when compiling under hpux11.11 Message-ID: Patches item #1864550, was opened at 2008-01-05 16:18 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1864550&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_swap: unresolved symbol when compiling under hpux11.11 Initial Comment: Hi, i tried to build plugins-1.4.11 on a hp-ux 11.11 machine, but it failed with: -1.4.11/plugins -lm ../lib/libnagiosplug.a ../gl/libgnu.a /usr/ccs/bin/ld: Unsatisfied symbols: floorf (first referenced in check_swap.o) (code) collect2: ld returned 1 exit status It looks like floorf is not known to this OS. I propose to replace the warn_size_bytes = floorf(warn_size_bytes); with warn_size_bytes = (float) floor(warn_size_bytes); which converts double to float. Attached is a patch which let me build the plugins successfully. Greetings from Munich, Gerhard ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2008-01-08 11:01 Message: Logged In: YES user_id=664364 Originator: NO I'd prefer to add floorf from gnulib - it would be useful all round. I've got some notes on updating gnulib - and I'll happily go through it with anyone. Volunteers? Matthias? Ton ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-01-06 22:09 Message: Logged In: YES user_id=1694341 Originator: NO Hi all, short update on this one. adding floorf detection in configure.in won't fix #1480574 either. I browsed the gnulib git repository and found out that floor(f) was added to gnulib in october. So we'll probably end with either adding floorf.c to gl/ or simply avoiding floorf calls. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-01-05 22:37 Message: Logged In: YES user_id=1694341 Originator: NO I wouldn't mind removing inline, too. I'll commit this if nobody shows any objections in the next days. and.. hope that's not you ^^ http://images.buycostumes.com/mgen/merchandiser/21890.jpg ---------------------------------------------------------------------- Comment By: gerhard lausser (lausser) Date: 2008-01-05 20:18 Message: Logged In: YES user_id=613416 Originator: YES It compiled successfully under hpux11.11 and after 2 hours of nearly becoming crazy finally powerpc-ibm-aix5.1.0.0. The problem with AIX5.1 was that even the "static inline float floorf...." was included (i checked it with a #error directive), in the end it still aborted with "unresolved floorf..". I think it is the GCC4.0.0 i found on this machine. After i removed the "inline" so that i had "static float floorf (float x) { return floor(x); }" it compiled without problems. I still prefer your solution Nr.2, but i strongly recommend to take the "inline" out, because i am sure, machines with these outdated OSes also have outdated compilers installed. Gerhard (with a lot more grey hair now) ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-01-05 18:35 Message: Logged In: YES user_id=1694341 Originator: NO Hi Gerhard, there already were some problems with floorf in the past. I guess it was used in check disk. As a workaround an own floorf function is defined in plugins/common.h but only for sun systems. There are two possibilities now: 1st: apply the changes as you suggested, remove floorf function in common.h and add a hint to developer guidelines to never use floorf again since it's not portable 2nd: add floorf detection to autoconf and forget about the portability issue Google claims that floorf is also not available on AIX and HP-UX (as you described). So I followed the comment in common.h and included floorf detection in configure.in. It'd be great if you could test if this fix works for you as well. We can then discuss which way we'll implement. Matthias $ svn diff configure.in plugins/common.h Index: configure.in =================================================================== --- configure.in (revision 1884) +++ configure.in (working copy) @@ -151,6 +151,7 @@ dnl check for math-related functions needing -lm AC_CHECK_HEADERS(math.h) AC_CHECK_LIB(m,floor,MATHLIBS="-lm") +AC_CHECK_LIB(m,floorf,[AC_DEFINE(HAVE_FLOORF,1,[Define HAVE_FLOORF if floorf is available])]) AC_SUBST(MATHLIBS) dnl Check for libtap, to run perl-like tests Index: plugins/common.h =================================================================== --- plugins/common.h (revision 1884) +++ plugins/common.h (working copy) @@ -186,8 +186,7 @@ }; #endif -/* Solaris does not have floorf, but floor works. Should probably be in configure */ -#if defined(__sun) || defined(__sun__) +#if !HAVE_FLOORF static inline float floorf (float x) { return floor(x); } #endif ---------------------------------------------------------------------- Comment By: gerhard lausser (lausser) Date: 2008-01-05 18:08 Message: Logged In: YES user_id=613416 Originator: YES Update: The same happens with AIX5.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1864550&group_id=29880 From dermoth at aei.ca Tue Jan 8 12:27:00 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 08 Jan 2008 06:27:00 -0500 Subject: [Nagiosplug-devel] r1879: check_tcp now returns UNKNOWN with an invalid hostname on command line Message-ID: <47835E04.9050206@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In check_tcp.c svn logs: - ------------------------------------------------------------------------ r1879 | tonvoon | 2007-12-19 05:08:06 -0500 (Wed, 19 Dec 2007) | 2 lines check_tcp now returns UNKNOWN with an invalid hostname on command line This breaks some tests (at least check_ftp and maybe others)... I fixed check_ftp but I can't guarantee I'll fix all breakages if there's more. Also while I see the point of using UNKNOWNs for unknown hosts, I'm thinking whoever is testing a remote host he doesn't control with check_tcp will receive UNKNOWN instead of CRITICAL if the hostname changes which might not be the expected behavior. So it should be well documented that whoever is running checks with hostnames should check with check_dns as well, especially for hosts they don't have control over. Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFHg14E6dZ+Kt5BchYRAr9cAJYkj8UYCaAQHPhQ3gWpjfaEMp7cAKCw3WbX jcoW6JNd5QdIDTrJ+MWRtA== =FG9L -----END PGP SIGNATURE----- From ton.voon at altinity.com Tue Jan 8 12:48:39 2008 From: ton.voon at altinity.com (Ton Voon) Date: Tue, 8 Jan 2008 11:48:39 +0000 Subject: [Nagiosplug-devel] r1879: check_tcp now returns UNKNOWN with an invalid hostname on command line In-Reply-To: <47835E04.9050206@aei.ca> References: <47835E04.9050206@aei.ca> Message-ID: On 8 Jan 2008, at 11:27, Thomas Guyot-Sionnest wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > In check_tcp.c svn logs: > - > ------------------------------------------------------------------------ > r1879 | tonvoon | 2007-12-19 05:08:06 -0500 (Wed, 19 Dec 2007) | 2 > lines > > check_tcp now returns UNKNOWN with an invalid hostname on command line > > This breaks some tests (at least check_ftp and maybe others)... I > fixed > check_ftp but I can't guarantee I'll fix all breakages if there's > more. > > Also while I see the point of using UNKNOWNs for unknown hosts, I'm > thinking whoever is testing a remote host he doesn't control with > check_tcp will receive UNKNOWN instead of CRITICAL if the hostname > changes which might not be the expected behavior. > > So it should be well documented that whoever is running checks with > hostnames should check with check_dns as well, especially for hosts > they > don't have control over. Fair point. I specifically made this change because in a Nagios configuration $HOSTADDRESS$ wasn't set, so the check_tcp was effectively running: check_tcp -H -w 5 and mistaking -w for the hostname. My thinking was that this was a command line options error, hence UNKNOWN. However, I've obviously implemented it as a hostname resolution check. Looking at http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN78 , it's a higher level error so shouldn't be UNKNOWN and should be CRITICAL. So, sorry, I screwed up here twice: once for changing to UNKNOWN, and twice for not checking the test results to see the impact. I'll revert back now. Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From dermoth at aei.ca Tue Jan 8 13:27:20 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 08 Jan 2008 07:27:20 -0500 Subject: [Nagiosplug-devel] r1879: check_tcp now returns UNKNOWN with an invalid hostname on command line In-Reply-To: References: <47835E04.9050206@aei.ca> Message-ID: <47836C28.9070104@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/01/08 06:48 AM, Ton Voon wrote: > On 8 Jan 2008, at 11:27, Thomas Guyot-Sionnest wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> In check_tcp.c svn logs: >> - >> ------------------------------------------------------------------------ >> r1879 | tonvoon | 2007-12-19 05:08:06 -0500 (Wed, 19 Dec 2007) | 2 >> lines >> >> check_tcp now returns UNKNOWN with an invalid hostname on command line >> >> This breaks some tests (at least check_ftp and maybe others)... I >> fixed >> check_ftp but I can't guarantee I'll fix all breakages if there's >> more. >> >> Also while I see the point of using UNKNOWNs for unknown hosts, I'm >> thinking whoever is testing a remote host he doesn't control with >> check_tcp will receive UNKNOWN instead of CRITICAL if the hostname >> changes which might not be the expected behavior. >> >> So it should be well documented that whoever is running checks with >> hostnames should check with check_dns as well, especially for hosts >> they >> don't have control over. > > > Fair point. I specifically made this change because in a Nagios > configuration $HOSTADDRESS$ wasn't set, so the check_tcp was > effectively running: > > check_tcp -H -w 5 > > and mistaking -w for the hostname. My thinking was that this was a > command line options error, hence UNKNOWN. However, I've obviously > implemented it as a hostname resolution check. > > Looking at http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN78 > , it's a higher level error so shouldn't be UNKNOWN and should be > CRITICAL. > > So, sorry, I screwed up here twice: once for changing to UNKNOWN, and > twice for not checking the test results to see the impact. > > I'll revert back now. The arguments goes in both ways. It is fair to think name resolution belongs to check_dns, and in my setups I use IPs everywhere I can and the dns servers have their own checks. I didn't push my vote towards the reversal of your commit because some other plugins I checked goes UNKNOWN on invalid hosts too. The developer guideline should be clear on this (if it's not already) and plugins not following the specs should be fixed. I don't believe this should apply for plugin that use a protocol to check something behind it (i.e. check_snmp, check_nrpe, check_by_ssh, check_nt). It that case this should be UNKNOWN with optionally the possibility to return CRITICAL on protocol unreachable. So instead of setting 10 thousand dependencies in Nagios you can just have one check for the protocol (using the CRITICAL option or negate) and all other returning UNKNOWN when unreachable - this ways you won't get a "pager bomb" then the service does down ;) Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHg2wo6dZ+Kt5BchYRAupZAJ9ESlq91Ww6ua0UAs0JbVBQPEYMAwCgshgZ MeJyb9Pkk9HhwpS5I7tAl3M= =ptDc -----END PGP SIGNATURE----- From matthias.eble at mailing.kaufland-informationssysteme.com Tue Jan 8 13:53:00 2008 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Tue, 08 Jan 2008 13:53:00 +0100 Subject: [Nagiosplug-devel] check_dns broken in CVS In-Reply-To: <4783569F.4090308@aei.ca> References: <4783569F.4090308@aei.ca> Message-ID: <4783722C.5040302@mailing.kaufland-informationssysteme.com> Thomas Guyot-Sionnest schrieb: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Result of last commit to it... > > $ svn log check_dns.c|head > - ------------------------------------------------------------------------ > r1886 | psychotrahe | 2008-01-04 20:06:36 -0500 (Fri, 04 Jan 2008) | 2 lines > > check_dns now sorts addresses for -a support with multiple address > replies (Matthias Urlichs #1724052) > > $ svn up -r1885 check_dns.c > U check_dns.c > Updated to revision 1885. > $ make -q > $ ./check_dns -H 206.123.6.183 -a web.aei.ca. -t 5 > DNS CRITICAL - '/usr/sbin/nslookup -sil' msg parsing exited with no address > $ svn up -rHEAD check_dns.c > U check_dns.c > Updated to revision 1897. > $ make -q > $ ./check_dns -H 206.123.6.183 -a web.aei.ca. -t 5 > DNS CRITICAL - '/usr/sbin/nslookup -sil' msg parsing exited with no address > $ Hi Thomas, thank you.. jup there is/was a problem with the patch I applied. I have overseen the reverse functionality and somehow interpreted the testcase output as non-critical.. I'll commit a fix tonight. This shows again, how important software testing is. Matthias From matthias.eble at mailing.kaufland-informationssysteme.com Tue Jan 8 13:57:44 2008 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Tue, 08 Jan 2008 13:57:44 +0100 Subject: [Nagiosplug-devel] nagios-plugins 1.4.11 compile problems on Solaris 10 (+workarounds) In-Reply-To: <1199789494.21087.35.camel@phoenix> References: <1199789494.21087.35.camel@phoenix> Message-ID: <47837348.8080003@mailing.kaufland-informationssysteme.com> Alexander Leidinger schrieb: > Hi, > > I compiled nagios plugins 1.4.11 on Solaris 10 with the Sun Studio > compiler/tools. I encountered the following problems. > > Error 1: > --snip-- > Undefined first referenced > symbol in file > floor check_apt.o > --snip-- > > My workaround: > --snip-- > vi plugins/Makefile > search LIBS = ... > add -lm in the end > --snip-- > > > Error 2: > The same for plugins-root/Makefile (floor in check_dhcp.o) > > Note: configure checks for floor and tells it finds it in libm. MATHLIBS > in the Makefile contains libm, but it seems it is not used for > check_apt. Hi Alexander, this is a known issue that needs to be discussed/solved.. since with the current behaviour all programs that use common.h should need to link against the math libs (although gcc works) which is not the case at the moment. This problem is described in item #1864550 in the patches reacker.. http://sourceforge.net/tracker/index.php?func=detail&aid=1864550&group_id=29880&atid=397599 Matthias From ton.voon at altinity.com Tue Jan 8 14:39:19 2008 From: ton.voon at altinity.com (Ton Voon) Date: Tue, 8 Jan 2008 13:39:19 +0000 Subject: [Nagiosplug-devel] r1879: check_tcp now returns UNKNOWN with an invalid hostname on command line In-Reply-To: <47836C28.9070104@aei.ca> References: <47835E04.9050206@aei.ca> <47836C28.9070104@aei.ca> Message-ID: <874F8592-08DD-45DF-991B-F624BB047F27@altinity.com> On 8 Jan 2008, at 12:27, Thomas Guyot-Sionnest wrote: > The arguments goes in both ways. It is fair to think name resolution > belongs to check_dns, and in my setups I use IPs everywhere I can and > the dns servers have their own checks. I didn't push my vote towards > the > reversal of your commit because some other plugins I checked goes > UNKNOWN on invalid hosts too. > > The developer guideline should be clear on this (if it's not already) > and plugins not following the specs should be fixed. We did have an argument a long time ago about whether an invalid host is a CRITICAL or an UNKNOWN. I argued for UNKNOWN because a name resolution doesn't mean that the host is not there. Ethan and others (who I can't recall) argued for CRITICAL and that was the consensus, hence the decision to set the text in the guidelines as UNKNOWNs: Invalid command line arguments were supplied to the plugin or low- level failures internal to the plugin (such as unable to fork, or open a tcp socket) that prevent it from performing the specified operation. Higher-level errors (such as name resolution errors, socket timeouts, etc) are outside of the control of plugins and should generally NOT be reported as UNKNOWN states. > I don't believe this should apply for plugin that use a protocol to > check something behind it (i.e. check_snmp, check_nrpe, check_by_ssh, > check_nt). It that case this should be UNKNOWN with optionally the > possibility to return CRITICAL on protocol unreachable. So instead of > setting 10 thousand dependencies in Nagios you can just have one check > for the protocol (using the CRITICAL option or negate) and all other > returning UNKNOWN when unreachable - this ways you won't get a "pager > bomb" then the service does down ;) It means that you have to have at least 1 other check of the protocol setup in Nagios, which is not always the case. I personally agree with this, but not sure if it should be in the guidelines. Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From ton.voon at altinity.com Tue Jan 8 14:47:05 2008 From: ton.voon at altinity.com (Ton Voon) Date: Tue, 8 Jan 2008 13:47:05 +0000 Subject: [Nagiosplug-devel] check_dns broken in CVS In-Reply-To: <4783722C.5040302@mailing.kaufland-informationssysteme.com> References: <4783569F.4090308@aei.ca> <4783722C.5040302@mailing.kaufland-informationssysteme.com> Message-ID: <90DF3407-DC34-4D24-9063-5F5D8E88501E@altinity.com> On 8 Jan 2008, at 12:53, Matthias Eble wrote: > Thomas Guyot-Sionnest schrieb: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Result of last commit to it... >> >> $ svn log check_dns.c|head >> - >> ------------------------------------------------------------------------ >> r1886 | psychotrahe | 2008-01-04 20:06:36 -0500 (Fri, 04 Jan 2008) >> | 2 lines >> >> check_dns now sorts addresses for -a support with multiple address >> replies (Matthias Urlichs #1724052) >> >> $ svn up -r1885 check_dns.c >> U check_dns.c >> Updated to revision 1885. >> $ make -q >> $ ./check_dns -H 206.123.6.183 -a web.aei.ca. -t 5 >> DNS CRITICAL - '/usr/sbin/nslookup -sil' msg parsing exited with no >> address >> $ svn up -rHEAD check_dns.c >> U check_dns.c >> Updated to revision 1897. >> $ make -q >> $ ./check_dns -H 206.123.6.183 -a web.aei.ca. -t 5 >> DNS CRITICAL - '/usr/sbin/nslookup -sil' msg parsing exited with no >> address >> $ > > Hi Thomas, > > thank you.. jup there is/was a problem with the patch I applied. I > have > overseen the reverse functionality and somehow interpreted the > testcase > output as non-critical.. I'll commit a fix tonight. > > This shows again, how important software testing is. Good work guys. I just spotted this too. I was going to apply a patch to change the default DNS entries (was apple.com, but will switch to nagios.com instead) in the test script. Is this okay to do? Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From matthias.eble at mailing.kaufland-informationssysteme.com Tue Jan 8 15:13:00 2008 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Tue, 08 Jan 2008 15:13:00 +0100 Subject: [Nagiosplug-devel] check_dns broken in CVS In-Reply-To: <90DF3407-DC34-4D24-9063-5F5D8E88501E@altinity.com> References: <4783569F.4090308@aei.ca> <4783722C.5040302@mailing.kaufland-informationssysteme.com> <90DF3407-DC34-4D24-9063-5F5D8E88501E@altinity.com> Message-ID: <478384EC.2020203@mailing.kaufland-informationssysteme.com> Ton Voon schrieb: > On 8 Jan 2008, at 12:53, Matthias Eble wrote: > >> Hi Thomas, >> >> thank you.. jup there is/was a problem with the patch I applied. I >> have >> overseen the reverse functionality and somehow interpreted the >> testcase >> output as non-critical.. I'll commit a fix tonight. >> >> This shows again, how important software testing is. > > Good work guys. hmm thanks. but.. just want to remind you that the commit is broken. so.. good work thomas :) > I just spotted this too. I was going to apply a patch to change the > default DNS entries (was apple.com, but will switch to nagios.com > instead) in the test script. Is this okay to do? I guess that was the cause why I commited despite failing tests. Apple reverse lookups changed from request to request - so yes changing this would be good IMO. I guess we'll need at least one dns entry that returns multiple addresses - which doesn't seem to be the case for nagios.org. Matthias From dermoth at aei.ca Tue Jan 8 15:15:25 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 08 Jan 2008 09:15:25 -0500 Subject: [Nagiosplug-devel] r1879: check_tcp now returns UNKNOWN with an invalid hostname on command line In-Reply-To: <874F8592-08DD-45DF-991B-F624BB047F27@altinity.com> References: <47835E04.9050206@aei.ca> <47836C28.9070104@aei.ca> <874F8592-08DD-45DF-991B-F624BB047F27@altinity.com> Message-ID: <4783857D.70709@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/01/08 08:39 AM, Ton Voon wrote: > On 8 Jan 2008, at 12:27, Thomas Guyot-Sionnest wrote: >> I don't believe this should apply for plugin that use a protocol to >> check something behind it (i.e. check_snmp, check_nrpe, check_by_ssh, >> check_nt). It that case this should be UNKNOWN with optionally the >> possibility to return CRITICAL on protocol unreachable. So instead of >> setting 10 thousand dependencies in Nagios you can just have one check >> for the protocol (using the CRITICAL option or negate) and all other >> returning UNKNOWN when unreachable - this ways you won't get a "pager >> bomb" then the service does down ;) > > It means that you have to have at least 1 other check of the protocol > setup in Nagios, which is not always the case. I personally agree with > this, but not sure if it should be in the guidelines. Well, otherwise the guidelines would specifically forbid these plugins from returning UNKNOWN. If you take check_nrpe for example, not being able to reach the host doesn't mean the plug-in would fail, and having many nrpe check would cause many alerts if a single component, nrpe, fails. Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHg4V96dZ+Kt5BchYRAtrJAJwO1Rj2F/epju8k/Cspbtr8l1gjWgCcD75G wSWTrjDY49p616g5UD3bIAw= =FdC1 -----END PGP SIGNATURE----- From ton.voon at altinity.com Tue Jan 8 17:06:30 2008 From: ton.voon at altinity.com (Ton Voon) Date: Tue, 8 Jan 2008 16:06:30 +0000 Subject: [Nagiosplug-devel] check_dns broken in CVS In-Reply-To: <478384EC.2020203@mailing.kaufland-informationssysteme.com> References: <4783569F.4090308@aei.ca> <4783722C.5040302@mailing.kaufland-informationssysteme.com> <90DF3407-DC34-4D24-9063-5F5D8E88501E@altinity.com> <478384EC.2020203@mailing.kaufland-informationssysteme.com> Message-ID: On 8 Jan 2008, at 14:13, Matthias Eble wrote: >> I just spotted this too. I was going to apply a patch to change the >> default DNS entries (was apple.com, but will switch to nagios.com >> instead) in the test script. Is this okay to do? > > I guess that was the cause why I commited despite failing tests. > Apple reverse lookups changed from request to request - so yes > changing this would be good IMO. Done. > I guess we'll need at least one dns entry that returns multiple > addresses - which doesn't seem to be the case for nagios.org. I was thinking that maybe we should test by having a text file which has the contents of an nslookup on a host with lots of addresses, then somehow get the plugin to read that as the output of "nslookup -sil". This way we don't actually have to have a DNS entry somewhere that is in a particular-fashion-but-may-be-changed-in-the-future. Then again, I was thinking that check_dns should use the C resolver routines in the future, in which case this nslookup bit won't work... Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From mike at primaledge.ca Tue Jan 8 19:20:33 2008 From: mike at primaledge.ca (mike) Date: Tue, 8 Jan 2008 10:20:33 -0800 Subject: [Nagiosplug-devel] patch for check_by_ssh passive mode In-Reply-To: <668670f40801071501j6f38a70bo228c90544d4460b0@mail.gmail.com> References: <668670f40801071501j6f38a70bo228c90544d4460b0@mail.gmail.com> Message-ID: <668670f40801081020h7d87f707w842ced4af48906b9@mail.gmail.com> Here's a corrected patch after testing in a live environment ;) --- check_by_ssh.c.orig 2007-09-23 05:26:03.000000000 -0700 +++ check_by_ssh.c 2008-01-08 10:20:01.000000000 -0800 @@ -100,7 +100,7 @@ main (int argc, char **argv) skip_stderr = chld_err.lines; /* UNKNOWN if (non-skipped) output found on stderr */ - if(chld_err.lines > skip_stderr) { + if(!passive && chld_err.lines > skip_stderr) { printf (_("Remote command execution failed: %s\n"), chld_err.line[skip_stderr]); return STATE_UNKNOWN; @@ -133,16 +133,16 @@ main (int argc, char **argv) commands = 0; for(i = skip_stdout; i < chld_out.lines; i++) { status_text = strstr (chld_out.line[i], "STATUS CODE: "); - if (status_text == NULL) { - printf ("%s", chld_out.line[i]); - return result; - } if (service[commands] && status_text && sscanf (status_text, "STATUS CODE: %d", &cresult) == 1) { - fprintf (fp, "[%d] PROCESS_SERVICE_CHECK_RESULT;%s;%s;%d;%s\n", - (int) local_time, host_shortname, service[commands++], - cresult, chld_out.line[i]); + fprintf (fp, "[%d] PROCESS_SERVICE_CHECK_RESULT;%s;%s;%d;", + (int) local_time, host_shortname, service[commands++], cresult); + if (strstr (chld_out.line[i-1], "STATUS CODE: ") == 0) fprintf (fp, "%s", chld_out.line[i-1]); + if (cresult != 0) + fprintf (fp, "%s - Remote command exit status %d\n", + state_text(cresult), cresult); + else fprintf (fp, "\n"); } } On 1/7/08, mike wrote: > > The current one doesn't really work. It basically did nothing if there > was a \n anywhere in the command output (most commands return a \n at the > end :) This makes it better by writing the last output line (up to the \n) > in the log, and doesn't abort if one of the commands has an error. Still > isn't perfect but it's usable. > Enjoy, > Mike > > > --- check_by_ssh.c.orig 2007-09-23 05:26:03.000000000 -0700 > +++ check_by_ssh.c 2008-01-07 14:59:42.000000000 -0800 > @@ -100,7 +100,7 @@ main (int argc, char **argv) > skip_stderr = chld_err.lines; > > /* UNKNOWN if (non-skipped) output found on stderr */ > - if(chld_err.lines > skip_stderr) { > + if(!passive && chld_err.lines > skip_stderr) { > printf (_("Remote command execution failed: %s\n"), > chld_err.line[skip_stderr]); > return STATE_UNKNOWN; > @@ -133,16 +133,14 @@ main (int argc, char **argv) > commands = 0; > for(i = skip_stdout; i < chld_out.lines; i++) { > status_text = strstr (chld_out.line[i], "STATUS CODE: "); > - if (status_text == NULL) { > - printf ("%s", chld_out.line[i]); > - return result; > - } > if (service[commands] && status_text > && sscanf (status_text, "STATUS CODE: %d", > &cresult) == 1) > { > - fprintf (fp, "[%d] > PROCESS_SERVICE_CHECK_RESULT;%s;%s;%d;%s\n", > - (int) local_time, host_shortname, > service[commands++], > - cresult, chld_out.line[i]); > + fprintf (fp, "[%d] > PROCESS_SERVICE_CHECK_RESULT;%s;%s;%d;", > + (int) local_time, host_shortname, > service[commands++], cresult); > + if (cresult == 0) fprintf (fp, "%s\n", > chld_out.line[i-1]); > + else if(chld_err.lines > skip_stderr) > + fprintf (fp, "%s\n", > chld_err.line[skip_stderr]); > } > } > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Tue Jan 8 20:42:09 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Jan 2008 11:42:09 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1460312 ] check_http doesn't check response time on 300's Message-ID: Bugs item #1460312, was opened at 2006-03-28 17:40 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1460312&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: Thomas Guyot (dermoth) Assigned to: Thomas Guyot (dermoth) Summary: check_http doesn't check response time on 300's Initial Comment: 300's return codes are accepted as OK by default, but some checks, notably warning/critical time, aren't done on 300 return codes. I didn't had time to rewrite this correctly and test it troughfully, but this simple patch will go on with other tests when 300's are accepted as OK. Ideally, response time should be checked when 300!=CRITICAL, and I also on when expecting a string. ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2008-01-08 14:42 Message: Logged In: YES user_id=375623 Originator: YES For the heads up, I just applied it against 1.4.11 and I checked it; it does not prevent redirects. It only change the behavior if oneredirect == STATE_OK and redirs only happens if oneredirect == STATE_DEPENDENT. However if oneredirect == STATE_WARNING it will not detect critical times either, so it fix oneredirect == OK (-f ok, default) but not oneredirect == STATE_WARNING (-f warning). For that reason it should rather be fixed the proper way. The proper fix is likely doing something like following redirect if oneredirect == STATE_DEPENDENT, otherwise using max_state there and in the time check section, and properly handling output as well. It will definitely need careful work and testing, but meanwhile this patch is *safe* but incomplete. ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-06-12 19:55 Message: Logged In: YES user_id=375623 Originator: YES Indeed this patch looks strange... It was not necessarily intended for inclusion (just a hack), I don't use it anymore and it's been so long I don't even remember why it wasn't "right"... I wasn't a NP developer when I submitted it... I'll assign it to myself and will look over it when I have time (Certainly not until august unfortunately). Thomas ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-12 14:09 Message: Logged In: YES user_id=1694341 Originator: NO Hi Thomas, I looked over the patch and i guess, this would prevent the actual redirect. We should also take care of changes to the time measuring behaviour and mention changes in NEWS or similar so that people don't wonder why their performance got worse :) Could you bring up some time look at this? Matthias ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2006-03-28 17:41 Message: Logged In: YES user_id=375623 Forgot the check_box ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1460312&group_id=29880 From mgerber at leitwerk.de Tue Jan 8 21:00:27 2008 From: mgerber at leitwerk.de (Mike Gerber) Date: Tue, 8 Jan 2008 21:00:27 +0100 Subject: [Nagiosplug-devel] Restricting Nagios' SSH access (was: Re: NRPE Authentication/Authorization?? DEVS PLEASE READ) In-Reply-To: <47833150.200@bier.homeip.net> References: <47822EEA.3080807@googlemail.com> <47833150.200@bier.homeip.net> Message-ID: <20080108200027.GN30573@nin.lan.rwsr-xr-x.de> * Florian Gleixner schrieb: > > Is there any chance we can have authentication added to NRPE like we do > > with NSCA where you must have at the very least a shared secret? > I vote for this too. check_by_ssh can be an alternative sometimes, but > sometimes it is not desireable to have the nagios server full ssh access > to the monitored machine. You don't need full SSH access. You need to be able to execute the Nagios plugins, let's say they're located in /usr/lib/nagios/plugins/: # cat /home/nagios/.ssh/authorized_keys command="/usr/bin/nagios-ssh-commands",no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-dss AAAAA[...]Tvj6wQ== nagios at nagios-server # cat /usr/bin/nagios-ssh-commands #!/bin/sh logtag=`basename $0` if echo "$SSH_ORIGINAL_COMMAND" | egrep -q "^/usr/lib/nagios/plugins/[a-zA-Z0-9\.:,%/_ -]+$"; then logger -t "$logtag" "Allowing command \"$SSH_ORIGINAL_COMMAND\"" exec $SSH_ORIGINAL_COMMAND else logger -t "$logtag" "ALERT: NOT allowing command \"$SSH_ORIGINAL_COMMAND\"" echo "ALERT: NOT allowing command \"$SSH_ORIGINAL_COMMAND\"" exit 2 fi Cheers, Mike -- ------------------------------------------------------------------ Mike Gerber Management Internet/Security Development LEITWERK GmbH http://www.leitwerk.de Im Ettenbach 13a Fon: +49 7805 918 0 77767 Appenweier Fax: +49 7805 918 200 ------------------------------------------------------------------ Unternehmensform: Gesellschaft mit beschr. Haftung Firmensitz: 77767 Appenweier-Urloffen Eingetragen im Handelsregister: AG Freiburg i.Br., HRB 472015 Gesch?ftsf?hrer: Martin Foshag, Benoit Girerd USt-IdNr.: DE 1422 18361 ------------------------------------------------------------------ From dermoth at aei.ca Wed Jan 9 07:01:10 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Wed, 09 Jan 2008 01:01:10 -0500 Subject: [Nagiosplug-devel] N::P wrapper functions for max_state/max_state_alt Message-ID: <47846326.3050908@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I patched N::P to add a max_state_alt in Functions.pm and wrapper functions in Nagios/Plugin.pm. I'm not sure if it's right, but I tested with both Nagios::Plugin::max_state() and $np->max_state() and they both seems to work, even though in the latter the first argument passed to max_stats is a reference to an object. I'm not sure if it's the right way to do it... If anyone with knowledge of Perl packages can review it that would be greatly appreciated. Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHhGMl6dZ+Kt5BchYRAtUPAKDj8iEUlVY7B+elIajhYTwJr5eHzACeNNTo 9INtsv5b2xq8nh7BEdteTjg= =ua41 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: N__P.max_state_alt.patch Type: text/x-diff Size: 2746 bytes Desc: not available URL: From noreply at sourceforge.net Wed Jan 9 15:22:25 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Jan 2008 06:22:25 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1864225 ] check_procs under SunOS 5.10 broken Message-ID: Bugs item #1864225, was opened at 2008-01-04 22:37 Message generated for change (Comment added) made by valloo99 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1864225&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs under SunOS 5.10 broken Initial Comment: Hi, i just compiled the 4.11 plugins on a $ uname -a SunOS spnb51 5.10 Generic_118833-24 sun4v sparc SUNW,Sun-Fire-T200 and found that check_procs does not work correctly. $ ps -ef | grep cron root 15100 1 0 Nov 08 ? 1:06 /usr/sbin/cron $ /usr/ucb/ps -alxwwn | grep cron 0 0 15100 1 0 59 20 2784 1048 60015774482 S ? 1:06 /usr/sbin/cron Cron is running, but.... check_procs -w :10 -c 1: -C cron PROCS CRITICAL: 0 processes with command name '/usr/sbin/cron' Running check-procs with -vvv shows, that it uses /usr/ucb/ps -alxwwn and actually parses the right line proc#=0 uid=0 vsz=2784 rss=1048 pid=15100 ppid=1 pcpu=0.00 stat=S etime= prog= args=/usr/sbin/cron but as you see, prog is empty and what should be prog is recognized as argument. Please change the configure.in (the buggy lines in configure are 24967 ff) so that it reads: ac_cv_ps_varlist="&procuid,&procpid,&procppid,&procpcpu,&procvsz,&procrs s,procstat,procprog,&pos" ac_cv_ps_command="/usr/ucb/ps -alxwwn" ac_cv_ps_format="%*s %d %d %d %d %*d %*d %d %d%*[ 0123456789abcdef]%[OSR ZT]%*s %*s %s %n" ac_cv_ps_cols=9 (add procprog to the varlist, add a %s at the end of format and increase cols) Then it looks good: $ check_procs -w :10 -c 1: -C cron PROCS OK: 1 process with command name 'cron' Greetings from Munich, Gerhard ---------------------------------------------------------------------- Comment By: Vincent Alloo (valloo99) Date: 2008-01-09 15:22 Message: Logged In: YES user_id=1977333 Originator: NO Becarefull, the "/usr/ucb/ps -alxwwn" can be non-parseable on some system: 0 18046 20095 20093 0 59 20 3056 1996 fffffe8d3efb8776 S pts/9 0:00 -tcsh 0 0 911 3293 0 59 20837008 1188 ffffffff85c0af42 S ? 0:00 /usr/local/bin/rsync -aWz -v --stats --progress --rsync-path=/apps/free/rsync/2 I still don't have a working check_procs for sol10/x86. ---------------------------------------------------------------------- Comment By: gerhard lausser (lausser) Date: 2008-01-05 02:01 Message: Logged In: YES user_id=613416 Originator: YES Hi Matthias, the last release i compiled on this machine was 1.4.2 and at that time configure decided to use /usr/bin/ps. I can try a 1.4.10 tomorrow but i am sure, it is also broken. I currently look at configure.in line 519. Particularly noticeable is the missing procprog variable in the ac_cv_ps_format. As one can see in the egrep line above, there _is_ a COMMAND field in the output, but the sscanf will not catch it. Gerhard p.s. this ps_format is not used for SunOS in general, only for SunOS whose /usr/ucb/ps -alxwwn shows the expected output format. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-01-05 01:13 Message: Logged In: YES user_id=1694341 Originator: NO Hi Gerhard, Are you sure this is valid for all operating systems where uname -s returns SunOS? I guess this (mis-)behaviour is not new in 1.4.11, right? Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1864225&group_id=29880 From noreply at sourceforge.net Wed Jan 9 15:46:58 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Jan 2008 06:46:58 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1867716 ] check_snmp invalid performance data Message-ID: Bugs item #1867716, was opened at 2008-01-09 15:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1867716&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joerg Linge (pitchfork) Assigned to: Nobody/Anonymous (nobody) Summary: check_snmp invalid performance data Initial Comment: check_snmp produces invalid performance data. Version: check_snmp v1859 (nagios-plugins 1.4.11) Call: check_snmp -H localhost -C public -o sysUpTime.0 Output: SNMP OK - Timeticks: (49845368) 5 d | SNMPv2-MIB::sysUpTime.0=Timeticks: (49845368) 5 d OS: Linux SuSE 2.6.11.4-21.17-bigsmp Compiler: gcc version 3.3.5 20050117 (prerelease) (SUSE Linux) Kind regards J?rg ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1867716&group_id=29880 From mike at primaledge.ca Wed Jan 9 02:02:42 2008 From: mike at primaledge.ca (mike) Date: Tue, 8 Jan 2008 17:02:42 -0800 Subject: [Nagiosplug-devel] patch for check_by_ssh passive mode In-Reply-To: <668670f40801071501j6f38a70bo228c90544d4460b0@mail.gmail.com> References: <668670f40801071501j6f38a70bo228c90544d4460b0@mail.gmail.com> Message-ID: <668670f40801081702u13e1e576h43d4a547c9e50f66@mail.gmail.com> last one, I promise. using it now in prod and it's working great. ok i'm gone (btw i'm not on this list, send comments, hate mail etc to me directly) --- check_by_ssh.c.orig 2007-09-23 05:26:03.000000000 -0700 +++ check_by_ssh.c 2008-01-08 13:39:49.000000000 -0800 @@ -100,7 +100,7 @@ main (int argc, char **argv) skip_stderr = chld_err.lines; /* UNKNOWN if (non-skipped) output found on stderr */ - if(chld_err.lines > skip_stderr) { + if(!passive && chld_err.lines > skip_stderr) { printf (_("Remote command execution failed: %s\n"), chld_err.line[skip_stderr]); return STATE_UNKNOWN; @@ -133,16 +133,14 @@ main (int argc, char **argv) commands = 0; for(i = skip_stdout; i < chld_out.lines; i++) { status_text = strstr (chld_out.line[i], "STATUS CODE: "); - if (status_text == NULL) { - printf ("%s", chld_out.line[i]); - return result; - } if (service[commands] && status_text && sscanf (status_text, "STATUS CODE: %d", &cresult) == 1) { - fprintf (fp, "[%d] PROCESS_SERVICE_CHECK_RESULT;%s;%s;%d;%s\n", - (int) local_time, host_shortname, service[commands++], - cresult, chld_out.line[i]); + fprintf (fp, "[%d] PROCESS_SERVICE_CHECK_RESULT;%s;%s;%d;", + (int) local_time, host_shortname, service[commands++], cresult); + if (i > 0 && strstr (chld_out.line[i-1], "STATUS CODE: ") == 0) fprintf (fp, "%s\n", chld_out.line[i-1]); + else fprintf (fp, "%s - Remote command exit status %d\n", + state_text(cresult), cresult); } } @@ -307,7 +305,7 @@ process_arguments (int argc, char **argv asprintf (&remotecmd, "%s", argv[c]); } - if (commands > 1) + if (passive) asprintf (&remotecmd, "%s;echo STATUS CODE: $?;", remotecmd); if (remotecmd == NULL || strlen (remotecmd) <= 1) On 1/7/08, mike wrote: > > The current one doesn't really work. It basically did nothing if there > was a \n anywhere in the command output (most commands return a \n at the > end :) This makes it better by writing the last output line (up to the \n) > in the log, and doesn't abort if one of the commands has an error. Still > isn't perfect but it's usable. > Enjoy, > Mike > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Wed Jan 9 16:22:45 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Jan 2008 07:22:45 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1867736 ] check_http: allow simultaneous use size and content checks Message-ID: Patches item #1867736, was opened at 2008-01-09 15:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1867736&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: svenx (svenx) Assigned to: Nobody/Anonymous (nobody) Summary: check_http: allow simultaneous use size and content checks Initial Comment: Patch against Plugin Version: check_http v1892 (nagios-plugins 1.4.11) Plugin Name: check_http Example Plugin Commandline: ./check_http -H www.example.net -p 80 -f follow -m 700:750 -s 'reserved' Tested on operating system: Ubuntu 7.10 Tested on architecture: i686 Tested with compiler: gcc 4.1.3 This patch enables the user to perform both page size checking together with string or regex content checking. Previously, the string/regex test ignored the page size check. Sven Ulland ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1867736&group_id=29880 From noreply at sourceforge.net Wed Jan 9 16:47:44 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Jan 2008 07:47:44 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1864225 ] check_procs under SunOS 5.10 broken Message-ID: Bugs item #1864225, was opened at 2008-01-04 22:37 Message generated for change (Comment added) made by lausser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1864225&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs under SunOS 5.10 broken Initial Comment: Hi, i just compiled the 4.11 plugins on a $ uname -a SunOS spnb51 5.10 Generic_118833-24 sun4v sparc SUNW,Sun-Fire-T200 and found that check_procs does not work correctly. $ ps -ef | grep cron root 15100 1 0 Nov 08 ? 1:06 /usr/sbin/cron $ /usr/ucb/ps -alxwwn | grep cron 0 0 15100 1 0 59 20 2784 1048 60015774482 S ? 1:06 /usr/sbin/cron Cron is running, but.... check_procs -w :10 -c 1: -C cron PROCS CRITICAL: 0 processes with command name '/usr/sbin/cron' Running check-procs with -vvv shows, that it uses /usr/ucb/ps -alxwwn and actually parses the right line proc#=0 uid=0 vsz=2784 rss=1048 pid=15100 ppid=1 pcpu=0.00 stat=S etime= prog= args=/usr/sbin/cron but as you see, prog is empty and what should be prog is recognized as argument. Please change the configure.in (the buggy lines in configure are 24967 ff) so that it reads: ac_cv_ps_varlist="&procuid,&procpid,&procppid,&procpcpu,&procvsz,&procrs s,procstat,procprog,&pos" ac_cv_ps_command="/usr/ucb/ps -alxwwn" ac_cv_ps_format="%*s %d %d %d %d %*d %*d %d %d%*[ 0123456789abcdef]%[OSR ZT]%*s %*s %s %n" ac_cv_ps_cols=9 (add procprog to the varlist, add a %s at the end of format and increase cols) Then it looks good: $ check_procs -w :10 -c 1: -C cron PROCS OK: 1 process with command name 'cron' Greetings from Munich, Gerhard ---------------------------------------------------------------------- >Comment By: gerhard lausser (lausser) Date: 2008-01-09 16:47 Message: Logged In: YES user_id=613416 Originator: YES You are right, when SZ and/or RSS grow too large, ther is no space left between NI and SZ or between SZ and RS: Not parseable: 0 0 16901 1 0 59 205028812184 30004e2e1a6 S ? 278:36 /opt/VRTSsmf/bin/vxsmf.bin -p RootSMF -B I replaced ac_cv_ps_format="%*s %d %d %d %d %*d %*d %d %d%*[...... with ac_cv_ps_format="%*s %d %d %d %d %*d %*2d %5d %d%*[.... and it successfully scanned these lines. (nice can have a maximum of 2 digits, and size can have a maximum of 5 digits. at least when the values still fit into the columns. maybe there are situations, where even the columns don't fit any more, then i think we have no chance) But then i found another one: Not parseable: 0 0 16101 351 0 54 20 3104 2664 ? S ? 0:00 /usr/openv/netbackup/bin/bpcd Here we have a WCHAN value of "?". Adding a ? to the conversion shoud should solve this. So i propose to change line 521 of configure.in to: ac_cv_ps_format="%*s %d %d %d %d %*d %*2d %5d %d%*[ 0123456789abcdef?]%[OSRZT]%*s %*s %s %n" Gerhard ---------------------------------------------------------------------- Comment By: Vincent Alloo (valloo99) Date: 2008-01-09 15:22 Message: Logged In: YES user_id=1977333 Originator: NO Becarefull, the "/usr/ucb/ps -alxwwn" can be non-parseable on some system: 0 18046 20095 20093 0 59 20 3056 1996 fffffe8d3efb8776 S pts/9 0:00 -tcsh 0 0 911 3293 0 59 20837008 1188 ffffffff85c0af42 S ? 0:00 /usr/local/bin/rsync -aWz -v --stats --progress --rsync-path=/apps/free/rsync/2 I still don't have a working check_procs for sol10/x86. ---------------------------------------------------------------------- Comment By: gerhard lausser (lausser) Date: 2008-01-05 02:01 Message: Logged In: YES user_id=613416 Originator: YES Hi Matthias, the last release i compiled on this machine was 1.4.2 and at that time configure decided to use /usr/bin/ps. I can try a 1.4.10 tomorrow but i am sure, it is also broken. I currently look at configure.in line 519. Particularly noticeable is the missing procprog variable in the ac_cv_ps_format. As one can see in the egrep line above, there _is_ a COMMAND field in the output, but the sscanf will not catch it. Gerhard p.s. this ps_format is not used for SunOS in general, only for SunOS whose /usr/ucb/ps -alxwwn shows the expected output format. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-01-05 01:13 Message: Logged In: YES user_id=1694341 Originator: NO Hi Gerhard, Are you sure this is valid for all operating systems where uname -s returns SunOS? I guess this (mis-)behaviour is not new in 1.4.11, right? Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1864225&group_id=29880 From noreply at sourceforge.net Wed Jan 9 17:57:58 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Jan 2008 08:57:58 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1864225 ] check_procs under SunOS 5.10 broken Message-ID: Bugs item #1864225, was opened at 2008-01-04 22:37 Message generated for change (Comment added) made by valloo99 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1864225&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs under SunOS 5.10 broken Initial Comment: Hi, i just compiled the 4.11 plugins on a $ uname -a SunOS spnb51 5.10 Generic_118833-24 sun4v sparc SUNW,Sun-Fire-T200 and found that check_procs does not work correctly. $ ps -ef | grep cron root 15100 1 0 Nov 08 ? 1:06 /usr/sbin/cron $ /usr/ucb/ps -alxwwn | grep cron 0 0 15100 1 0 59 20 2784 1048 60015774482 S ? 1:06 /usr/sbin/cron Cron is running, but.... check_procs -w :10 -c 1: -C cron PROCS CRITICAL: 0 processes with command name '/usr/sbin/cron' Running check-procs with -vvv shows, that it uses /usr/ucb/ps -alxwwn and actually parses the right line proc#=0 uid=0 vsz=2784 rss=1048 pid=15100 ppid=1 pcpu=0.00 stat=S etime= prog= args=/usr/sbin/cron but as you see, prog is empty and what should be prog is recognized as argument. Please change the configure.in (the buggy lines in configure are 24967 ff) so that it reads: ac_cv_ps_varlist="&procuid,&procpid,&procppid,&procpcpu,&procvsz,&procrs s,procstat,procprog,&pos" ac_cv_ps_command="/usr/ucb/ps -alxwwn" ac_cv_ps_format="%*s %d %d %d %d %*d %*d %d %d%*[ 0123456789abcdef]%[OSR ZT]%*s %*s %s %n" ac_cv_ps_cols=9 (add procprog to the varlist, add a %s at the end of format and increase cols) Then it looks good: $ check_procs -w :10 -c 1: -C cron PROCS OK: 1 process with command name 'cron' Greetings from Munich, Gerhard ---------------------------------------------------------------------- Comment By: Vincent Alloo (valloo99) Date: 2008-01-09 17:57 Message: Logged In: YES user_id=1977333 Originator: NO Fro info, this config is working for both Solaris8 and Soalris 10: ./configure --with-ps-command="/usr/bin/ps -eo 's uid pid ppid vsz rss pcpu etime comm args'" \ --with-ps-format='%s %d %d %d %d %d %f %s %s %n' \ --with-ps-cols=10 \ --with-ps-varlist='procstat,&procuid,&procpid,&procppid,&procvsz,&procrss,&procpcpu,procetime,procprog,&pos' Hope it helps. ---------------------------------------------------------------------- Comment By: gerhard lausser (lausser) Date: 2008-01-09 16:47 Message: Logged In: YES user_id=613416 Originator: YES You are right, when SZ and/or RSS grow too large, ther is no space left between NI and SZ or between SZ and RS: Not parseable: 0 0 16901 1 0 59 205028812184 30004e2e1a6 S ? 278:36 /opt/VRTSsmf/bin/vxsmf.bin -p RootSMF -B I replaced ac_cv_ps_format="%*s %d %d %d %d %*d %*d %d %d%*[...... with ac_cv_ps_format="%*s %d %d %d %d %*d %*2d %5d %d%*[.... and it successfully scanned these lines. (nice can have a maximum of 2 digits, and size can have a maximum of 5 digits. at least when the values still fit into the columns. maybe there are situations, where even the columns don't fit any more, then i think we have no chance) But then i found another one: Not parseable: 0 0 16101 351 0 54 20 3104 2664 ? S ? 0:00 /usr/openv/netbackup/bin/bpcd Here we have a WCHAN value of "?". Adding a ? to the conversion shoud should solve this. So i propose to change line 521 of configure.in to: ac_cv_ps_format="%*s %d %d %d %d %*d %*2d %5d %d%*[ 0123456789abcdef?]%[OSRZT]%*s %*s %s %n" Gerhard ---------------------------------------------------------------------- Comment By: Vincent Alloo (valloo99) Date: 2008-01-09 15:22 Message: Logged In: YES user_id=1977333 Originator: NO Becarefull, the "/usr/ucb/ps -alxwwn" can be non-parseable on some system: 0 18046 20095 20093 0 59 20 3056 1996 fffffe8d3efb8776 S pts/9 0:00 -tcsh 0 0 911 3293 0 59 20837008 1188 ffffffff85c0af42 S ? 0:00 /usr/local/bin/rsync -aWz -v --stats --progress --rsync-path=/apps/free/rsync/2 I still don't have a working check_procs for sol10/x86. ---------------------------------------------------------------------- Comment By: gerhard lausser (lausser) Date: 2008-01-05 02:01 Message: Logged In: YES user_id=613416 Originator: YES Hi Matthias, the last release i compiled on this machine was 1.4.2 and at that time configure decided to use /usr/bin/ps. I can try a 1.4.10 tomorrow but i am sure, it is also broken. I currently look at configure.in line 519. Particularly noticeable is the missing procprog variable in the ac_cv_ps_format. As one can see in the egrep line above, there _is_ a COMMAND field in the output, but the sscanf will not catch it. Gerhard p.s. this ps_format is not used for SunOS in general, only for SunOS whose /usr/ucb/ps -alxwwn shows the expected output format. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-01-05 01:13 Message: Logged In: YES user_id=1694341 Originator: NO Hi Gerhard, Are you sure this is valid for all operating systems where uname -s returns SunOS? I guess this (mis-)behaviour is not new in 1.4.11, right? Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1864225&group_id=29880 From holger at CIS.FU-Berlin.DE Wed Jan 9 19:05:02 2008 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Wed, 9 Jan 2008 19:05:02 +0100 Subject: [Nagiosplug-devel] r1879: check_tcp now returns UNKNOWN with an invalid hostname on command line In-Reply-To: <47836C28.9070104@aei.ca> References: <47835E04.9050206@aei.ca> <47836C28.9070104@aei.ca> Message-ID: <20080109180502.GL28313306@CIS.FU-Berlin.DE> * Thomas Guyot-Sionnest [2008-01-08 07:27]: > On 08/01/08 06:48 AM, Ton Voon wrote: > > Fair point. I specifically made this change because in a Nagios > > configuration $HOSTADDRESS$ wasn't set, so the check_tcp was > > effectively running: > > > > check_tcp -H -w 5 > > > > and mistaking -w for the hostname. My thinking was that this was a > > command line options error, hence UNKNOWN. However, I've obviously > > implemented it as a hostname resolution check. > > > > Looking at http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN78 > > , it's a higher level error so shouldn't be UNKNOWN and should be > > CRITICAL. > > > > So, sorry, I screwed up here twice: once for changing to UNKNOWN, and > > twice for not checking the test results to see the impact. > > > > I'll revert back now. > > The arguments goes in both ways. It is fair to think name resolution > belongs to check_dns The problem is that there are not only the two cases that DNS (or some other "dependant-upon-functionality") either works or doesn't, but there's the third case that it works in general but not for some particular check. E.g., the record for "example.com" might be missing or broken even though your DNS server is fine. Therefore, I definitely want a notification if "check_ping example.com" fails due to a failure in resolving "example.com", _unless_ the actual DNS check also fails. IMHO, the only clean solution to this really is to properly reflect such dependencies in the Nagios configuration. > and in my setups I use IPs everywhere I can and the dns servers have > their own checks. For the reason I stated above (and for maintainability), I use host names everywhere I can :-) > I didn't push my vote towards the reversal of your commit because some > other plugins I checked goes UNKNOWN on invalid hosts too. I'd personally vote against UNKNOWN in these cases, as the only use I see in making a distinction between CRITICAL and UNKNOWN is to be able to handle an UNKNOWN differently from a CRITICAL (especially regarding notifications, of course); and if a check fails for reasons which are out of the plugin's scope, I personally want notifications suppressed only by Nagios' dependency logic and not via the plugin status. The plugin just cannot know whether only the "example.com" record or DNS in general is broken, so IMHO it shouldn't try to be too clever, here. If we'd consistently return an UNKOWN _only_ on _internal_ plugin errors as the guidelines state, then I'd configure Nagios to only send me (i.e., the Nagios admin) notifications about UNKNOWNs so that others wouldn't be bothered with these. But in practice, an UNKNOWN is sometimes returned on problems others want to be notified about, so I make no distinction between CRITICAL and UNKNOWN in my configuration. Then again, internal plugin errors are rare, so this isn't a real problem for me. However, for this reason I don't really care that much about the CRITICAL<->UNKNOWN distinction in practice :-P > The developer guideline should be clear on this (if it's not already) > and plugins not following the specs should be fixed. Yes. > I don't believe this should apply for plugin that use a protocol to > check something behind it (i.e. check_snmp, check_nrpe, check_by_ssh, > check_nt). For this special case, I have no strong opinion. I agree it's different from cases such as DNS. The chance that only the Nagios check (and not an actual service provided to customers) is affected by problems and therefore that only the Nagios admin wants to be notified is probably higher than in case of "example.com" not resolving. Holger From holger at CIS.FU-Berlin.DE Wed Jan 9 20:34:44 2008 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Wed, 9 Jan 2008 20:34:44 +0100 Subject: [Nagiosplug-devel] [Nagios-users] Licensing of Official and 3rd Party Plugins In-Reply-To: <477CAF42.5050004@googlemail.com> References: <477B8DBE.7020207@googlemail.com> <951D2145-FCA9-47DF-AF69-B52BB7E05DF5@secure-computing.net> <477CAF42.5050004@googlemail.com> Message-ID: <20080109193444.GM28313306@CIS.FU-Berlin.DE> * Hari Sekhon [2008-01-03 09:47]: > Are there any plans to upgrade the official plugin distribution to GPLv3? This hasn't been discussed yet, so I can only speak for myself. > Are there any advantages/disadvantages to doing so? First, almost all of the official plugins explicitly state that they're licensed under "either version 2 of the License, or (at your option) any later version", so you can use and redistribute them with GPLv3 code already. Obviously, the "advantage" of switching to a GPLv3-only license and therefore prohibiting redistribution under the GPLv2 would be to force the additional restrictions imposed by the GPLv3, which I'm personally not interested in. It would also make using other people's GPLv2-only code impossible. On the other hand, as soon as we want to include some GPLv3-only code, we'll have to upgrade to GPLv3-only, so I'd _guess_ it'll happen some day anyway. > Does anyone have any opinions in licensing of 3rd party plugins as GPLv3 > instead of GPLv2? Personally, I'm somewhat annoyed by the various incompatible Open Source licenses floating around, as it they can make re-using code impossible in some cases. As the GPLv3 is yet another license which is incompatible to everything else, I'm not really a fan of it. I would prefer "GPLv2 or higher" licenses over "GPLv3-only", if possible. However, that's just me. People who are interested in the new GPLv3 restrictions will of course prefer "GPLv3-only" licenses. Holger From MiCkEy2002 at nagios-portal.de Wed Jan 9 18:59:12 2008 From: MiCkEy2002 at nagios-portal.de (=?iso-8859-15?Q?Michael_L=FCbben?=) Date: Wed, 09 Jan 2008 18:59:12 +0100 Subject: [Nagiosplug-devel] Nagios::Plugin with debugging function? Message-ID: <1199901552.47850b709e461@nagios-portal.de> Hi @all, in last time, i have script a many plugins in perl. In all my plugins, i have add a debugging. This debbuging can be enable in the script. When nagios start this plugin for a check, then the plugin write debug information to file. This make fixing from bugs or problems a many easier! Was that a function for the Nagios::plugin modul? In the moment i don't use the Nagios::Plugin modul, but for the next plugins i have planed that and than was a debugging important for me! Was that a function for the Nagios::plugin modul? Bye Michael From ton.voon at altinity.com Wed Jan 9 21:33:05 2008 From: ton.voon at altinity.com (Ton Voon) Date: Wed, 9 Jan 2008 20:33:05 +0000 Subject: [Nagiosplug-devel] Nagios::Plugin with debugging function? In-Reply-To: <1199901552.47850b709e461@nagios-portal.de> References: <1199901552.47850b709e461@nagios-portal.de> Message-ID: Hi Michael, On 9 Jan 2008, at 17:59, Michael L?bben wrote: > in last time, i have script a many plugins in perl. In all my > plugins, i > have add a debugging. This debbuging can be enable in the script. When > nagios start this plugin for a check, then the plugin write debug > information to file. This make fixing from bugs or problems a many > easier! > Was that a function for the Nagios::plugin modul? In the moment i > don't use > the Nagios::Plugin modul, but for the next plugins i have planed > that and > than was a debugging important for me! > Was that a function for the Nagios::plugin modul? You can use -v -v -v and then set debug messages within the plugin so that you get more data, but that is sent to stdout, not to a file. If you doing anything within the perl script, you probably should use the perl debugger - here's a quick guide I found on the net: http://www.devshed.com/c/a/Perl/Using-The-Perl-Debugger/ It is one of the best parts of perl... Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From MiCkEy2002 at nagios-portal.de Thu Jan 10 07:57:17 2008 From: MiCkEy2002 at nagios-portal.de (=?iso-8859-15?Q?Michael_L=FCbben?=) Date: Thu, 10 Jan 2008 07:57:17 +0100 Subject: [Nagiosplug-devel] Nagios::Plugin with debugging function? In-Reply-To: References: <1199901552.47850b709e461@nagios-portal.de> Message-ID: <1199948237.4785c1cd90fbc@nagios-portal.de> Hello Ton, thanks for this information, but when i write my plugins and enable my debugging, so i can see for example which parameters use nagios for the plugin etc. Example: 1199806213.86788 ---------------===== Start debugging =====--------------- 1199806213.89714 Get content from url: ******************** TEST = 100 ******************** 1199806213.89727 OK - NO Errors! 1199806213.89734 Exit code: 0 1199806213.89738 Plugin executen time 0.03s 1199806213.89738 ---------------===== Stop debugging =====---------------- That was only a idea! What do you think about that? Bye Michael --- Urspr?ngliche Nachricht --- Datum: 09.01.2008 21:33 Von: Ton Voon An: Nagios Plugin Development Mailing List Betreff: Re: [Nagiosplug-devel] Nagios::Plugin with debugging function? > Hi Michael, > > On 9 Jan 2008, at 17:59, Michael L?bben wrote: > > > in last time, i have script a many plugins in perl. In all my > > plugins, i > > have add a debugging. This debbuging can be enable in the script. When > > nagios start this plugin for a check, then the plugin write debug > > information to file. This make fixing from bugs or problems a many > > easier! > > Was that a function for the Nagios::plugin modul? In the moment i > > don't use > > the Nagios::Plugin modul, but for the next plugins i have planed > > that and > > than was a debugging important for me! > > Was that a function for the Nagios::plugin modul? > > You can use -v -v -v and then set debug messages within the plugin so > that you get more data, but that is sent to stdout, not to a file. > > If you doing anything within the perl script, you probably should use > the perl debugger - here's a quick guide I found on the net: http://www.devshed.com/c/a/Perl/Using-The-Perl-Debugger/ > > It is one of the best parts of perl... > > Ton > > http://www.altinity.com > UK: +44 (0)870 787 9243 > US: +1 866 879 9184 > Fax: +44 (0)845 280 1725 > Skype: tonvoon > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > From noreply at sourceforge.net Thu Jan 10 09:42:46 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Jan 2008 00:42:46 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1864225 ] check_procs under SunOS 5.10 broken Message-ID: Bugs item #1864225, was opened at 2008-01-04 22:37 Message generated for change (Comment added) made by valloo99 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1864225&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs under SunOS 5.10 broken Initial Comment: Hi, i just compiled the 4.11 plugins on a $ uname -a SunOS spnb51 5.10 Generic_118833-24 sun4v sparc SUNW,Sun-Fire-T200 and found that check_procs does not work correctly. $ ps -ef | grep cron root 15100 1 0 Nov 08 ? 1:06 /usr/sbin/cron $ /usr/ucb/ps -alxwwn | grep cron 0 0 15100 1 0 59 20 2784 1048 60015774482 S ? 1:06 /usr/sbin/cron Cron is running, but.... check_procs -w :10 -c 1: -C cron PROCS CRITICAL: 0 processes with command name '/usr/sbin/cron' Running check-procs with -vvv shows, that it uses /usr/ucb/ps -alxwwn and actually parses the right line proc#=0 uid=0 vsz=2784 rss=1048 pid=15100 ppid=1 pcpu=0.00 stat=S etime= prog= args=/usr/sbin/cron but as you see, prog is empty and what should be prog is recognized as argument. Please change the configure.in (the buggy lines in configure are 24967 ff) so that it reads: ac_cv_ps_varlist="&procuid,&procpid,&procppid,&procpcpu,&procvsz,&procrs s,procstat,procprog,&pos" ac_cv_ps_command="/usr/ucb/ps -alxwwn" ac_cv_ps_format="%*s %d %d %d %d %*d %*d %d %d%*[ 0123456789abcdef]%[OSR ZT]%*s %*s %s %n" ac_cv_ps_cols=9 (add procprog to the varlist, add a %s at the end of format and increase cols) Then it looks good: $ check_procs -w :10 -c 1: -C cron PROCS OK: 1 process with command name 'cron' Greetings from Munich, Gerhard ---------------------------------------------------------------------- Comment By: Vincent Alloo (valloo99) Date: 2008-01-10 09:42 Message: Logged In: YES user_id=1977333 Originator: NO Fro info, this config is working for both Solaris8 and Soalris 10: ./configure --with-ps-command="/usr/bin/ps -eo 's uid pid ppid vsz rss pcpu etime comm args'" \ --with-ps-format='%s %d %d %d %d %d %f %s %s %n' \ --with-ps-cols=10 \ --with-ps-varlist='procstat,&procuid,&procpid,&procppid,&procvsz,&procrss,&procpcpu,procetime,procprog,&pos' Hope it helps. ---------------------------------------------------------------------- Comment By: Vincent Alloo (valloo99) Date: 2008-01-09 17:57 Message: Logged In: YES user_id=1977333 Originator: NO Fro info, this config is working for both Solaris8 and Soalris 10: ./configure --with-ps-command="/usr/bin/ps -eo 's uid pid ppid vsz rss pcpu etime comm args'" \ --with-ps-format='%s %d %d %d %d %d %f %s %s %n' \ --with-ps-cols=10 \ --with-ps-varlist='procstat,&procuid,&procpid,&procppid,&procvsz,&procrss,&procpcpu,procetime,procprog,&pos' Hope it helps. ---------------------------------------------------------------------- Comment By: gerhard lausser (lausser) Date: 2008-01-09 16:47 Message: Logged In: YES user_id=613416 Originator: YES You are right, when SZ and/or RSS grow too large, ther is no space left between NI and SZ or between SZ and RS: Not parseable: 0 0 16901 1 0 59 205028812184 30004e2e1a6 S ? 278:36 /opt/VRTSsmf/bin/vxsmf.bin -p RootSMF -B I replaced ac_cv_ps_format="%*s %d %d %d %d %*d %*d %d %d%*[...... with ac_cv_ps_format="%*s %d %d %d %d %*d %*2d %5d %d%*[.... and it successfully scanned these lines. (nice can have a maximum of 2 digits, and size can have a maximum of 5 digits. at least when the values still fit into the columns. maybe there are situations, where even the columns don't fit any more, then i think we have no chance) But then i found another one: Not parseable: 0 0 16101 351 0 54 20 3104 2664 ? S ? 0:00 /usr/openv/netbackup/bin/bpcd Here we have a WCHAN value of "?". Adding a ? to the conversion shoud should solve this. So i propose to change line 521 of configure.in to: ac_cv_ps_format="%*s %d %d %d %d %*d %*2d %5d %d%*[ 0123456789abcdef?]%[OSRZT]%*s %*s %s %n" Gerhard ---------------------------------------------------------------------- Comment By: Vincent Alloo (valloo99) Date: 2008-01-09 15:22 Message: Logged In: YES user_id=1977333 Originator: NO Becarefull, the "/usr/ucb/ps -alxwwn" can be non-parseable on some system: 0 18046 20095 20093 0 59 20 3056 1996 fffffe8d3efb8776 S pts/9 0:00 -tcsh 0 0 911 3293 0 59 20837008 1188 ffffffff85c0af42 S ? 0:00 /usr/local/bin/rsync -aWz -v --stats --progress --rsync-path=/apps/free/rsync/2 I still don't have a working check_procs for sol10/x86. ---------------------------------------------------------------------- Comment By: gerhard lausser (lausser) Date: 2008-01-05 02:01 Message: Logged In: YES user_id=613416 Originator: YES Hi Matthias, the last release i compiled on this machine was 1.4.2 and at that time configure decided to use /usr/bin/ps. I can try a 1.4.10 tomorrow but i am sure, it is also broken. I currently look at configure.in line 519. Particularly noticeable is the missing procprog variable in the ac_cv_ps_format. As one can see in the egrep line above, there _is_ a COMMAND field in the output, but the sscanf will not catch it. Gerhard p.s. this ps_format is not used for SunOS in general, only for SunOS whose /usr/ucb/ps -alxwwn shows the expected output format. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-01-05 01:13 Message: Logged In: YES user_id=1694341 Originator: NO Hi Gerhard, Are you sure this is valid for all operating systems where uname -s returns SunOS? I guess this (mis-)behaviour is not new in 1.4.11, right? Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1864225&group_id=29880 From hpsekhon at googlemail.com Thu Jan 10 10:37:28 2008 From: hpsekhon at googlemail.com (Hari Sekhon) Date: Thu, 10 Jan 2008 09:37:28 +0000 Subject: [Nagiosplug-devel] [Nagios-users] Licensing of Official and 3rd Party Plugins In-Reply-To: <20080109193444.GM28313306@CIS.FU-Berlin.DE> References: <477B8DBE.7020207@googlemail.com> <951D2145-FCA9-47DF-AF69-B52BB7E05DF5@secure-computing.net> <477CAF42.5050004@googlemail.com> <20080109193444.GM28313306@CIS.FU-Berlin.DE> Message-ID: <4785E758.9030106@googlemail.com> Holger Weiss wrote: > * Hari Sekhon [2008-01-03 09:47]: > >> Are there any plans to upgrade the official plugin distribution to GPLv3? >> > > This hasn't been discussed yet, so I can only speak for myself. > > >> Are there any advantages/disadvantages to doing so? >> > > First, almost all of the official plugins explicitly state that they're > licensed under "either version 2 of the License, or (at your option) any > later version", so you can use and redistribute them with GPLv3 code > already. Obviously, the "advantage" of switching to a GPLv3-only > license and therefore prohibiting redistribution under the GPLv2 would > be to force the additional restrictions imposed by the GPLv3, which I'm > personally not interested in. It would also make using other people's > GPLv2-only code impossible. On the other hand, as soon as we want to > include some GPLv3-only code, we'll have to upgrade to GPLv3-only, so > I'd _guess_ it'll happen some day anyway. > > >> Does anyone have any opinions in licensing of 3rd party plugins as GPLv3 >> instead of GPLv2? >> > > Personally, I'm somewhat annoyed by the various incompatible Open Source > licenses floating around, as it they can make re-using code impossible > in some cases. As the GPLv3 is yet another license which is > incompatible to everything else, I'm not really a fan of it. I would > prefer "GPLv2 or higher" licenses over "GPLv3-only", if possible. > However, that's just me. People who are interested in the new GPLv3 > restrictions will of course prefer "GPLv3-only" licenses. > > Holger > Thanks for the response, I think your points are valid. I'll continue to use a GPL version 2 or higher license in order to try to maintain compatibility and then I'll go GPLv3 when more people get in to it. Hari -- Hari Sekhon From dermoth at aei.ca Thu Jan 10 12:16:50 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Thu, 10 Jan 2008 06:16:50 -0500 Subject: [Nagiosplug-devel] [Nagios-users] Licensing of Official and 3rd Party Plugins In-Reply-To: <4785E758.9030106@googlemail.com> References: <477B8DBE.7020207@googlemail.com> <951D2145-FCA9-47DF-AF69-B52BB7E05DF5@secure-computing.net> <477CAF42.5050004@googlemail.com> <20080109193444.GM28313306@CIS.FU-Berlin.DE> <4785E758.9030106@googlemail.com> Message-ID: <4785FEA2.5090409@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/01/08 04:37 AM, Hari Sekhon wrote: > Holger Weiss wrote: >> Personally, I'm somewhat annoyed by the various incompatible Open Source >> licenses floating around, as it they can make re-using code impossible >> in some cases. As the GPLv3 is yet another license which is >> incompatible to everything else, I'm not really a fan of it. I would >> prefer "GPLv2 or higher" licenses over "GPLv3-only", if possible. Incompatibilities among GPL license are only brought by "GPLvX-only" type of licenses. Programs and libraries using "GPLvX or higher" will always avoid compatibility problems among GPL licenses. GPL is meant to be incompatible with other licenses. If you're worried about that you should use the BSD license but keep in mind that OSS wouldn't be nearly as strong as it is with BSD. Many companies contributing to OSS would just rip the code if it was under the BSD license. >> However, that's just me. People who are interested in the new GPLv3 >> restrictions will of course prefer "GPLv3-only" licenses. >> >> Holger >> > Thanks for the response, I think your points are valid. I'll continue to > use a GPL version 2 or higher license in order to try to maintain > compatibility > and then I'll go GPLv3 when more people get in to it. That will likely change for the next release if we update Gnulib to the latest version, as they bumped their license to GPL v3. GPL requires code linking to GPL be GPL as well, and obviously of the same version. http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHhf6i6dZ+Kt5BchYRAny3AJ4/XXIhyZy9vPJQ5nXsZtqf+lgyTQCgkqR+ iQ8QffcPyN5U8reih1C0a/U= =1qFB -----END PGP SIGNATURE----- From holger at CIS.FU-Berlin.DE Thu Jan 10 15:35:13 2008 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Thu, 10 Jan 2008 15:35:13 +0100 Subject: [Nagiosplug-devel] [Nagios-users] Licensing of Official and 3rd Party Plugins In-Reply-To: <4785FEA2.5090409@aei.ca> References: <477B8DBE.7020207@googlemail.com> <951D2145-FCA9-47DF-AF69-B52BB7E05DF5@secure-computing.net> <477CAF42.5050004@googlemail.com> <20080109193444.GM28313306@CIS.FU-Berlin.DE> <4785E758.9030106@googlemail.com> <4785FEA2.5090409@aei.ca> Message-ID: <20080110143513.GQ28313306@CIS.FU-Berlin.DE> * Thomas Guyot-Sionnest [2008-01-10 06:16]: > On 10/01/08 04:37 AM, Hari Sekhon wrote: > > Holger Weiss wrote: > >> Personally, I'm somewhat annoyed by the various incompatible Open Source > >> licenses floating around, as it they can make re-using code impossible > >> in some cases. As the GPLv3 is yet another license which is > >> incompatible to everything else, I'm not really a fan of it. I would > >> prefer "GPLv2 or higher" licenses over "GPLv3-only", if possible. > > Incompatibilities among GPL license are only brought by "GPLvX-only" > type of licenses. Programs and libraries using "GPLvX or higher" will > always avoid compatibility problems among GPL licenses. Which is why I prefer the latter over the former, but not all people do it this way. See the Linux kernel's license, for example. > GPL is meant to be incompatible with other licenses. If you're worried > about that you should use the BSD license Yes, I personally do :-) > but keep in mind that OSS wouldn't be nearly as strong as it is with > BSD. Many companies contributing to OSS would just rip the code if it > was under the BSD license. That's the idea of the GPL and in some cases it definitely worked, but I doubt this effect is really that strong in practice. My guess would be that most companies which don't want to (or cannot) contribute their code to OSS won't be forced by the GPL to do so, they simply won't use GPL code. > > Thanks for the response, I think your points are valid. I'll continue to > > use a GPL version 2 or higher license in order to try to maintain > > compatibility and then I'll go GPLv3 when more people get in to it. > > That will likely change for the next release if we update Gnulib to the > latest version, as they bumped their license to GPL v3. I thought so, too, but I checked before my other posting and most of Gnulib is actually LGPL'd, despite the headers in the C files: | Many modules are provided dual-license, either GPL or LGPL at your | option. The headers of files in the lib directory (e.g., lib/error.c) | state GPL for convenience, since the bulk of current gnulib users are | GPL'd programs. But the files in the modules directory (e.g., | modules/error) state the true license of each file, and when you use | 'gnulib-tool --lgpl --import ', gnulib-tool either rewrites | the files to have an LGPL header as part of copying them from gnulib | to your project directory, or fails because the modules you requested | were not licensed under LGPL. [ http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=COPYING ] AFAICS, we're currently not using any of the GPL-only Gnulib files. Anyway, if you (or others) would like to upgrade to GPLv3, I'm perfectly fine with that. I just stated my personal preference, but the license question isn't important to me. Holger From ae at op5.se Thu Jan 10 15:48:06 2008 From: ae at op5.se (Andreas Ericsson) Date: Thu, 10 Jan 2008 15:48:06 +0100 Subject: [Nagiosplug-devel] [Nagios-users] Licensing of Official and 3rd Party Plugins In-Reply-To: <20080110143513.GQ28313306@CIS.FU-Berlin.DE> References: <477B8DBE.7020207@googlemail.com> <951D2145-FCA9-47DF-AF69-B52BB7E05DF5@secure-computing.net> <477CAF42.5050004@googlemail.com> <20080109193444.GM28313306@CIS.FU-Berlin.DE> <4785E758.9030106@googlemail.com> <4785FEA2.5090409@aei.ca> <20080110143513.GQ28313306@CIS.FU-Berlin.DE> Message-ID: <47863026.8080405@op5.se> Holger Weiss wrote: > * Thomas Guyot-Sionnest [2008-01-10 06:16]: >> On 10/01/08 04:37 AM, Hari Sekhon wrote: >>> Holger Weiss wrote: >>>> Personally, I'm somewhat annoyed by the various incompatible Open Source >>>> licenses floating around, as it they can make re-using code impossible >>>> in some cases. As the GPLv3 is yet another license which is >>>> incompatible to everything else, I'm not really a fan of it. I would >>>> prefer "GPLv2 or higher" licenses over "GPLv3-only", if possible. >> Incompatibilities among GPL license are only brought by "GPLvX-only" >> type of licenses. Programs and libraries using "GPLvX or higher" will >> always avoid compatibility problems among GPL licenses. > > Which is why I prefer the latter over the former, but not all people do > it this way. See the Linux kernel's license, for example. > It isn't really an issue for the kernel though, as it's never loaded as a library. >> GPL is meant to be incompatible with other licenses. If you're worried >> about that you should use the BSD license > > Yes, I personally do :-) > BSD license has other issues. If there had ever been a perfect one, the need for a billion different ones wouldn't be needed. >> but keep in mind that OSS wouldn't be nearly as strong as it is with >> BSD. Many companies contributing to OSS would just rip the code if it >> was under the BSD license. > > That's the idea of the GPL and in some cases it definitely worked, but I > doubt this effect is really that strong in practice. My guess would be > that most companies which don't want to (or cannot) contribute their > code to OSS won't be forced by the GPL to do so, they simply won't use > GPL code. > Or they'll use GPL code and have in-house modifications that are never made public, which is exactly what they would have done had it been BSD- or MIT-licensed instead. >>> Thanks for the response, I think your points are valid. I'll continue to >>> use a GPL version 2 or higher license in order to try to maintain >>> compatibility and then I'll go GPLv3 when more people get in to it. >> That will likely change for the next release if we update Gnulib to the >> latest version, as they bumped their license to GPL v3. > > I thought so, too, but I checked before my other posting and most of > Gnulib is actually LGPL'd, despite the headers in the C files: > > | Many modules are provided dual-license, either GPL or LGPL at your > | option. The headers of files in the lib directory (e.g., lib/error.c) > | state GPL for convenience, since the bulk of current gnulib users are > | GPL'd programs. But the files in the modules directory (e.g., > | modules/error) state the true license of each file, and when you use > | 'gnulib-tool --lgpl --import ', gnulib-tool either rewrites > | the files to have an LGPL header as part of copying them from gnulib > | to your project directory, or fails because the modules you requested > | were not licensed under LGPL. > > [ http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=COPYING ] > > AFAICS, we're currently not using any of the GPL-only Gnulib files. > > Anyway, if you (or others) would like to upgrade to GPLv3, I'm perfectly > fine with that. I just stated my personal preference, but the license > question isn't important to me. > For the plugins it won't matter in the slightest which version is used, as it isn't a library and so other programs will never have to think about it. That will only become an issue if someone tries to use the API functions in a GPLv2-only program. otoh, I fail to see that switching to GPLv3 buys the plugins-project anything, so *shrug* -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From thomas at zango.com Thu Jan 10 16:13:01 2008 From: thomas at zango.com (Thomas Guyot-Sionnest) Date: Thu, 10 Jan 2008 10:13:01 -0500 Subject: [Nagiosplug-devel] [Nagios-users] Licensing of Official and 3rd Party Plugins In-Reply-To: <47863026.8080405@op5.se> References: <477B8DBE.7020207@googlemail.com> <951D2145-FCA9-47DF-AF69-B52BB7E05DF5@secure-computing.net> <477CAF42.5050004@googlemail.com> <20080109193444.GM28313306@CIS.FU-Berlin.DE> <4785E758.9030106@googlemail.com> <4785FEA2.5090409@aei.ca> <20080110143513.GQ28313306@CIS.FU-Berlin.DE> <47863026.8080405@op5.se> Message-ID: <478635FD.7030504@zango.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Ericsson wrote: > Holger Weiss wrote: >> I thought so, too, but I checked before my other posting and most of >> Gnulib is actually LGPL'd, despite the headers in the C files: >> >> | Many modules are provided dual-license, either GPL or LGPL at your >> | option. The headers of files in the lib directory (e.g., lib/error.c) >> | state GPL for convenience, since the bulk of current gnulib users are >> | GPL'd programs. But the files in the modules directory (e.g., >> | modules/error) state the true license of each file, and when you use >> | 'gnulib-tool --lgpl --import ', gnulib-tool either rewrites >> | the files to have an LGPL header as part of copying them from gnulib >> | to your project directory, or fails because the modules you requested >> | were not licensed under LGPL. >> >> [ http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=COPYING ] >> >> AFAICS, we're currently not using any of the GPL-only Gnulib files. >> >> Anyway, if you (or others) would like to upgrade to GPLv3, I'm perfectly >> fine with that. I just stated my personal preference, but the license >> question isn't important to me. Thanks for the clarification, Holger. I'll check whenever we can --lgpl it. > For the plugins it won't matter in the slightest which version is used, > as it isn't a library and so other programs will never have to think > about it. That will only become an issue if someone tries to use the > API functions in a GPLv2-only program. Holger have plans to make a C library similar in functionality to Nagios::Plugin. Although that would not be an issue either if the library is lgpl'ed, a discussion about the license of this project haven't even started... - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHhjX96dZ+Kt5BchYRAurTAJ0dQxRaIs0pDr+JWeOE/l5ZpJBzyQCgrP0W KO1k1yaDl3Rlkmp+dN0ZAqw= =SrOh -----END PGP SIGNATURE----- From holger at CIS.FU-Berlin.DE Thu Jan 10 16:20:28 2008 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Thu, 10 Jan 2008 16:20:28 +0100 Subject: [Nagiosplug-devel] [Nagios-users] Licensing of Official and 3rd Party Plugins In-Reply-To: <47863026.8080405@op5.se> References: <477B8DBE.7020207@googlemail.com> <951D2145-FCA9-47DF-AF69-B52BB7E05DF5@secure-computing.net> <477CAF42.5050004@googlemail.com> <20080109193444.GM28313306@CIS.FU-Berlin.DE> <4785E758.9030106@googlemail.com> <4785FEA2.5090409@aei.ca> <20080110143513.GQ28313306@CIS.FU-Berlin.DE> <47863026.8080405@op5.se> Message-ID: <20080110152028.GR28313306@CIS.FU-Berlin.DE> * Andreas Ericsson [2008-01-10 15:48]: > Holger Weiss wrote: > > * Thomas Guyot-Sionnest [2008-01-10 06:16]: > >> Incompatibilities among GPL license are only brought by "GPLvX-only" > >> type of licenses. Programs and libraries using "GPLvX or higher" will > >> always avoid compatibility problems among GPL licenses. > > > > Which is why I prefer the latter over the former, but not all people do > > it this way. See the Linux kernel's license, for example. > > It isn't really an issue for the kernel though, as it's never loaded as > a library. The issue is using kernel code directly in other projects. If this weren't an issue there'd be no point in using an Open Source license for non-library-code. > >> GPL is meant to be incompatible with other licenses. If you're worried > >> about that you should use the BSD license > > > > Yes, I personally do :-) > > BSD license has other issues. If there had ever been a perfect one, the > need for a billion different ones wouldn't be needed. *shrug*, I don't see the "issues", I guess the main reason the variants emerged was to keep the lawyers of various institutions busy. Well, an issue I do see is with Berkeley's original 4-clause license, which isn't compatible with the GPL, but I don't use that. > >> but keep in mind that OSS wouldn't be nearly as strong as it is with > >> BSD. Many companies contributing to OSS would just rip the code if it > >> was under the BSD license. > > > > That's the idea of the GPL and in some cases it definitely worked, but I > > doubt this effect is really that strong in practice. My guess would be > > that most companies which don't want to (or cannot) contribute their > > code to OSS won't be forced by the GPL to do so, they simply won't use > > GPL code. > > Or they'll use GPL code and have in-house modifications that are never > made public, which is exactly what they would have done had it been BSD- > or MIT-licensed instead. Yup. > For the plugins it won't matter in the slightest which version is used, > as it isn't a library and so other programs will never have to think > about it. It doesn't matter for the plugins, but authors which like to use plugin code in their projects would have to think about it. I guess it's just me, but I've been bitten by license incompatibility issues more than once, so I'm a bit annoyed of these. However, I fully agree it's no big deal for the plugin's project. I should've kept silent :-) Holger From ae at op5.se Thu Jan 10 16:40:26 2008 From: ae at op5.se (Andreas Ericsson) Date: Thu, 10 Jan 2008 16:40:26 +0100 Subject: [Nagiosplug-devel] [Nagios-users] Licensing of Official and 3rd Party Plugins In-Reply-To: <20080110152028.GR28313306@CIS.FU-Berlin.DE> References: <477B8DBE.7020207@googlemail.com> <951D2145-FCA9-47DF-AF69-B52BB7E05DF5@secure-computing.net> <477CAF42.5050004@googlemail.com> <20080109193444.GM28313306@CIS.FU-Berlin.DE> <4785E758.9030106@googlemail.com> <4785FEA2.5090409@aei.ca> <20080110143513.GQ28313306@CIS.FU-Berlin.DE> <47863026.8080405@op5.se> <20080110152028.GR28313306@CIS.FU-Berlin.DE> Message-ID: <47863C6A.9010704@op5.se> Holger Weiss wrote: > * Andreas Ericsson [2008-01-10 15:48]: >> Holger Weiss wrote: >>> * Thomas Guyot-Sionnest [2008-01-10 06:16]: >>>> Incompatibilities among GPL license are only brought by "GPLvX-only" >>>> type of licenses. Programs and libraries using "GPLvX or higher" will >>>> always avoid compatibility problems among GPL licenses. >>> Which is why I prefer the latter over the former, but not all people do >>> it this way. See the Linux kernel's license, for example. >> It isn't really an issue for the kernel though, as it's never loaded as >> a library. > > The issue is using kernel code directly in other projects. If this > weren't an issue there'd be no point in using an Open Source license for > non-library-code. > True that, but 90% of the even half-generic code in the kernel has dual licenses. Most of it is in the public domain (cryptography framework, fe). > >> For the plugins it won't matter in the slightest which version is used, >> as it isn't a library and so other programs will never have to think >> about it. > > It doesn't matter for the plugins, but authors which like to use plugin > code in their projects would have to think about it. > > I guess it's just me, but I've been bitten by license incompatibility > issues more than once, so I'm a bit annoyed of these. In that case, stick with "GPL, v2 or later". Change for the sake of changing is only profitable for aspirin vendors. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From noreply at sourceforge.net Thu Jan 10 21:24:33 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Jan 2008 12:24:33 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1868822 ] check_http link fails with openssl installed Message-ID: Bugs item #1868822, was opened at 2008-01-10 15:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1868822&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: Dave van Nierop (ca28200) Assigned to: Nobody/Anonymous (nobody) Summary: check_http link fails with openssl installed Initial Comment: Compile and link of nagios-plugins-1.4.10 succeeds, but a compile and link of nagios-plugins-1.4.11 fails. Problem: All function references for np_net_ssl_* (included in netutils.h) in plugins/check_http.c are unresolved when the linker fires in. I tried to figure it out, but just didn't have the time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1868822&group_id=29880 From noreply at sourceforge.net Fri Jan 11 22:55:59 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Jan 2008 13:55:59 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1867716 ] check_snmp invalid performance data Message-ID: Bugs item #1867716, was opened at 2008-01-09 09:46 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1867716&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joerg Linge (pitchfork) Assigned to: Nobody/Anonymous (nobody) Summary: check_snmp invalid performance data Initial Comment: check_snmp produces invalid performance data. Version: check_snmp v1859 (nagios-plugins 1.4.11) Call: check_snmp -H localhost -C public -o sysUpTime.0 Output: SNMP OK - Timeticks: (49845368) 5 d | SNMPv2-MIB::sysUpTime.0=Timeticks: (49845368) 5 d OS: Linux SuSE 2.6.11.4-21.17-bigsmp Compiler: gcc version 3.3.5 20050117 (prerelease) (SUSE Linux) Kind regards J?rg ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2008-01-11 16:55 Message: Logged In: YES user_id=375623 Originator: NO This is the expected behavior; chhek_snmp doesn't know anything about TimeTicks Perhaps passing -Ot would help, but it would require different parsing and I don't know how it would affect any the the many special data formats in SNMP. This would be better suited as a feature request. However it would be much easier to just write a local check (run trough nrpe or check_by_ssh) that parse uptime. Also you should keep in mind that the SNMP uptime is the SNMP daemon uptime, not the server uptime (in other words you're ok as long as you don't restart the daemon). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1867716&group_id=29880 From noreply at sourceforge.net Sat Jan 12 12:07:27 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Jan 2008 03:07:27 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1867716 ] check_snmp invalid performance data Message-ID: Bugs item #1867716, was opened at 2008-01-09 15:46 Message generated for change (Comment added) made by pitchfork You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1867716&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joerg Linge (pitchfork) Assigned to: Nobody/Anonymous (nobody) Summary: check_snmp invalid performance data Initial Comment: check_snmp produces invalid performance data. Version: check_snmp v1859 (nagios-plugins 1.4.11) Call: check_snmp -H localhost -C public -o sysUpTime.0 Output: SNMP OK - Timeticks: (49845368) 5 d | SNMPv2-MIB::sysUpTime.0=Timeticks: (49845368) 5 d OS: Linux SuSE 2.6.11.4-21.17-bigsmp Compiler: gcc version 3.3.5 20050117 (prerelease) (SUSE Linux) Kind regards J?rg ---------------------------------------------------------------------- >Comment By: Joerg Linge (pitchfork) Date: 2008-01-12 12:07 Message: Logged In: YES user_id=1353850 Originator: YES sysUpTime.0 was just an example! I think check_snmp should only provide performance data on interger values. Just to be sure the performance data ist valid. J?rg ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-01-11 22:55 Message: Logged In: YES user_id=375623 Originator: NO This is the expected behavior; chhek_snmp doesn't know anything about TimeTicks Perhaps passing -Ot would help, but it would require different parsing and I don't know how it would affect any the the many special data formats in SNMP. This would be better suited as a feature request. However it would be much easier to just write a local check (run trough nrpe or check_by_ssh) that parse uptime. Also you should keep in mind that the SNMP uptime is the SNMP daemon uptime, not the server uptime (in other words you're ok as long as you don't restart the daemon). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1867716&group_id=29880 From dataking at gmail.com Thu Jan 10 23:56:37 2008 From: dataking at gmail.com (Charlie Heselton) Date: Thu, 10 Jan 2008 23:56:37 +0100 (CET) Subject: [Nagiosplug-devel] (no subject) In-Reply-To: <302ce8b50708011457q1ec0c5cbn114effc1da2d59bb@mail.gmail.com> References: <302ce8b50708011457q1ec0c5cbn114effc1da2d59bb@mail.gmail.com> Message-ID: <20080110225637.2C155778164@desire.netways.de> Hi Jim I have the same issue. As far as I can tell, the required libraries exist, but the build still can't find them. Per the FAQ, I've used the '--with-gd-lib=/usr/local/lib' and '--with-gd-inc=/usr/local/include' as configure options. However, my libjpeg files are in /opt/sfw/lib. I even tried adding '--with-jpeg-lib=/opt/sfw/lib'. Still no joy. Any other suggestions? Thanks. - Charlie Heselton (dataking) ----------------------- This thread is located in the archive at this URL: http://www.nagiosexchange.org/nagiosplug-devel.31.0.html?&tx_maillisttofaq_pi1[showUid]=3234 From perldork at webwizarddesign.com Mon Jan 14 00:54:05 2008 From: perldork at webwizarddesign.com (Max) Date: Sun, 13 Jan 2008 18:54:05 -0500 Subject: [Nagiosplug-devel] Nagios::Plugin::SNMP Message-ID: Hi, I do a lot of custom SNMP checks that don't have existing plugins; most of the plugin work I do is in perl. I have created a sub-class of Nagios::Plugin for my use for this, it uses Net::SNMP for its' SNMP requests, and includes convenience functionality: * Automatically adds SNMP-related arguments to Nagios::Plugin * --snmp-version * --snmp-timeout * --snmp-debug - turns on debugging in Net::SNMP * --auth-username * --auth-password * --auth-protocol * --rocommunity * --hostname * --port * Adds --warning and --critical to args as well * Validates SNMP arguments by overloading getopts to include a validation method to make sure the SNMP arguments passed in are valid for the version of SNMP selected. * Appends an USAGE string to the 'usage' parameter passed in via new() in Nagios::Plugin * Includes an easy to use get() and walk() routine. * Includes connect and disconnect routines; connect can be called explicitly or will be called implicitly when get() or walk() is called. I thought using the namespace Nagios::Plugin::SNMP would be appropriate since it does subclass Nagios::Plugin, but figured I better write you, the developers and maintainers of the module :), to see if that is ok with you; I would like to publish this module on CPAN when it is ready for prime time. If you are not ok with the namespace i have chosen, that is ok too :) .. please let me know. Will publish the code online once I have stable code, just figured it would be better to ask permission for the namespace right away so that if you are not ok with this I can choose another before I set up project space. Regardless of whether you allow me to use this name space or not I will give credits to you in my module docs for your module along with links to the SF.net project page :). Regards, Max From flo at bier.homeip.net Mon Jan 14 09:43:08 2008 From: flo at bier.homeip.net (Florian Gleixner) Date: Mon, 14 Jan 2008 09:43:08 +0100 Subject: [Nagiosplug-devel] performance data output and locale settings Message-ID: <478B209C.8010708@bier.homeip.net> Hi, i encountered a problem that affects collecting performance data. If the locale is not C or similar, then the performance data may have a different number format. Example: with german locale the performance data of check_disk and check_dns (and others) contain a "," instead of a "." as decimal point. In the plugin development guide http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN203 the "," is not allowed. Nagios addons that parse the performance data may also be started with another locale and cannot guess the number format. Florian Gleixner From dermoth at aei.ca Mon Jan 14 14:48:00 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Mon, 14 Jan 2008 08:48:00 -0500 Subject: [Nagiosplug-devel] Any reason NOT to use AC_SYS_LARGEFILE? Message-ID: <478B6810.4000807@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I asked on the gnulib mailing list why fsusage doesn't try using 64bits statvfs... It turns out 64-bit file-system interfaces are used automatically when using AC_SYS_LARGEFILE in configure.in (no other code change needed). I'm wondering if this subject was brought up before... Is there any reason why we're not using that? This seems to fix at least check_disk on 16TB filesystem on Solaris. Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHi2gQ6dZ+Kt5BchYRApW3AKDskwJlIt0ipqqzZiddp1xKmjZ30QCgpGZk RjLlFpo+LppjsBizGf9f0pg= =/Bzt -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: lfs.patch Type: text/x-diff Size: 293 bytes Desc: not available URL: From gavin at openfusion.com.au Mon Jan 14 23:38:57 2008 From: gavin at openfusion.com.au (Gavin Carr) Date: Tue, 15 Jan 2008 09:38:57 +1100 Subject: [Nagiosplug-devel] Nagios::Plugin::SNMP In-Reply-To: References: Message-ID: <20080114223857.GA21206@openfusion.com.au> Hi Max, On Sun, Jan 13, 2008 at 06:54:05PM -0500, Max wrote: > I do a lot of custom SNMP checks that don't have existing plugins; > most of the plugin work I do is in perl. > > I have created a sub-class of Nagios::Plugin for my use for this, it > uses Net::SNMP for its' SNMP requests, and includes convenience > functionality: > * Automatically adds SNMP-related arguments to Nagios::Plugin > * --snmp-version > * --snmp-timeout > * --snmp-debug - turns on debugging in Net::SNMP > * --auth-username > * --auth-password > * --auth-protocol > * --rocommunity > * --hostname > * --port > * Adds --warning and --critical to args as well > * Validates SNMP arguments by overloading getopts to include a validation > method to make sure the SNMP arguments passed in are valid for the > version of SNMP selected. > * Appends an USAGE string to the 'usage' parameter passed in via new() in > Nagios::Plugin > * Includes an easy to use get() and walk() routine. > * Includes connect and disconnect routines; connect can be called explicitly > or will be called implicitly when get() or walk() is called. > > I thought using the namespace Nagios::Plugin::SNMP would be > appropriate since it does subclass Nagios::Plugin, but figured I > better write you, the developers and maintainers of the module :), to > see if that is ok with you; I would like to publish this module on > CPAN when it is ready for prime time. Looks good to me - seems to fit in pretty well with what we're trying to do with N::P, and seems nicely generic. Thanks for asking. > If you are not ok with the namespace i have chosen, that is ok too :) > .. please let me know. Will publish the code online once I have > stable code, just figured it would be better to ask permission for the > namespace right away so that if you are not ok with this I can choose > another before I set up project space. > > Regardless of whether you allow me to use this name space or not I > will give credits to you in my module docs for your module along with > links to the SF.net project page :). If you could let us know if you set up a webpage or version control tree or anything for it what would be great. Cheers, Gavin From perldork at webwizarddesign.com Thu Jan 17 04:40:57 2008 From: perldork at webwizarddesign.com (Max) Date: Wed, 16 Jan 2008 22:40:57 -0500 Subject: [Nagiosplug-devel] Nagios::Plugin::SNMP In-Reply-To: <20080114223857.GA21206@openfusion.com.au> References: <20080114223857.GA21206@openfusion.com.au> Message-ID: Hi Gavin, On Jan 14, 2008 5:38 PM, Gavin Carr wrote: > Looks good to me - seems to fit in pretty well with what we're trying to do > with N::P, and seems nicely generic. Thanks for asking. Excellent, thank you! > If you could let us know if you set up a webpage or version control tree > or anything for it what would be great. Absolutely, bit busy right now but I will do that before too long :). - Max From noreply at sourceforge.net Thu Jan 17 14:00:07 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Jan 2008 05:00:07 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1873649 ] check_oracle.sh oracle 8 Message-ID: Patches item #1873649, was opened at 2008-01-17 14:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1873649&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: Roland Halder (rolandhalder) Assigned to: Nobody/Anonymous (nobody) Summary: check_oracle.sh oracle 8 Initial Comment: check_oracle v1.1 (nagios-plugins 1.4.11) Problem: When we used this plugin and queried an ORACLE 8 Server we got this error: ORA-00933: SQL command not properly ended Cause: In Oracle 8 the join statement does not exist. Solution: Modified the statement using the old syntax with WHERE ... (+)= ... AND Checked the new Version successfully against both: Oracle Database 10g Release 10.2.0.1.0 - 64bit Production and the formerly failed Oracle8i Release 8.1.7.4.1 - Production ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1873649&group_id=29880 From noreply at sourceforge.net Thu Jan 17 20:31:02 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Jan 2008 11:31:02 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1874041 ] check_dig does not parse timeout value Message-ID: Bugs item #1874041, was opened at 2008-01-17 11:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1874041&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: LoOoD (loood) Assigned to: Nobody/Anonymous (nobody) Summary: check_dig does not parse timeout value Initial Comment: When I try to specifiy a timeout value for check_dig, it doesn't send that value to the actual dig command. I'm using version 1.4.11 of the plugins and its running on centos4 $ ~/libexec/check_dig -H localhost -l host.domain.com -t 1300 -v /usr/bin/dig @localhost -p 53 host.domain.com -t A Looking for: 'host.domain.com' DNS WARNING - 10.010 seconds response time (dig returned an error status)|time=10.010081s;;;0.000000 $ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1874041&group_id=29880 From noreply at sourceforge.net Mon Jan 21 18:39:41 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Jan 2008 09:39:41 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1876638 ] check_linux_raid.pl confuses devices Message-ID: Bugs item #1876638, was opened at 2008-01-21 17:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1876638&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: alain williams (addw) Assigned to: Nobody/Anonymous (nobody) Summary: check_linux_raid.pl confuses devices Initial Comment: If the entries in /proc/mdstat are not separated by a blank line, the plugin doesn't realise that a new device is started. It also doesn't recognise a --help option. I attach a patch to fix both of these issues. It is against nagios-plugins-1.4.11 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1876638&group_id=29880 From noreply at sourceforge.net Tue Jan 22 16:27:44 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Jan 2008 07:27:44 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1877447 ] Example usage of LDAP plugin Message-ID: Patches item #1877447, was opened at 2008-01-22 15:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1877447&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: nexroth (nexroth) Assigned to: Nobody/Anonymous (nobody) Summary: Example usage of LDAP plugin Initial Comment: Hi. This is small fix of command.cfg. It adds example usage of check_ldap. Greetings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1877447&group_id=29880 From noreply at sourceforge.net Wed Jan 23 15:24:57 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Jan 2008 06:24:57 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1878144 ] check_mailq need root privileges Message-ID: Patches item #1878144, was opened at 2008-01-23 15:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1878144&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_mailq need root privileges Initial Comment: Hi, i have several Linux servers, where you need special privileges to execute /usr/bin/mailq. On these servers i got: -bash-2.05b$ check_mailq -w 1 -c 5 Program mode requires special privileges, e.g., root or TrustedUser. CRITICAL: Error code 78 returned from /usr/bin/mailq Allowing the Nagios user to call check_mailq with sudo was not an option, because the plugins are owned and writable by this user himself. Yet it was possible to get sudo privileges for the /usr/bin/mailq command. I then patched check_mailq so that it first would ask "sudo -l" if $utils::PATH_TO_MAILQ is among the priviledged commands and if yes, call it with "sudo $utils::PATH_TO_MAILQ" instead. I appended the patch. Do you think this could be an option for plugins in general? I am sure, there are other installations which prefer sudo "/usr/bin/command inside the plugin" over sudo plugin Greetings from Munich, Gerhard ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1878144&group_id=29880 From noreply at sourceforge.net Wed Jan 23 16:24:41 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Jan 2008 07:24:41 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1878144 ] check_mailq need root privileges Message-ID: Patches item #1878144, was opened at 2008-01-23 09:24 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1878144&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: Pending Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_mailq need root privileges Initial Comment: Hi, i have several Linux servers, where you need special privileges to execute /usr/bin/mailq. On these servers i got: -bash-2.05b$ check_mailq -w 1 -c 5 Program mode requires special privileges, e.g., root or TrustedUser. CRITICAL: Error code 78 returned from /usr/bin/mailq Allowing the Nagios user to call check_mailq with sudo was not an option, because the plugins are owned and writable by this user himself. Yet it was possible to get sudo privileges for the /usr/bin/mailq command. I then patched check_mailq so that it first would ask "sudo -l" if $utils::PATH_TO_MAILQ is among the priviledged commands and if yes, call it with "sudo $utils::PATH_TO_MAILQ" instead. I appended the patch. Do you think this could be an option for plugins in general? I am sure, there are other installations which prefer sudo "/usr/bin/command inside the plugin" over sudo plugin Greetings from Munich, Gerhard ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2008-01-23 10:24 Message: Logged In: YES user_id=375623 Originator: NO Why don't you just remove any write permissions from Nagios for the plugin and plugin's folder? If you have dependencies you can also use a different path. Make it owned from root with read access for Nagios or everyone, for example. I don't believe adding sudo commands in plugin scripts is a viable solution, however an alternative would be to define the mailq path/command as "/usr/bin/sudo /usr/bin/mailq" or whichever path you need. ./configure --with-mailq-command="/usr/bin/sudo /usr/bin/mailq" I haven't tried but this may work already... If it don't and you have a fix for that, we'll merge it (and document this trick in the web site). Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1878144&group_id=29880 From noreply at sourceforge.net Wed Jan 23 16:55:37 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Jan 2008 07:55:37 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1878144 ] check_mailq need root privileges Message-ID: Patches item #1878144, was opened at 2008-01-23 15:24 Message generated for change (Comment added) made by lausser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1878144&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Open Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_mailq need root privileges Initial Comment: Hi, i have several Linux servers, where you need special privileges to execute /usr/bin/mailq. On these servers i got: -bash-2.05b$ check_mailq -w 1 -c 5 Program mode requires special privileges, e.g., root or TrustedUser. CRITICAL: Error code 78 returned from /usr/bin/mailq Allowing the Nagios user to call check_mailq with sudo was not an option, because the plugins are owned and writable by this user himself. Yet it was possible to get sudo privileges for the /usr/bin/mailq command. I then patched check_mailq so that it first would ask "sudo -l" if $utils::PATH_TO_MAILQ is among the priviledged commands and if yes, call it with "sudo $utils::PATH_TO_MAILQ" instead. I appended the patch. Do you think this could be an option for plugins in general? I am sure, there are other installations which prefer sudo "/usr/bin/command inside the plugin" over sudo plugin Greetings from Munich, Gerhard ---------------------------------------------------------------------- >Comment By: gerhard lausser (lausser) Date: 2008-01-23 16:55 Message: Logged In: YES user_id=613416 Originator: YES Setting PATH_TO_MAILQ to "sudo mailq" doesn't work, because there are some if (-x $PATH_TO_MAILQ) { in the code. Removing write permissions for the plugins is not an option. There is an extra nagios team which owns the plugin directories and which has to be able to do updates for the nagios client software on all servers any time. Configuring the plugins so that mailq is called with sudo by default would require two versions of the plugin. One for the servers (SuSE) where everyone may execute mailq and one for the others where mailq is restricted to root. Gerhard ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-01-23 16:24 Message: Logged In: YES user_id=375623 Originator: NO Why don't you just remove any write permissions from Nagios for the plugin and plugin's folder? If you have dependencies you can also use a different path. Make it owned from root with read access for Nagios or everyone, for example. I don't believe adding sudo commands in plugin scripts is a viable solution, however an alternative would be to define the mailq path/command as "/usr/bin/sudo /usr/bin/mailq" or whichever path you need. ./configure --with-mailq-command="/usr/bin/sudo /usr/bin/mailq" I haven't tried but this may work already... If it don't and you have a fix for that, we'll merge it (and document this trick in the web site). Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1878144&group_id=29880 From noreply at sourceforge.net Wed Jan 23 23:06:33 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Jan 2008 14:06:33 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1878144 ] check_mailq need root privileges Message-ID: Patches item #1878144, was opened at 2008-01-23 09:24 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1878144&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_mailq need root privileges Initial Comment: Hi, i have several Linux servers, where you need special privileges to execute /usr/bin/mailq. On these servers i got: -bash-2.05b$ check_mailq -w 1 -c 5 Program mode requires special privileges, e.g., root or TrustedUser. CRITICAL: Error code 78 returned from /usr/bin/mailq Allowing the Nagios user to call check_mailq with sudo was not an option, because the plugins are owned and writable by this user himself. Yet it was possible to get sudo privileges for the /usr/bin/mailq command. I then patched check_mailq so that it first would ask "sudo -l" if $utils::PATH_TO_MAILQ is among the priviledged commands and if yes, call it with "sudo $utils::PATH_TO_MAILQ" instead. I appended the patch. Do you think this could be an option for plugins in general? I am sure, there are other installations which prefer sudo "/usr/bin/command inside the plugin" over sudo plugin Greetings from Munich, Gerhard ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2008-01-23 17:06 Message: Logged In: YES user_id=375623 Originator: NO Hmmmm.... I'm not trying to make you life harder but I still don't like your solution... So what comes to my mind is: 1. Use a different group for the Nagios team, and male the directories/plugins writable by that team 2. We could maybe do something like (not looking at the code, so it will likely need to be adapted): if ($PATH_TO_MAILQ =~ m/^(.*\/sudo)\s+(.*)$/) { if (-x $1 && -x $2) { ... } } elsif (-x $PATH_TO_MAILQ) { ... 3 (ideal but most complex to implement): Add a --with-sudo-command detection and option in configure, and a switch in mailq to use it. ---------------------------------------------------------------------- Comment By: gerhard lausser (lausser) Date: 2008-01-23 10:55 Message: Logged In: YES user_id=613416 Originator: YES Setting PATH_TO_MAILQ to "sudo mailq" doesn't work, because there are some if (-x $PATH_TO_MAILQ) { in the code. Removing write permissions for the plugins is not an option. There is an extra nagios team which owns the plugin directories and which has to be able to do updates for the nagios client software on all servers any time. Configuring the plugins so that mailq is called with sudo by default would require two versions of the plugin. One for the servers (SuSE) where everyone may execute mailq and one for the others where mailq is restricted to root. Gerhard ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-01-23 10:24 Message: Logged In: YES user_id=375623 Originator: NO Why don't you just remove any write permissions from Nagios for the plugin and plugin's folder? If you have dependencies you can also use a different path. Make it owned from root with read access for Nagios or everyone, for example. I don't believe adding sudo commands in plugin scripts is a viable solution, however an alternative would be to define the mailq path/command as "/usr/bin/sudo /usr/bin/mailq" or whichever path you need. ./configure --with-mailq-command="/usr/bin/sudo /usr/bin/mailq" I haven't tried but this may work already... If it don't and you have a fix for that, we'll merge it (and document this trick in the web site). Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1878144&group_id=29880 From noreply at sourceforge.net Wed Jan 23 23:34:15 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Jan 2008 14:34:15 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1878539 ] check_ntp_peer doesn't honor ntp flags Message-ID: Bugs item #1878539, was opened at 2008-01-23 17:34 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=1878539&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: 6 Private: No Submitted By: Thomas Guyot (dermoth) Assigned to: Thomas Guyot (dermoth) Summary: check_ntp_peer doesn't honor ntp flags Initial Comment: Just as for check_ntp patch #1798774, check_ntp_time should honor the ntp flags. I've been fooled into thinking that there were no such flags in ntp control packets but I was wrong. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1878539&group_id=29880 From benny.chis at gmail.com Thu Jan 24 13:14:35 2008 From: benny.chis at gmail.com (Ben Chisholm) Date: Thu, 24 Jan 2008 12:14:35 +0000 Subject: [Nagiosplug-devel] nagios-plugins-1.4.11 make problem Message-ID: Hi, I've had issues compiling nagios-plugins-1.4.11 on Solaris 10 (sparc). I have had a look around the web, and have seen a few post with the same problem, but no working solutions! Following are the results from configure, make, and the command itself that has issues that is called within the make command. Appreciate any suggestions or help! Regards, Ben Configure seems to work ok: ./configure -q --with-openssl=/usr/sfw appending configuration tag "CXX" to libtool appending configuration tag "F77" to libtool configure: WARNING: Skipping radius plugin configure: WARNING: install radius libs to compile this plugin (see REQUIREMENTS). configure: WARNING: Skipping check_ide_smart plugin. configure: WARNING: check_ide_smart is linux specific. It requires linux/hdreg.h and linux/types.h. configure: WARNING: Skipping mysql plugin configure: WARNING: install mysql client libs to compile this plugin (see REQUIREMENTS). configure: WARNING: Get lmstat from Globetrotter Software to monitor flexlm licenses configure: WARNING: Get smbclient from Samba.org to monitor SMB shares configure: WARNING: Get snmpget from http://net-snmp.sourceforge.net to make check_hpjd and check_snmp plugins configure: WARNING: Tried /usr/bin/perl - install Net::SNMP perl module if you want to use the perl snmp plugins configure: WARNING: Get qstat from http://www.activesw.com/people/steve/qstat.html in order to make check_game plugin configure: WARNING: Get fping from http://www.fping.com in order to make check_fping plugin configure: WARNING: Could not find qmail-qstat or eqivalent config.status: creating po/POTFILES config.status: creating po/Makefile --with-apt-get-command: --with-ping6-command: --with-ping-command: /usr/sbin/ping -n -s %s 56 %d --with-ipv6: yes --with-mysql: no --with-openssl: yes --with-gnutls: no --with-perl: /usr/bin/perl --enable-perl-modules: no --with-cgiurl: /nagios/cgi-bin --with-trusted-path: /bin:/sbin:/usr/bin:/usr/sbin ========================================= Make has an error: make make all-recursive Making all in gl make all-am Making all in lib Making all in tests Making all in plugins /bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -L. -L/usr/sfw/lib -o check_http check_http.o sslutils.o netutils.o utils.o ../lib/libnagiosplug.a ../gl/libgnu.a -lnsl -lsocket -lresolv -lssl -lcrypto -lnsl -lsocket gcc -g -O2 -o check_http check_http.o sslutils.o netutils.o utils.o -L/var/tmp/nagios/nagios-plugins-1.4.11/plugins -L/usr/sfw/lib ../lib/libnagiosplug.a ../gl/libgnu.a -lresolv -lssl -lcrypto -lnsl -lsocket Undefined first referenced symbol in file OpenSSL_add_all_algorithms sslutils.o ld: fatal: Symbol referencing errors. No output written to check_http collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `check_http' Current working directory /var/tmp/nagios/nagios-plugins-1.4.11/plugins *** Error code 1 The following command caused the error: failcom='exit 1'; \ for f in x $MAKEFLAGS; do \ case $f in \ *=* | --[!k]*);; \ *k*) failcom='fail=yes';; \ esac; \ done; \ dot_seen=no; \ target=`echo all-recursive | sed s/-recursive//`; \ list='gl lib plugins plugins-scripts plugins-root po'; for subdir in $list; do \ echo "Making $target in $subdir"; \ if test "$subdir" = "."; then \ dot_seen=yes; \ local_target="$target-am"; \ else \ local_target="$target"; \ fi; \ (cd $subdir && make $local_target) \ || eval $failcom; \ done; \ if test "$dot_seen" = "no"; then \ make "$target-am" || exit 1; \ fi; test -z "$fail" make: Fatal error: Command failed for target `all-recursive' Current working directory /var/tmp/nagios/nagios-plugins-1.4.11 *** Error code 1 make: Fatal error: Command failed for target `all' ============================================= Going to the plugins dir and running the command that has the problem: /bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -L. -L/usr/sfw/lib -o check_http check_http.o sslutils.o netutils.o utils.o ../lib/libnagiosplug.a ../gl/libgnu.a -lnsl -lsocket -lresolv -lssl -lcrypto -lnsl -lsocket gcc -g -O2 -o check_http check_http.o sslutils.o netutils.o utils.o -L/var/tmp/nagios/nagios-plugins-1.4.11/plugins -L/usr/sfw/lib ../lib/libnagiosplug.a ../gl/libgnu.a -lresolv -lssl -lcrypto -lnsl -lsocket Undefined first referenced symbol in file OpenSSL_add_all_algorithms sslutils.o ld: fatal: Symbol referencing errors. No output written to check_http collect2: ld returned 1 exit status From noreply at sourceforge.net Thu Jan 24 16:17:57 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Jan 2008 07:17:57 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1878144 ] check_mailq need root privileges Message-ID: Patches item #1878144, was opened at 2008-01-23 15:24 Message generated for change (Comment added) made by lausser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1878144&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_mailq need root privileges Initial Comment: Hi, i have several Linux servers, where you need special privileges to execute /usr/bin/mailq. On these servers i got: -bash-2.05b$ check_mailq -w 1 -c 5 Program mode requires special privileges, e.g., root or TrustedUser. CRITICAL: Error code 78 returned from /usr/bin/mailq Allowing the Nagios user to call check_mailq with sudo was not an option, because the plugins are owned and writable by this user himself. Yet it was possible to get sudo privileges for the /usr/bin/mailq command. I then patched check_mailq so that it first would ask "sudo -l" if $utils::PATH_TO_MAILQ is among the priviledged commands and if yes, call it with "sudo $utils::PATH_TO_MAILQ" instead. I appended the patch. Do you think this could be an option for plugins in general? I am sure, there are other installations which prefer sudo "/usr/bin/command inside the plugin" over sudo plugin Greetings from Munich, Gerhard ---------------------------------------------------------------------- >Comment By: gerhard lausser (lausser) Date: 2008-01-24 16:17 Message: Logged In: YES user_id=613416 Originator: YES Thanks for not trying to make my life harder! What i wanted to achieve is: - Compile the plugins once so that they can be used on every linux server without individual changes. (compile check_mailq on Suse where mailq can be executed by everyone and it will run unchanged on a RedHat where you need sudo rights to execute mailq) - If the plugin needs to call an external command, let the plugin decide wether to execute it with or without sudo. But your proposal Nr.2 would be an acceptable compromise. This way one can distribute individual utils.pm which ihmo is preferable to individual plugins. Gerhard ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-01-23 23:06 Message: Logged In: YES user_id=375623 Originator: NO Hmmmm.... I'm not trying to make you life harder but I still don't like your solution... So what comes to my mind is: 1. Use a different group for the Nagios team, and male the directories/plugins writable by that team 2. We could maybe do something like (not looking at the code, so it will likely need to be adapted): if ($PATH_TO_MAILQ =~ m/^(.*\/sudo)\s+(.*)$/) { if (-x $1 && -x $2) { ... } } elsif (-x $PATH_TO_MAILQ) { ... 3 (ideal but most complex to implement): Add a --with-sudo-command detection and option in configure, and a switch in mailq to use it. ---------------------------------------------------------------------- Comment By: gerhard lausser (lausser) Date: 2008-01-23 16:55 Message: Logged In: YES user_id=613416 Originator: YES Setting PATH_TO_MAILQ to "sudo mailq" doesn't work, because there are some if (-x $PATH_TO_MAILQ) { in the code. Removing write permissions for the plugins is not an option. There is an extra nagios team which owns the plugin directories and which has to be able to do updates for the nagios client software on all servers any time. Configuring the plugins so that mailq is called with sudo by default would require two versions of the plugin. One for the servers (SuSE) where everyone may execute mailq and one for the others where mailq is restricted to root. Gerhard ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-01-23 16:24 Message: Logged In: YES user_id=375623 Originator: NO Why don't you just remove any write permissions from Nagios for the plugin and plugin's folder? If you have dependencies you can also use a different path. Make it owned from root with read access for Nagios or everyone, for example. I don't believe adding sudo commands in plugin scripts is a viable solution, however an alternative would be to define the mailq path/command as "/usr/bin/sudo /usr/bin/mailq" or whichever path you need. ./configure --with-mailq-command="/usr/bin/sudo /usr/bin/mailq" I haven't tried but this may work already... If it don't and you have a fix for that, we'll merge it (and document this trick in the web site). Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1878144&group_id=29880 From noreply at sourceforge.net Thu Jan 24 16:44:44 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Jan 2008 07:44:44 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1878971 ] several typos Message-ID: Bugs item #1878971, was opened at 2008-01-24 16:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1878971&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: several typos Initial Comment: the attached patch fixes several typos and was commited to Debian Nagios Maintainer Group. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1878971&group_id=29880 From noreply at sourceforge.net Thu Jan 24 16:47:48 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Jan 2008 07:47:48 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1878972 ] fixes compilation of check_pgsql with postgresql 8.3 Message-ID: Bugs item #1878972, was opened at 2008-01-24 16:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1878972&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: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: fixes compilation of check_pgsql with postgresql 8.3 Initial Comment: the attached patch fixes compilation of check_psql with postgresql 8.3. Changelog of postgresql 8.3: - Move NAMEDATALEN definition from postgres_ext.h to pg_config_manual.h. It used to be part of libpq's exported interface many releases ago, but now it's no longer necessary to make it accessible to clients. The patch is against 1.4.11. With kind regards, Jan. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1878972&group_id=29880 From noreply at sourceforge.net Sat Jan 26 00:24:42 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 25 Jan 2008 15:24:42 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1880095 ] some fixes for option help of check_ntp* Message-ID: Bugs item #1880095, was opened at 2008-01-26 00:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1880095&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: CVS Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: some fixes for option help of check_ntp* Initial Comment: some fixes for option help of check_ntp_peer and check_ntp_time ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1880095&group_id=29880 From noreply at sourceforge.net Sat Jan 26 16:44:19 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 26 Jan 2008 07:44:19 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1880095 ] some fixes for option help of check_ntp* Message-ID: Bugs item #1880095, was opened at 2008-01-25 18:24 Message generated for change (Settings changed) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1880095&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: CVS >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) >Assigned to: Thomas Guyot (dermoth) Summary: some fixes for option help of check_ntp* Initial Comment: some fixes for option help of check_ntp_peer and check_ntp_time ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2008-01-26 10:44 Message: Logged In: YES user_id=375623 Originator: NO My bad, I forgot the most obvious! Thanks for the patch, will be in SVN shortly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1880095&group_id=29880 From mindmaster at gmail.com Fri Jan 25 19:59:48 2008 From: mindmaster at gmail.com (Lucas Liendo) Date: Fri, 25 Jan 2008 15:59:48 -0300 Subject: [Nagiosplug-devel] Strange behaviour in check_http Message-ID: Hi I'm writting this mail because I couldn't find any information about this issue on Google. I set on the KeepAlive option on my Apache webserver and I noticed that if I run a check_http against it returns a socket timeout. Here are the parameters I used : With KeepAlive OFF : ./check_http -I HOSTNAMEXX -u http://mywebsite.html -w 1.5 -c 2 and got : HTTP OK HTTP/1.1 200 OK - 2292 bytes in 0.045 seconds |time= 0.044638s;1.500000;2.000000;0.000000 size=2292B;;;0 With KeepAlive ON : ./check_http -I HOSTNAMEXX -u http://mywebsite.html -w 1.5 -c 2 and got : CRITICAL - Socket timeout after 10 seconds I'm running Apache 2.2 and Nagios 2.5. If you need any further information please let me now. Best regards, Lucas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at CIS.FU-Berlin.DE Mon Jan 28 10:40:49 2008 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Mon, 28 Jan 2008 10:40:49 +0100 Subject: [Nagiosplug-devel] Strange behaviour in check_http In-Reply-To: References: Message-ID: <20080128094049.GR28313306@CIS.FU-Berlin.DE> * Lucas Liendo [2008-01-25 15:59]: > Hi I'm writting this mail because I couldn't find any information about this > issue on Google. I set on the KeepAlive option on my Apache webserver and I > noticed that if I run a check_http against it returns a socket timeout. Here > are the parameters I used : > > With KeepAlive OFF : > > ./check_http -I HOSTNAMEXX -u http://mywebsite.html -w 1.5 -c 2 > > and got : HTTP OK HTTP/1.1 200 OK - 2292 bytes in 0.045 seconds |time= > 0.044638s;1.500000;2.000000;0.000000 size=2292B;;;0 > > With KeepAlive ON : > > ./check_http -I HOSTNAMEXX -u http://mywebsite.html -w 1.5 -c 2 > > and got : CRITICAL - Socket timeout after 10 seconds This should be fixed since the 1.4.10 release of the plugins. I guess you're using an older version? Holger From noreply at sourceforge.net Mon Jan 28 17:51:48 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Jan 2008 08:51:48 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1881254 ] Connection source address (for check_http) Message-ID: Patches item #1881254, was opened at 2008-01-28 16:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1881254&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Piotr Stolc (socrtp) Assigned to: Nobody/Anonymous (nobody) Summary: Connection source address (for check_http) Initial Comment: netutils.c, check_http - add option to specify local IP address of the connection. Patch against Plugin Version (-V output): check_http v1892 (nagios-plugins 1.4.11) $Id: netutils.c 1893 2008-01-07 02:04:17Z hweiss $ $Id: netutils.h 1580 2007-01-24 22:47:25Z tonvoon $ Plugin Name: check_http, netutils.c Example Plugin Commandline: check_http www.example.com -B one.of.our.ip-address Tested on operating system: Gentoo Linux Tested on architecture: x86 Tested with compiler: gcc version 4.1.2 (Gentoo 4.1.2 p1.0.2) This patch adds the functionality of binding the socket to chosen local IP address. It modifies the behavior of nb_net_connect() function but it doesn't break compatibility with older versions. It is easy to add this option to other plugins which use nb_net_connect(). Greetz, Piotr Stolc ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1881254&group_id=29880 From dermoth at aei.ca Tue Jan 29 10:49:46 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 29 Jan 2008 04:49:46 -0500 Subject: [Nagiosplug-devel] Multiple fixes to check_ntp_time (and check_ntp) best offset server selection Message-ID: <479EF6BA.1090600@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just a note about the fixes for check_ntp_time (and check_ntp) I just committed. While trying to check something about the alarm flag in check_ntp_time I accidentally came across a bug: any server that didn't respond was taken as the best offset server. After adding a bunch of debugging to that function (and also reading some NTP documentation) a few other bugs became evident: 1. As stated above, non-responding peers were always selected (making the final offset unknown). 2. The break statement in the LI_NOWARNING check was breaking the main for loop, preventing all remaining peers to be checked. 3. As soon as the first loop started discarding peers the 2md level loop wasn't functioning properly and was ignoring the last peers of the array. 4. The candidate array was shifting the wrong way, overwriting all elements with the last one before setting the first element with the current best offset server! 5. Only the first element of the candidate array was used anyways so all this was useless. 6. Discarding peers with LI_NOWARNING would also discard peers that have the leap indicator set. NTP servers start advertising leap bits one month before leap seconds needs to be inserted, so this means on those months any good NTP server would fail! With the exception of #6, all these bugs were only an issue if you checked a pool of servers (multiple A returned for a single hostname) and one of them was not responding or had the LI_ALARM flag set, or if there was more than 6 server to be checked. I rewritten parts of the best_offset_server function to address these issues. All this is old stuff (always worked this way) except for the LI_NOWARNING break statement bug which appeared in 1.4.10. A possible segfault in 1.4.11 and earlier releases was also fixed a few seeks ago. Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHnva56dZ+Kt5BchYRAloxAJ9KKdtS7Uqy0wJSMuXD4g0AHn69xACgqqcM TWgVtvttG4vh9XW/PqJldXQ= =zPWt -----END PGP SIGNATURE----- From noreply at sourceforge.net Tue Jan 29 11:28:15 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Jan 2008 02:28:15 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1878539 ] check_ntp_peer doesn't honor ntp flags Message-ID: Bugs item #1878539, was opened at 2008-01-23 17:34 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1878539&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: 6 Private: No Submitted By: Thomas Guyot (dermoth) Assigned to: Thomas Guyot (dermoth) Summary: check_ntp_peer doesn't honor ntp flags Initial Comment: Just as for check_ntp patch #1798774, check_ntp_time should honor the ntp flags. I've been fooled into thinking that there were no such flags in ntp control packets but I was wrong. ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-01-29 05:28 Message: Logged In: YES user_id=375623 Originator: YES 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=1878539&group_id=29880 From noreply at sourceforge.net Tue Jan 29 17:14:59 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Jan 2008 08:14:59 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1881898 ] Fix 'Host:' heqder to include port Message-ID: Patches item #1881898, was opened at 2008-01-29 11:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1881898&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: Christophe Dupre (duprec) Assigned to: Nobody/Anonymous (nobody) Summary: Fix 'Host:' heqder to include port Initial Comment: RFC-2616 (HTTP/1.1 protocol) states that the lack of the port information in the "Host: " header supplied by the client implies the default value (80 for http, 443 for https). This means that if we override the port with the '-p' option, the plugin must provide that information in the "Host: " header. This patch fixes that oversight by always supplying the port, which is accepted practice and makes it a one-liner. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1881898&group_id=29880 From noreply at sourceforge.net Tue Jan 29 17:15:25 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Jan 2008 08:15:25 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1881898 ] Fix 'Host:' header to include port Message-ID: Patches item #1881898, was opened at 2008-01-29 11:14 Message generated for change (Settings changed) made by duprec You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1881898&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: Christophe Dupre (duprec) Assigned to: Nobody/Anonymous (nobody) >Summary: Fix 'Host:' header to include port Initial Comment: RFC-2616 (HTTP/1.1 protocol) states that the lack of the port information in the "Host: " header supplied by the client implies the default value (80 for http, 443 for https). This means that if we override the port with the '-p' option, the plugin must provide that information in the "Host: " header. This patch fixes that oversight by always supplying the port, which is accepted practice and makes it a one-liner. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1881898&group_id=29880 From noreply at sourceforge.net Tue Jan 29 17:34:09 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Jan 2008 08:34:09 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1881916 ] Ability to read POST data from a file Message-ID: Patches item #1881916, was opened at 2008-01-29 11:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1881916&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christophe Dupre (duprec) Assigned to: Nobody/Anonymous (nobody) Summary: Ability to read POST data from a file Initial Comment: This patch adds a '-F' command line option as an alternative to the '-P' option. Both will result in a POST request to the server, but while '-P' gets its data from the command line, -F gets its data from a file. This is useful for testing web services where a lengthy XML post is required. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1881916&group_id=29880