Description of problem: There is extraneous output produced, making the check's output unable to be read on one line. Version-Release number of selected component (if applicable): nagios-plugins-disk-2.2.1-17.20190829gitfb792ff.el7.x86_64 How reproducible: Always Steps to Reproduce: 1. Upgrade from nagios-plugins-disk-2.2.1-16.20180725git3429dad.el7.x86_64 to nagios-plugins-disk-2.2.1-17.20190829gitfb792ff.el7.x86_64 2. Run check_disk with any appropriate options (e.g. check_disk -w 20 -c 10) 3. Actual results: dfree_units 0 0 disk_result is 0dfree_units 0 0 disk_result is 0dfree_units 0 2 disk_result is 2dfree_units 0 0 disk_result is 0dfree_units 0 0 disk_result is 0DISK CRITICAL - free space: <SNIP> Expected results: DISK CRITICAL - free space: <SNIP> Additional info: I have reported an Issue and submitted a Pull Request upstream: https://github.com/nagios-plugins/nagios-plugins/issues/472 I used a higher severity since I have encountered monitoring solutions that used a regex against the output rather than relying on the exit code. This would break that methodology of checking the check's result, with this extra output "^DISK OK" would now be a failure.
*** Bug 1752272 has been marked as a duplicate of this bug. ***
Will be adding this to https://github.com/nagios-plugins/nagios-plugins/issues/472 as well. However I would also like to point out that this extraneous dfree_units lines and the 0 just before the status type also occur for an OK check, however if you do a more verbose check the extraneous 0 in the line starting with DISK looses the 0 before the status. /usr/lib64/nagios/plugins/check_disk -w 10% -c 5% -p /boot I am returned dfree_units 0 0 disk_result is 0DISK OK - free space: /boot 315 MiB (63.43% inode=100%);| /boot=181MiB;446;471;0;496 I would expect to see DISK OK - free space: /boot 315 MiB (63.43% inode=100%);| /boot=181MiB;446;471;0;496 When using the -vvv (note that between DISK and OK the extraneous 0 has disappeared and the last line is like what I would expect on a normal run. /usr/lib64/nagios/plugins/check_disk -vvv -w 10% -c 5% -p /boot calling stat on /boot Thresholds(pct) for /boot warn: 10.000000 crit 5.000000 calling stat on /boot For /boot, used_pct=36.57 free_pct=63.43 used_units=181 free_units=315 total_units=496 used_inodes_pct=0.07 free_inodes_pct=99.93 fsp.fsu_blocksize=4096 mult=1048576 Freespace_units result=0 Freespace% result=0 dfree_units 0 0 disk_result is 0Usedspace_units result=0 Usedspace_percent result=0 Usedinodes_percent result=0 Freeinodes_percent result=0 DISK OK - free space: /boot 315 MiB (63.43% inode=100%);| /boot=181MiB;446;471;0;496
(In reply to Alexander Kohr from comment #2) > [SNIP] > When using the -vvv (note that between DISK and OK the extraneous 0 has > disappeared and the last line is like what I would expect on a normal run. > [SNIP] > dfree_units 0 0 > disk_result is 0Usedspace_units result=0 > Usedinodes_percent result=0 > Freeinodes_percent result=0 > DISK OK - free space: /boot 315 MiB (63.43% inode=100%);| > /boot=181MiB;446;471;0;496 The second extraneous printf does not include a trailing newline, which is why you see it on the same line as "Usedspace_units" in the -vvv output. The verbose Freeinodes statement has a newline and is printed afterwards (correctly) giving you a newline before "DISK OK".
Thank you. I had posted this prior to trying to review the code in github. In my github post (To the link above.) I suggested that the line I think is responsible for that needed a line break after it, if the line is going to be maintained as a verbose output. -Alex
For reference, the Pull Request has been merged: https://github.com/nagios-plugins/nagios-plugins/pull/473
This is also a issue on EL6 not only on EL7 > [root@webXXXXXX ~]# /usr/lib64/nagios/plugins/check_disk -w 10% -c 5% -W 10% -K 5% -p / > dfree_units 0 0 > disk_result is 0DISK OK - free space: / 4737 MiB (64.48% inode=79%);| /=2608MiB;6971;7358;0;7746 > > nagios-plugins-disk-2.2.1-17.20190829gitfb792ff.el6.x86_64
Nor is there a yum downgrade option. I see https://github.com/nagios-plugins/nagios-plugins/pull/473 was merged 5 days ago, but I don't see an updated pkg in yum check-update for centos 7.
I do this in what spare time I have which is not a lot. You get 4 hours a weekend if I am lucky. If that is not enough, then there are several probably better resourced alternatives that you can use or pay for.
And that comment was crap on my part. I am updating the spec file and trying to get builds out as we speak.
(In reply to Stephen John Smoogen from comment #9) > And that comment was crap on my part. I am updating the spec file and trying > to get builds out as we speak. Hi Smooge, I don't know if this will save you any time now that you've started to work on it, but I worked on updating all the git branches and ran scratch builds last night. Scratch builds: rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=37767647 f31: http://koji.fedoraproject.org/koji/taskinfo?taskID=37767607 f30: http://koji.fedoraproject.org/koji/taskinfo?taskID=37767614 f29: http://koji.fedoraproject.org/koji/taskinfo?taskID=37767621 epel8: http://koji.fedoraproject.org/koji/taskinfo?taskID=37771425 epel7: http://koji.fedoraproject.org/koji/taskinfo?taskID=37771431 el6: http://koji.fedoraproject.org/koji/taskinfo?taskID=37771435 Git repo: https://src.fedoraproject.org/fork/tmz/rpms/nagios-plugins If that looks decent and you think it'll save you any time or effort, I can file PR's for each branch. Thanks for all the effort you put in on this and everything else in Fedora/EPEL. Sorry I couldn't get these builds/PR's up sooner. :)
Should remember that I was posting to the other bug. Thanks Todd Z for putting the updates.. I didn't see this updated bug until I had already started melding all the spec file and my fedpkg new-sources failed :). You should see a bunch of builds coming to the various releases in the next 1-2 hours. Thanks for the scratch-builds they saved 2 steps I go through.
FEDORA-EPEL-2019-904c578b3f has been submitted as an update to Fedora EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-904c578b3f
FEDORA-EPEL-2019-dfd2737e17 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-dfd2737e17
nagios-plugins-2.2.2-1.20190919git00cff01.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-dfd2737e17
nagios-plugins-2.2.2-1.20190919git00cff01.el6 has been pushed to the Fedora EPEL 6 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-904c578b3f
Tests positively for me on Centos 7 and Fedora 29, thanks.
The check_disk_smb plugin picked up a requirement on 'perl(utf8::all)' in upstream commit c8714d72 ("check_disk_smb.pl: added utf support & blacklisting characters instead of expanding the whitelist", 2019-08-02). It's easy enough to revert that on el6, which seems like it's probably less work than trying to make it an optional requirement upstream. I have done that locally. Before I submit it as a pull request, what is your preference as far as what git branch(es) to make the change? I can do it only on el6 and use no rpm conditionals. If that makes it harder to merge between other branches, I can do it conditionally and base it on the epel7 branch (which appears to be merged into el6 or vice versa). The latter method is how I did it locally. I pushed the result here: https://src.fedoraproject.org/fork/tmz/rpms/nagios-plugins/c/5853d86
I am confirming that the newly built nagios-plugins-disk.x86_64 2.2.2-1.20190919git00cff01.el7 epel-testing that the package is working correctly in RHEL 7.7 install. However it seems nagios-plugins-disk.x86_64 2.2.1-17.20190829gitfb792ff.el6 made it into the official epel repo for el6 x86 and not just the testing repo. When I enable the epel-testing repo for el6. I am also experiencing the check_disk_smb.pl requires perl... error Todd Zulling mentioned in the last comment. Thank you for what you have done so far.
Note if you are in a larger shop to avoid this from happening on other RHEL 6 based OSes you can run your yum update command as follows, and it will if nessicary update you to the previous version or update to the next version. yum update --exclude=nagios-plugins-*2.2.1-17.20190829gitfb792ff.el6
My comment about previous version only works if you have a local repo set up to keep multiple copies. The official repo mirror my local repo server is connecting does not have older version in it.
Working with upstream, the utf8::all module is now optional (https://github.com/nagios-plugins/nagios-plugins/pull/479 and https://github.com/nagios-plugins/nagios-plugins/commit/1b8ad57). I updated the el6 branch in my nagios-plugins package fork to use the latest upstream git: https://src.fedoraproject.org/fork/tmz/rpms/nagios-plugins/c/8885b16?branch=el6 Stephen, let me know how I can best help you preparing that as an update. I don't know what your preference/process is for applying changes like this across the various branches. In any case, we should be able to update to the latest git snapshot from upstream's maint branch and it won't have the 'perl(utf8::all)' dep. I manually added 'Requires: perl(utf8::all)' to the disk-smb subpackage for non-el6 systems in the commit I made to the el6 branch. The check_disk_smb plugin works without that, but it seems ideal to ensure we require it so results aren't dependent on whether a system has that package or not.
nagios-plugins-2.2.2-2.20190926git1b8ad57.el6 will be appearing 'soon' in updates.
FEDORA-EPEL-2019-e8e98311c9 has been submitted as an update to Fedora EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-e8e98311c9
FEDORA-EPEL-2019-d5a42a332c has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d5a42a332c
nagios-plugins-2.2.2-2.20190926git1b8ad57.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d5a42a332c
nagios-plugins-2.2.2-2.20190926git1b8ad57.el6 has been pushed to the Fedora EPEL 6 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-e8e98311c9
nagios-plugins-2.2.2-2.20190926git1b8ad57.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.
I'm still getting this in EPEL 7 while trying to update nagios-plugins Error: Package: nagios-plugins-disk_smb-2.2.2-2.20190926git1b8ad57.el7.x86_64 (epel) Requires: perl(utf8::all)
(In reply to Berthold Cogel from comment #28) > I'm still getting this in EPEL 7 while trying to update nagios-plugins > > Error: Package: > nagios-plugins-disk_smb-2.2.2-2.20190926git1b8ad57.el7.x86_64 (epel) > Requires: perl(utf8::all) That requirement is provided in EL7 by perl-utf8-all-0.011-1.el7.noarch.
nagios-plugins-2.2.2-2.20190926git1b8ad57.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.