Closed a-mlbz closed 4 years ago
At least I can confirm this problem. As I am right now checking all issues which might come with production use of CentOS8 this one will be fixed soon I guess. I will let you know of any news.
Thank you very much Henri, very much appreciated!
Btw, I noticed that only 3 out of 4 CentOS 8 servers report the available update. The fourth one never showed anything in CMK so far and the yum status is "OK - All packages are up to date".
Cheers Manuel
What is the content of /var/lib/check_mk_agent/cache/
on your clients? I found this:
/var/lib/check_mk_agent/cache/:
insgesamt 16
-rw-r--r--. 1 root root 496 28. Apr 09:51 chrony.cache
-rw-r--r--. 1 root root 15 28. Apr 09:51 'plugins_86400\yum.cache'
-rw-r--r--. 1 root root 5 28. Apr 09:51 yum_check.cache
-rw-r--r--. 1 root root 1 28. Apr 09:51 yum_state.cache
The plugins_86400\yum.cache
seems to be new - we are using 1.6. What does your 1.5 do there?
Hey Henri,
pretty much the same:
# ls -ls /var/lib/check_mk_agent/cache/
total 20
4 -rw-rw-r-- 1 root root 497 Apr 28 11:09 chrony.cache
4 -rw-rw-r-- 1 root root 114 Apr 28 09:47 'plugins_7200\cmk-update-agent.cache'
4 -rw-rw-r-- 1 root root 15 Apr 28 10:23 'plugins_7200\yum.cache'
4 -rw-rw-r-- 1 root root 5 Apr 20 13:31 yum_check.cache
4 -rw-rw-r-- 1 root root 1 Apr 20 13:31 yum_state.cache
Have a look at the timestamps, looks like yum_check.cache
and yum_state.cache
wont get updated?
The yum_*.cache files are created by the check_yum plugin, because they where not just triggered every day or hours in earlier versions of it or checkmk. Well, apparently it has to consider different paths too.
Let me know if I can help or provide more infos if needed.
Can you please check if it works now with the latest 2.0.11 release?
Hey Henri, the update count changed now, but it looks like it is counting one to much. CMK showed me 15 updates, on the VM were only 14 available. After I installed the updates everywhere, CMK shows now one update for all my CentOS 8 hosts. And on the VMs are no further updates left to install.
The number of updates is "calculated" by https://github.com/HenriWahl/checkmk-agent-plugin-yum/blob/master/agents/plugins/yum#L72
What is your result when you run the command which sets the UPDATES variable?
# yum check-update
Last metadata expiration check: 0:20:51 ago on Fri 15 May 2020 02:48:12 PM CEST.
# yum update
Last metadata expiration check: 0:20:55 ago on Fri 15 May 2020 02:48:12 PM CEST.
Dependencies resolved.
Nothing to do.
Complete!
# yum -C --noplugins list updates | grep "\." | cut -d' ' -f1 | wc -l || echo "-1"
1
I added a --quiet to the yum command in my last commit https://github.com/HenriWahl/checkmk-agent-plugin-yum/commit/1f22dd80ed089350a08152b9b8ef8b1b3b8ee2f6 and now get correct results.
Uploaded 2.0.12 too.
Count is zero now :)
I will observe it on the mentioned hosts. Also deployed it to some older CentOS hosts to check it there. Will update you next week with the results.
Have a great weekend!
Looks good! Also on the older CentOS versions.
Is there any reason why the mkp file needs OMD 1.6? Would be nice if I could just upload the packet to our 1.5.0p16 version.
Yes, but I forgot it. Isn't it a good reason to upgrade?
Touche. But it's not that easy with almost 40 slaves in a bigger environment... :) We already tried but faced some issues, so we had to roll back for now.
Hey Henri,
first of all thank you very much for this great check!
We are using your plugin for quite some time now and had no issues so far.
Now we deployed some CentOS 8.1 servers and it looks like the amount of available updates is calculated wrong.
We have three hosts which all show 1 available update. But if you connect to the server, there is no update available when running "yum update".
Updating yum cache or deleting the check cache files also didn't help. As soon as the check runs again, it finds 1 update to install (which is still not the case).
We are using Check_mk Enterprise 1.5.0p16 and version 2.0.8 of your plugin, as 2.0.10 requires 1.6.0.
But I compared the changes between 2.0.8 and 2.0.10 and added "--debuglevel 0" to the yum check. Unfortunately this didnt help either.
Any advise?
Cheers Manuel