From notifications at github.com Mon Oct 6 10:36:42 2014 From: notifications at github.com (waja) Date: Mon, 06 Oct 2014 01:36:42 -0700 Subject: check_oracle --tns bad string matching [sf#3389177] (#1015) In-Reply-To: References: Message-ID: Closed #1015 via d8b81e9ef3947a36e2647f4e54a63e3b259b103b. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1015#event-174406605 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Oct 6 10:36:42 2014 From: notifications at github.com (waja) Date: Mon, 06 Oct 2014 01:36:42 -0700 Subject: check_mailq: fixed mailer names (#1289) In-Reply-To: References: Message-ID: Closed #1289 via 37b8081504baca0df9e19818f686f25011835d1b. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1289#event-174406606 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Oct 6 10:39:02 2014 From: notifications at github.com (waja) Date: Mon, 06 Oct 2014 01:39:02 -0700 Subject: check_oracle: --tns bad string matching (#1191) In-Reply-To: References: Message-ID: Closed #1191. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1191#event-174407527 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Oct 6 12:52:39 2014 From: notifications at github.com (Jonas Genannt) Date: Mon, 06 Oct 2014 03:52:39 -0700 Subject: check_file_age: add option to provide perf data (#1292) In-Reply-To: References: Message-ID: hello @weiss, thanks for your comments. I have fixed the output of the perf data, and added the win/max values. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1292#issuecomment-58001326 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Oct 6 20:18:45 2014 From: notifications at github.com (=?UTF-8?B?SG9sZ2VyIFdlacOf?=) Date: Mon, 06 Oct 2014 11:18:45 -0700 Subject: check_file_age: add option to provide perf data (#1292) In-Reply-To: References: Message-ID: > I have fixed the output of the perf data, and added the win/max values. Thank you! I've squashed your changes into a single commit, added a line to the `NEWS` file, and pushed the result. Thanks again. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1292#issuecomment-58064996 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Oct 6 20:18:45 2014 From: notifications at github.com (=?UTF-8?B?SG9sZ2VyIFdlacOf?=) Date: Mon, 06 Oct 2014 11:18:45 -0700 Subject: check_file_age: add option to provide perf data (#1292) In-Reply-To: References: Message-ID: Closed #1292. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1292#event-174697717 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Oct 6 20:22:24 2014 From: notifications at github.com (Jonas Genannt) Date: Mon, 06 Oct 2014 11:22:24 -0700 Subject: check_file_age: add option to provide perf data (#1292) In-Reply-To: References: Message-ID: :+1: -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1292#issuecomment-58065764 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Oct 7 16:25:50 2014 From: notifications at github.com (Sam Kottler) Date: Tue, 07 Oct 2014 07:25:50 -0700 Subject: monitoring-plugins.spec.in: Needs some love (#1273) In-Reply-To: References: Message-ID: @waja sorry for not responding sooner. I think the PR looks pretty good and am gonna work on getting it into a state where it can be merged over the next day or so. We'll need to rebuild and make sure the upgrade path works properly, though. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1273#issuecomment-58192377 -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at zedat.fu-berlin.de Thu Oct 9 11:39:38 2014 From: holger at zedat.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Thu, 9 Oct 2014 11:39:38 +0200 Subject: New release coming soon Message-ID: <20141009093938.GA44237@zedat.fu-berlin.de> We'd like to cut a new Monitoring Plugins release within the next few days. If you could spare a little time to test the current snapshot? and report any regressions from the 2.0 release, that would be great! Jan also created Debian packages for his "wheezy-backports" and "unstable" repositories for you to test, see: http://ftp.cyconet.org/instructions/ Thanks! Holger ? https://www.monitoring-plugins.org/download/snapshot/monitoring-plugins-master.tar.gz From kuhlmeier at riege.com Thu Oct 9 13:10:50 2014 From: kuhlmeier at riege.com (Dennis Kuhlmeier) Date: Thu, 09 Oct 2014 13:10:50 +0200 Subject: New release coming soon In-Reply-To: <20141009093938.GA44237@zedat.fu-berlin.de> References: <20141009093938.GA44237@zedat.fu-berlin.de> Message-ID: <54366D3A.7090908@riege.com> Hi there, On 09.10.2014 11:39, Holger Wei? wrote: > We'd like to cut a new Monitoring Plugins release within the next few > days. If you could spare a little time to test the current snapshot? > and report any regressions from the 2.0 release, that would be great! > I had hoped you would be updating the .spec file for those who build that themselves, but the build aborts early. $ rpmbuild -tb monitoring-plugins-2.0.tar.gz Executing(%prep): /bin/sh -e /home/admin/rpmbuild/TMP/rpm-tmp.nqzXle + umask 022 + cd /home/admin/rpmbuild/BUILD + LANG=C + export LANG + unset DISPLAY + cd /home/admin/rpmbuild/BUILD + rm -rf monitoring-plugins-2.0 + /usr/bin/gzip -dc /home/admin/rpmbuild/SOURCES/monitoring-plugins-2.0.tar.gz + /bin/tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd monitoring-plugins-2.0 /home/admin/rpmbuild/TMP/rpm-tmp.nqzXle: line 38: cd: monitoring-plugins-2.0: No such file or directory error: Bad exit status from /home/admin/rpmbuild/TMP/rpm-tmp.nqzXle (%prep) RPM build errors: Bad exit status from /home/admin/rpmbuild/TMP/rpm-tmp.nqzXle (%prep) That's on RHEL5 and RHEL6 > Jan also created Debian packages for his "wheezy-backports" and > "unstable" repositories for you to test, see: > > http://ftp.cyconet.org/instructions/ > > Thanks! > > Holger > > ? https://www.monitoring-plugins.org/download/snapshot/monitoring-plugins-master.tar.gz > > Would be great if you'd look into that as well! In the past most of the problems I had were plugins not being built without an easy way to notice. Thanks, Dennis -- .............................................................. Riege Software International GmbH Phone: +49 2159 91480 Mollsfeld 10 Fax: +49 2159 914811 40670 Meerbusch Web: www.riege.com Germany E-Mail: kuhlmeier at riege.com -- -- Commercial Register: Managing Directors: Amtsgericht Neuss HRB-NR 4207 Christian Riege VAT Reg No.: DE120585842 Gabriele Riege Johannes Riege Tobias Riege .............................................................. YOU CARE FOR FREIGHT, WE CARE FOR YOU From waja at cyconet.org Thu Oct 9 14:43:34 2014 From: waja at cyconet.org (Jan Wagner) Date: Thu, 09 Oct 2014 14:43:34 +0200 Subject: New release coming soon In-Reply-To: <54366D3A.7090908@riege.com> References: <20141009093938.GA44237@zedat.fu-berlin.de> <54366D3A.7090908@riege.com> Message-ID: <543682F6.3010507@cyconet.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Denis, Am 09.10.14 13:10, schrieb Dennis Kuhlmeier: > On 09.10.2014 11:39, Holger Wei? wrote: >> We'd like to cut a new Monitoring Plugins release within the next >> few days. If you could spare a little time to test the current >> snapshot? and report any regressions from the 2.0 release, that >> would be great! >> > > I had hoped you would be updating the .spec file for those who > build that themselves, but the build aborts early. sorry for this. This is the last remaining issue open for the next release: https://github.com/monitoring-plugins/monitoring-plugins/milestones/2.0.1 We even have open a Pull Request open for this: https://github.com/monitoring-plugins/monitoring-plugins/pull/1283 Maybe you could give it a try? Feedback is very welcome. Cheers, Jan. - -- Never write mail to , you have been warned! - -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT d-- s+: a C+++ UL++++ P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h---- r+++ y++++ - ------END GEEK CODE BLOCK------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJUNoL2AAoJEAxwVXtaBlE+o9IP/jdYSFc2U+CggbwdYb+0Q6qn 4J4eiWskjUv8wnpHcgui3vC398cnKH2/LlfpA32EsEdfj5bwLLUhLHB41an0JAzd 2pIOYJSxy41DVl9BRjPZG3inSetNfkD5qwJtmGPHDlxc4G2VWU7TQsa4D353W8SM Av7Fa5w0oIi3qnsSl8E4adsTfQU5RKF2xhyTmrD2hQfq/A49xL13XkiOwfdCqBqY /apRfXnr88zTW6BeT7V6FE0xXKnpIrd2DpDLPxTroir2NHvIfeqYp5NjbZjc1vCM irv9C8zy3A93eeR+FuYPQbBf86PVIFQUM2hnTzHYsskW2zRJCsvUS4NXEnRsUxto as4IWS+L4qiwvjpov1RFcipvLk+XBVc5UINF6jcD07e/2fwI2tS59F6eA68a/ivI OVeNRgL9TbucCscwk0tYUJmsFHTQoZPutP5r+kiwa8/lSjq/+fDzFz5BCqzSsyDT gzMSLMa4wE1cXe2T0BadvTDqfPB05sZdAky28W6k/++mL0DfWVqmHMyfNrqLkzzd byySsd/4MxV1rqPru1qX8sCJ0ayPTmJaGUpckHpDp0rPz1wC51y6U7UA1cNYDmw8 cjD9CEIKRgZYV57JpF3GAk4WvmArQYBtqznjX87OUsispZeEThxXTgst+X8/X0cM SftKyx76mW4fiLZ/mA8S =Tc8K -----END PGP SIGNATURE----- From notifications at github.com Sun Oct 12 16:56:36 2014 From: notifications at github.com (waja) Date: Sun, 12 Oct 2014 07:56:36 -0700 Subject: monitoring-plugins.spec.in: Needs some love (#1273) In-Reply-To: References: Message-ID: Okay ... are we droping the spec file or do we pull the PR? As we don't have any feedback for the PR yet, I'm in favour droping it. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1273#issuecomment-58803155 -------------- next part -------------- An HTML attachment was scrubbed... URL: From f at zz.de Thu Oct 23 09:06:20 2014 From: f at zz.de (Florian Lohoff) Date: Thu, 23 Oct 2014 09:06:20 +0200 Subject: uptime monitoring via check_snmp / counter wrap Message-ID: <20141023070620.GA24232@pax.zz.de> Hi, i am currently monitoring sysuptime via check-snmp command_line $USER1$/check_snmp -H $HOSTADDRESS$ -C $_HOSTCOMMUNITY$ -P 2c -o .1.3.6.1.2.1.1.3.0 -c 90000: The 90000 is basically that i want the first 15 Minutes after boot the alarm to be critical. Now obviously with a 32 bit counter this counter wraps at least every 497 days. flo at p2:~$ echo $[ 2**32 / 100 / 86400 ] 497 This causes the above statement to actually show a reboot/sysuptime ALARM. I dont see any way around this as the wrap depends on the last value found via check_snmp so it would need some kind of persistence of data. Is there a better sysuptime check? Flo -- Florian Lohoff f at zz.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 828 bytes Desc: Digital signature URL: From notifications at github.com Thu Oct 23 19:40:12 2014 From: notifications at github.com (=?UTF-8?B?VG9tw6HFoSBQb3Nww63FoWVr?=) Date: Thu, 23 Oct 2014 10:40:12 -0700 Subject: check_apt reports wrong/different stuff if run as the nagios user (#1294) Message-ID: This is under Debian wheezy with the Debmon packages. # /usr/lib/nagios/plugins/check_apt APT OK: 0 packages available for upgrade (0 critical updates). |available_upgrades=0;;;0 critical_updates=0;;;0 # su -c /usr/lib/nagios/plugins/check_apt -s /bin/sh - nagios APT WARNING: 6 packages available for upgrade (0 critical updates). |available_upgrades=6;;;0 critical_updates=0;;;0 Related to the problem seems to be this: # # apt-cache policy icinga2-bin icinga2-bin: Installed: 2.1.1-1~debmon70+1 Candidate: 2.1.1-1~debmon70+1 Version table: *** 2.1.1-1~debmon70+1 0 400 http://debmon.org/debmon/ debmon-wheezy/main amd64 Packages 100 /var/lib/dpkg/status 2.1.1-1~bpo70+1 0 100 http://ftp.de.debian.org/debian/ wheezy-backports/main amd64 Packages N: Ignoring file '20auto-upgrades.ucf-dist' in directory '/etc/apt/apt.conf.d/' as it has an invalid filename extension Where: # cat /etc/apt/preferences.d/debmon-pin-400 # prefer Debian Packages over Debmon packages # do not automatically update Package: * Pin: release o=debmon.org Pin-Priority: 400 I'm thinking that it's related to this, because there are 6 packages coming from the debmon Repository that have really similar versions in the backports repository. However neither "apt-cache policy", nor "dpkg --compare-versions" seem to behave differently when run as the nagios user or root. So at this point I have no idea why check_apt behaves differently under the nagios user. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1294 -------------- next part -------------- An HTML attachment was scrubbed... URL: From frnkblk at iname.com Fri Oct 24 02:10:23 2014 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 23 Oct 2014 19:10:23 -0500 Subject: uptime monitoring via check_snmp / counter wrap In-Reply-To: <20141023070620.GA24232@pax.zz.de> References: <20141023070620.GA24232@pax.zz.de> Message-ID: <004001cfef1e$e8215670$b8640350$@iname.com> There are scripts for some network hardware that check environmentals and they deal with that by tracking the last value, and if the last value was near wrap over, it doesn't treat it as a reload. -----Original Message----- From: Devel [mailto:devel-bounces+frnkblk=iname.com at monitoring-plugins.org] On Behalf Of Florian Lohoff Sent: Thursday, October 23, 2014 2:06 AM To: devel at monitoring-plugins.org Subject: uptime monitoring via check_snmp / counter wrap Hi, i am currently monitoring sysuptime via check-snmp command_line $USER1$/check_snmp -H $HOSTADDRESS$ -C $_HOSTCOMMUNITY$ -P 2c -o .1.3.6.1.2.1.1.3.0 -c 90000: The 90000 is basically that i want the first 15 Minutes after boot the alarm to be critical. Now obviously with a 32 bit counter this counter wraps at least every 497 days. flo at p2:~$ echo $[ 2**32 / 100 / 86400 ] 497 This causes the above statement to actually show a reboot/sysuptime ALARM. I dont see any way around this as the wrap depends on the last value found via check_snmp so it would need some kind of persistence of data. Is there a better sysuptime check? Flo -- Florian Lohoff f at zz.de From william at leibzon.org Fri Oct 24 02:37:10 2014 From: william at leibzon.org (William Leibzon) Date: Thu, 23 Oct 2014 17:37:10 -0700 Subject: uptime monitoring via check_snmp / counter wrap In-Reply-To: <20141023070620.GA24232@pax.zz.de> References: <20141023070620.GA24232@pax.zz.de> Message-ID: You need 64-bit counter and there is none for uptime. Since once every 500 days is rare people just deal with such extra alert. Most people for one reason or another reboot their servers more often though. If you want to write a work-around it would be one that uses previous run uptime data and if its near wrap time ignores the situation. On Thu, Oct 23, 2014 at 12:06 AM, Florian Lohoff wrote: > > Hi, > i am currently monitoring sysuptime via check-snmp > > command_line $USER1$/check_snmp -H $HOSTADDRESS$ -C > $_HOSTCOMMUNITY$ -P 2c -o .1.3.6.1.2.1.1.3.0 -c 90000: > > The 90000 is basically that i want the first 15 Minutes after boot the > alarm > to be critical. > > Now obviously with a 32 bit counter this counter wraps at least every 497 > days. > > flo at p2:~$ echo $[ 2**32 / 100 / 86400 ] > 497 > > This causes the above statement to actually show a reboot/sysuptime ALARM. > > I dont see any way around this as the wrap depends on the last value found > via check_snmp so it would need some kind of persistence of data. > > Is there a better sysuptime check? > > Flo > -- > Florian Lohoff f at zz.de > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQIVAwUBVEio7JDdQSDLCfIvAQpycQ//ayLcurUViD5vBKpZ/6zVebm7y7pxtXL/ > SNW6pac9ls0y8gsJjSolHrVobHR+Xtdz/gl2pA86wI4+l1txJlAirpocuw8QHtam > Hg39ndTbryvDkxekUdxJi0Alue21kKqMHGnRj8B5Utpd8YLqQ6WhGQVHZR4Qpsiq > m49BEmCJyvQsQZPfOm4wgeAL1uqzXKIbxT1fiL4lghybFyKd8DE5QdzBGnEjJUSM > CEKMC/10ItSUd7CLaV6lfXBG+I1RbWJuyHPhpm8tbzvQtftnrk2PDG9cdjaMtSu1 > MVnnh46gMuiDzWK6CQPJiQEAeIdHGb1r2roPnUEjJT3vQvZLA9yIEFuwyVzAIA6V > aX5QZLhMoB0JVmU2sUMWqrZXBnrI7tLuHThdEQkOIvSfTbwNIAQsTwKSAwiLjjPC > BvnBrNNHu17S3n3KCMEzB1JZRT769ZpCkrheSGVjCj5eDcVf/dD0ENJndUWyZFOp > tXnB/7LkNlO4tO8ZrCStWSOBbXkohdUEVLNkvMRDniNWHsOgr36EdKLifMml11Mj > C7e8KsKUOPU9clydynbSosVRu62NR4ythwV1l2Tzgkq/SFI1QB704iA/Wc2rKzAz > ifwfi4NFH5RanWHWzgQSkWruEMs8U1dRbUmqPV5hiW/M4nHNt+4yLBlLHqtiJ9UQ > 0fhGGhnz9EQ= > =9UBV > -----END PGP SIGNATURE----- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Oct 29 07:03:15 2014 From: notifications at github.com (ringep) Date: Tue, 28 Oct 2014 23:03:15 -0700 Subject: check_ntp has to respect ntpd-parameters like average and minimum (#1295) Message-ID: actually check_ntp/check_tnp_time submits udp packest to the ntp-server with an interval of about one second. In the documentation of ntpd servers it menttioned, that ntp-requests are/can be discarded when appearing with this high frequency: >From ?http://www.eecis.udel.edu/~mills/ntp/html/accopt.html#discard: discard [ average avg ][ minimum min ] [ monitor prob ] Set the parameters of the rate control facility which protects the server from client abuse. If the limited flag is present in the ACL, packets that violate these limits are discarded. If, in addition, the kod flag is present, a kiss-o'-death packet is returned. See the Rate Management page for further information. The options are: average avg Specify the minimum average interpacket spacing (minimum average headway time) in log2 s with default 3. minimum min Specify the minimum interpacket spacing (guard time) in seconds with default 2. monitor Specify the probability of being recorded for packets that overflow the MRU list size limit set by mru maxmem or mru maxdepth. This is a performance optimization for servers with aggregate arrivals of 1000 packets per second or more. For this, check_ntp will have to adopt its own request frequency or there have to command line parameters to adjust average and minimum. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1295 -------------- next part -------------- An HTML attachment was scrubbed... URL: