From kuhlmeier at riege.com Thu Apr 9 15:40:27 2015 From: kuhlmeier at riege.com (Dennis Kuhlmeier) Date: Thu, 09 Apr 2015 15:40:27 +0200 Subject: check_disk percentage calculation Message-ID: <5526814B.5060300@riege.com> Hi there, with check_disk (monitoring-plugins 2.0 and older) I have noticed a little discrepancy in status evaluation and performance data calculation, or maybe I am just mistaken. $ /opt/omd/versions/1.21.20140912/lib/nagios/plugins/check_disk -w 40% -c 10% -p /opt/ DISK OK - free space: / 1420 MB (42% inode=71%);| /=1927MB;2116;3174;0;3527 $ /opt/omd/versions/1.21.20140912/lib/nagios/plugins/check_disk -w 45% -c 10% -p /opt/ DISK WARNING - free space: / 1420 MB (42% inode=71%);| /=1927MB;1939;3174;0;3527 As you can see the free space is 42% which is lower than 45% and triggers a warning. But the absolute values in PF data are 1927 and 1939, 1927 being smaller than 1939 so it should be an OK state in my opinion. At least it is somewhat inconsistent. With larger filesystems this gap grows, "/opt/=75490MB;78330;88121;0;97913" resulting in a warning as well although there seem to be roughly 3 gigabytes of space left to the warning threshold. Can this be improved in either direction or am I not seeing the bigger picture? Thanks and regards 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 notifications at github.com Sun Apr 12 10:35:57 2015 From: notifications at github.com (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Sun, 12 Apr 2015 01:35:57 -0700 Subject: Add tools/update-thanks script (0a236c7) In-Reply-To: References: Message-ID: looks like `THANKS` is not produced when using git checkout to build from source. `make dist-hook` fixes this, but can it be added automatically to be ran for just `make` ? -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/commit/0a236c7c70a5d3b9f921338fca8ea67196a05c12#commitcomment-10681287 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Apr 13 02:17:58 2015 From: notifications at github.com (Andrew Widdersheim) Date: Sun, 12 Apr 2015 17:17:58 -0700 Subject: monitoring-plugins-2.1.1 - check_disk.c format warning (#1331) In-Reply-To: References: Message-ID: I think #1326 addresses this issue. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1331#issuecomment-92156224 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Apr 13 09:41:35 2015 From: notifications at github.com (=?UTF-8?B?SG9sZ2VyIFdlacOf?=) Date: Mon, 13 Apr 2015 00:41:35 -0700 Subject: Update RELEASING (#1332) In-Reply-To: References: Message-ID: Applied, thanks. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1332#issuecomment-92253857 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Apr 13 12:44:55 2015 From: notifications at github.com (nuts424) Date: Mon, 13 Apr 2015 03:44:55 -0700 Subject: monitoring-plugins-2.1.1 check_tcp -D didn't work as expected (#1333) In-Reply-To: References: Message-ID: server # /usr/lib/nagios/plugins/check_tcp -V check_tcp v2.1.1 (monitoring-plugins 2.1.1) crazy... It is a gentoo. My profile is default/linux/amd64/13.0 -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1333#issuecomment-92304899 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Apr 13 14:07:20 2015 From: notifications at github.com (Andrew Widdersheim) Date: Mon, 13 Apr 2015 05:07:20 -0700 Subject: Readability fix (#1334) Message-ID: You can view, comment on, or merge this pull request online at: https://github.com/monitoring-plugins/monitoring-plugins/pull/1334 -- Commit Summary -- * Readability fix -- File Changes -- M plugins/check_tcp.c (3) -- Patch Links -- https://github.com/monitoring-plugins/monitoring-plugins/pull/1334.patch https://github.com/monitoring-plugins/monitoring-plugins/pull/1334.diff -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1334 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Apr 13 14:12:34 2015 From: notifications at github.com (waja) Date: Mon, 13 Apr 2015 05:12:34 -0700 Subject: monitoring-plugins-2.1.1 check_tcp -D didn't work as expected (#1333) In-Reply-To: References: Message-ID: And you did install it via emerge? -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1333#issuecomment-92330958 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Apr 13 14:17:47 2015 From: notifications at github.com (=?UTF-8?B?SG9sZ2VyIFdlacOf?=) Date: Mon, 13 Apr 2015 05:17:47 -0700 Subject: Readability fix (#1334) In-Reply-To: References: Message-ID: Applied, thanks. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1334#issuecomment-92332189 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Apr 13 14:17:47 2015 From: notifications at github.com (=?UTF-8?B?SG9sZ2VyIFdlacOf?=) Date: Mon, 13 Apr 2015 05:17:47 -0700 Subject: Readability fix (#1334) In-Reply-To: References: Message-ID: Closed #1334. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1334#event-279696717 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Apr 14 01:03:03 2015 From: notifications at github.com (nuts424) Date: Mon, 13 Apr 2015 16:03:03 -0700 Subject: monitoring-plugins-2.1.1 check_tcp -D didn't work as expected (#1333) In-Reply-To: References: Message-ID: Ah, there is the failure. my useflags were: net-analyzer/monitoring-plugins sudo snmp gnutls with gnutls check_tcp -D doesn't work. Thanks! A "its working for me" is in some cases a good constructive answer. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1333#issuecomment-92527956 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Apr 14 01:03:02 2015 From: notifications at github.com (nuts424) Date: Mon, 13 Apr 2015 16:03:02 -0700 Subject: monitoring-plugins-2.1.1 check_tcp -D didn't work as expected (#1333) In-Reply-To: References: Message-ID: Closed #1333. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1333#event-280277868 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sun Apr 19 01:17:25 2015 From: notifications at github.com (Gerhard Lausser) Date: Sat, 18 Apr 2015 16:17:25 -0700 Subject: check ldap count entries (#1335) Message-ID: Hi, this patch adds --warn-entries and --crit-entries. As soon as you use one of them, not only the runtime of the ldap query will be checked but also the number of returned entries. The parameters accept threshold ranges as arguments, e.g.: --warn-entries 10: --crit-entries 1: This will result in CRITICAL if the ldap-query was correct, but returned no entry records. You can view, comment on, or merge this pull request online at: https://github.com/monitoring-plugins/monitoring-plugins/pull/1335 -- Commit Summary -- * add sperfdata function which can handle threshold ranges * add counting of entries to check_ldap -- File Changes -- M plugins/check_ldap.c (69) M plugins/utils.c (40) -- Patch Links -- https://github.com/monitoring-plugins/monitoring-plugins/pull/1335.patch https://github.com/monitoring-plugins/monitoring-plugins/pull/1335.diff -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1335 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Apr 20 09:27:11 2015 From: notifications at github.com (=?UTF-8?B?TWF0dGhpYXMgSMOkaG5lbA==?=) Date: Mon, 20 Apr 2015 00:27:11 -0700 Subject: Update sslutils.c (#1336) Message-ID: optimize output if certificate expires in less then 24h thx to axel.schmalowsky at sixt.com for this patch You can view, comment on, or merge this pull request online at: https://github.com/monitoring-plugins/monitoring-plugins/pull/1336 -- Commit Summary -- * Update sslutils.c -- File Changes -- M plugins/sslutils.c (7) -- Patch Links -- https://github.com/monitoring-plugins/monitoring-plugins/pull/1336.patch https://github.com/monitoring-plugins/monitoring-plugins/pull/1336.diff -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1336 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Apr 22 13:28:10 2015 From: notifications at github.com (Sven Nierlein) Date: Wed, 22 Apr 2015 04:28:10 -0700 Subject: Update sslutils.c (#1336) In-Reply-To: References: Message-ID: I like the idea. After a quick look, i think the code will print wrong information if the time till expire is below one hour. It would then print "minutes" as unit but stil print the hours_left. Also i am not a fan of cascaded if statements. I would at least break it on several lines. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1336#issuecomment-95144537 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Apr 22 15:57:55 2015 From: notifications at github.com (ylfingr) Date: Wed, 22 Apr 2015 06:57:55 -0700 Subject: make time calculations timezone independent (and thus more portable) (#1337) Message-ID: Time calculations have been done locale-dependent which lead to different expiration dates. You can view, comment on, or merge this pull request online at: https://github.com/monitoring-plugins/monitoring-plugins/pull/1337 -- Commit Summary -- * make time calculations timezone independent (and thus more portable) -- File Changes -- M plugins/sslutils.c (20) -- Patch Links -- https://github.com/monitoring-plugins/monitoring-plugins/pull/1337.patch https://github.com/monitoring-plugins/monitoring-plugins/pull/1337.diff -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1337 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Apr 22 16:33:54 2015 From: notifications at github.com (Sven Nierlein) Date: Wed, 22 Apr 2015 07:33:54 -0700 Subject: make time calculations timezone independent (and thus more portable) (#1337) In-Reply-To: References: Message-ID: How does this make the code more portable? I mean, thats what timezones are for, if you want UTC, just use UTC either by changing your system to UTC or by running the plugin with TZ="UTC" ..../check_http -C .. Or just set TZ for your monitoring user, i'd say there are way better solutions than hardcoding UTC in some of the plugins. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1337#issuecomment-95208644 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Apr 23 10:25:19 2015 From: notifications at github.com (Sven Nierlein) Date: Thu, 23 Apr 2015 01:25:19 -0700 Subject: make time calculations timezone independent (and thus more portable) (#1337) In-Reply-To: References: Message-ID: I am trying to reproduce that here: %> TZ=UTC ./check_http -v -p443 -H github.com -C 7,3 --sni OK - Certificate 'github.com' will expire on Tue 12 Apr 2016 12:00:00 PM UTC. %> ./check_http -v -p443 -H github.com -C 7,3 --sni OK - Certificate 'github.com' will expire on Tue 12 Apr 2016 01:00:00 PM CEST. %> TZ=Europe/Berlin ./check_http -v -p443 -H github.com -C 7,3 --sni OK - Certificate 'github.com' will expire on Tue 12 Apr 2016 01:00:00 PM CEST. %> ./check_http -V check_http v2.1.1.51.g08fc (monitoring-plugins 2.1.1) I'd say, the real question is, why is there no timezone mentioned in your output. The check uses strftime with "%c" fomat. This is "The preferred date and time representation for the current locale.". So, if i set LANG as well, i get close to your results: LANG=C TZ=Europe/Berlin ./check_http -v -p443 -H github.com -C 7,3 --sni OK - Certificate 'github.com' will expire on Tue Apr 12 13:00:00 2016. Which is not wrong, but you have to know the timezone :-) In the end, i would leave it like it is. With every ENV variable we set to a fixed value, we just trade reduced flexibility for a specific use case. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1337#issuecomment-95487885 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Apr 23 11:01:10 2015 From: notifications at github.com (ylfingr) Date: Thu, 23 Apr 2015 02:01:10 -0700 Subject: make time calculations timezone independent (and thus more portable) (#1337) In-Reply-To: References: Message-ID: I'm not quite sure why there's no timezone mentioned in my outputs. I've tried various settings (e.g. LANG=de_DE vs LANG=C), but there's never any timezone indicator in the outputs. But this seems to be an issue on my system. Nevertheless, for the sake of argument, let's assume there's a timezone indicator in the output. As you can see from your outputs, you'll never get the expiration time of **02:00:00 PM CEST** / **14:00:00**, which would be the correct time representation in the case of TZ=Europe/Berlin. And as you can see in my last patch, the variable TZ is being cleared / unset. Since the check uses "%c" in strftime, the user can still choose his preferred TZ-settings. At last, I have found a more verbose example: ## current behavior ```shell TZ=UTC ./check_http -v -p443 -H github.com -C 7,3 --sni OK - Certificate 'github.com' will expire on Tue Apr 12 12:00:00 2016. ``` ```shell TZ=PST8PDT ./check_http -v -p443 -H github.com -C 7,3 --sni OK - Certificate 'github.com' will expire on Tue Apr 12 13:00:00 2016. ``` ## new behavior ```shell TZ=PST8PDT ./check_http -v -p443 -H github.com -C 7,3 --sni OK - Certificate 'github.com' will expire on Tue Apr 12 05:00:00 2016. ``` Since PST8PDT is UTC-8, the second output would be correct. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1337#issuecomment-95497698 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Apr 23 14:58:23 2015 From: notifications at github.com (=?UTF-8?B?TWF0dGhpYXMgSMOkaG5lbA==?=) Date: Thu, 23 Apr 2015 05:58:23 -0700 Subject: Update sslutils.c (#1336) In-Reply-To: References: Message-ID: this looks like a temporary failure with travis or the mozilla test url can you restart the build? -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1336#issuecomment-95576626 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Apr 23 17:22:24 2015 From: notifications at github.com (=?UTF-8?B?SG9sZ2VyIFdlacOf?=) Date: Thu, 23 Apr 2015 08:22:24 -0700 Subject: Update sslutils.c (#1336) In-Reply-To: References: Message-ID: Done (and it helped). -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1336#issuecomment-95623324 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eponymousalias at yahoo.com Thu Apr 23 20:34:33 2015 From: eponymousalias at yahoo.com (eponymous alias) Date: Thu, 23 Apr 2015 11:34:33 -0700 Subject: check_disk command In-Reply-To: <5cf930f880a049d9868b7c4f78212a37@xchsrv02.allina.com> Message-ID: <1429814073.59544.YahooMailBasic@web160703.mail.bf1.yahoo.com> Your clue is in this line: > DISK CRITICAL - free space: /data02b 0 MB (0% inode=99%);| /data02b=2147483647MB;10874142;11096064;0;11096064 That "2147483647" number should look suspicious to you (being exactly 2^^31 ? 1). It's your evidence that check_disk encountered some sort of integer-overflow condition when sensing the disk space. Quite possibly, the underlying disk driver returned such a number when asked about the amount of space in the partition. Given that the two partitions in question both had 27873280 MB overall capacity (i.e., 28542238720 KB), and none of the other partitions approach anywhere near this size, I'd say that check_disk has trouble dealing with such a large partition. 64-bit arithmetic will be required throughout to handle this case. The only way to debug this for sure is to dig into the check_disk code and instrument it to print out what it gets back from the OS when asking for the disk information, and then trace the arithmetic operations in check_disk itself. And, look for evidence of 32-bit arithmetic within both results requested for disk sizing from the OS and for subsequent calculations within check_disk. On Tue, 3/31/15, Phan, Thao-Chi X wrote: > Please explain to me why the /usr/local/groundwork/nagios/libexec/check_disk > doesn't report the correct disk space free on 2 mount points /data02b and /data02a on a server. > > root at abc2/usr/local/groundwork/nagios/libexec# df -m > Filesystem MB blocks Free %Used Iused %Iused Mounted on > /dev/hd4 512.00 336.67 35% 5761 3% / > /dev/hd2 5120.00 2051.53 60% 44310 4% /usr > /dev/hd9var 512.00 228.29 56% 26189 20% /var > /dev/hd3 3072.00 2973.20 4% 101 1% /tmp > /dev/hd1 7168.00 4794.46 34% 1854 1% /home > /proc - - - - - /proc > /dev/hd10opt 1024.00 320.47 69% 9826 4% /opt > /dev/locallv 2048.00 1136.73 45% 720 1% /usr/local > /dev/hd11admin 128.00 123.93 4% 20 1% /admin > /dev/oralv 143360.00 100961.11 30% 203739 1% /oracle > /dev/data01lv 276224.00 124619.55 55% 86 1% /data01 > /dev/eplv 256.00 253.61 1% 6 1% /epic > /dev/clarlv 303104.00 89595.34 71% 67974 1% /epic/clarity > /dev/ftplv 512.00 507.60 1% 4 1% /ftpdir > /dev/dbkuplv 97792.00 67809.48 31% 3748 1% /dbkup > /dev/data03lv 215040.00 32499.46 85% 89 1% /data03 > /dev/ctmaglv 5120.00 4587.26 11% 3301 1% /ctmag > /dev/dump_cp 5120.00 5098.90 1% 4 1% /var/adm/ras/dump_cp > /dev/lv00 27873280.00 11204341.16 60% 880 1% /data02b > /dev/lv02 5120.00 5027.61 2% 12 1% /data04b > /dev/lv01 46080.00 16327.36 65% 14 1% /oraredob > /dev/lv04a 27873280.00 2550106.27 91% 880 1% /data02a > /dev/lv06a 5120.00 5027.61 2% 12 1% /data04a > /dev/lv05a 46080.00 16327.36 65% 14 1% /oraredoa > > -------INCORRECT --- 0 MB is not correct. 0% free is not correct. > root at abc2 /usr/local/groundwork/nagios/libexec# ./check_disk -w 2% -c 0% -p /data02b > DISK CRITICAL - free space: /data02b 0 MB (0% inode=99%);| /data02b=2147483647MB;10874142;11096064;0;11096064 > > -------INCORRECT ---- 22% free is not correct > root at abc2 /usr/local/groundwork/nagios/libexec# ./check_disk -w 2% -c 0% -p /data02a > DISK OK - free space: /data02a 2550106 MB (22% inode=99%);| /data02a=8545957MB;10874142;11096064;0;11096064 > > -------CORRECT > root at abc2 /usr/local/groundwork/nagios/libexec# ./check_disk -w 2% -c 0% -p /data04a > DISK OK - free space: /data04a 5027 MB (98% inode=99%);| /data04a=92MB;5017;5120;0;5120 > > -------CORRECT > root at abc2 /usr/local/groundwork/nagios/libexec# ./check_disk -w 2% -c 0% -p /oracle > DISK OK - free space: /oracle 100961 MB (70% inode=99%);| /oracle=42398MB;140492;143360;0;143360 > > Thanks a lot. > > Thao-Chi From notifications at github.com Wed Apr 29 06:38:16 2015 From: notifications at github.com (Geoff) Date: Tue, 28 Apr 2015 21:38:16 -0700 Subject: check_ping: Adjusting packet size [sf#781002] (#229) In-Reply-To: References: Message-ID: I'd really like this as well. We had a router replaced last week which was misconfigured, and dropping packets larger than 1468 bytes. We didn't even know we had a problem until users were complaining the next morning. Now I want to setup some monitoring to catch this earlier, which would need this option. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/229#issuecomment-97302045 -------------- next part -------------- An HTML attachment was scrubbed... URL: