CMK version: 2.2.0p17.cre
OS version: Debian GNU/Linux 12 (bookworm)
Error message:
N/A
Output of “cmk --debug -vvn hostname”: (If it is a problem with checks or plugins)
-bash: cmk: command not found
Hi!
I’m in the process of deploying the mk_apt plug-in to several Linux hosts.
It is located within the /lib/check_mk_apt/plugins directory, owned by root, with 755 file-bit permissions:
user@host1:~ $ ansible all -b -m shell -a "ls -l /lib/check_mk_agent/plugins/mk_apt"
host2 | CHANGED | rc=0 >>
-rwxr-xr-x 1 root root 1589 Feb 24 02:27 /lib/check_mk_agent/plugins/mk_apt
host1 | CHANGED | rc=0 >>
-rwxr-xr-x 1 root root 1589 Feb 24 02:27 /lib/check_mk_agent/plugins/mk_apt
host3 | CHANGED | rc=0 >>
-rwxr-xr-x 1 root root 1589 Feb 24 02:27 /lib/check_mk_agent/plugins/mk_apt
host4 | CHANGED | rc=0 >>
-rwxr-xr-x 1 root root 1589 Feb 24 02:27 /lib/check_mk_agent/plugins/mk_apt
user@host1:~ $
It executes without error:
user@host1:~ $ ansible all -b -m shell -a "/lib/check_mk_agent/plugins/mk_apt"
host2 | CHANGED | rc=0 >>
<<<apt:sep(0)>>>
All packages are up to date.
host4 | CHANGED | rc=0 >>
<<<apt:sep(0)>>>
All packages are up to date.
host3 | CHANGED | rc=0 >>
<<<apt:sep(0)>>>
All packages are up to date.
host1 | CHANGED | rc=0 >>
<<<apt:sep(0)>>>
All packages are up to date.
user@host1:~ $
I’m not seeing a new Service appear in the list of Services for any of the 4 hosts though, not even as Pending.
While reading thru other threads of similar mk_apt plug-in issues, I get the impression that a Service Discovery rule for APT Updates may not be required. Unfortunately, enabling/disabling the APT Updates Service Monitoring rule does not seem to make any difference.
What do I have mis-configured?
Hi,
what does running check_mk_agent| grep -A1 '...apt' result in? Is the line <<<apt:sep(0)>>> shown?
Another suggestion, not exactly related to your problem: Put the mk_apt plugin into a subfolder with the amount of seconds that you want a cache to be valid. For example, I put mine into a subfolder “43200” in order to have 12h cache for this check. Then, also take a look inside the plugin itself. If left on default, this plugin will perform an update by itself, which
a) could take longer and results in a slow execution / long wait time of your agent
b) might be something you do not want
Thank you @simon-mueller !
It seems the expected result is generated when executing the Agent as well:
user@host1:~ $ ansible all -b -m shell -a "check_mk_agent| grep -A1 '^<<<apt:sep(0)>>>'"
host2 | CHANGED | rc=0 >>
<<<apt:sep(0)>>>
All packages are up to date.
host4 | CHANGED | rc=0 >>
<<<apt:sep(0)>>>
All packages are up to date.
host3 | CHANGED | rc=0 >>
<<<apt:sep(0)>>>
All packages are up to date.
host1 | CHANGED | rc=0 >>
<<<apt:sep(0)>>>
All packages are up to date.
user@host1:~ $
Thank you for the scheduling suggestion! Once I can achieve a working state, I’ll definitely move forward with that.
Thanks again @simon-mueller for the suggestions. I agree, scheduling the APT plug-in avoids excessive execution and unpredictable changes that the apt upgrade may otherwise introduce.
While sub-dirs easily allow the scheduling of the APT plug-in’s execution, unfortunately though my CheckMK Raw Server apparently still does not see or process this part of the CheckMK Linux Agents:
<<<apt:sep(0):cached(1712513174,3600)>>>
All packages are up to date.
Recently, I came across a blog article which contains some detail on how I might further troubleshoot the problem by evaluating the output from the APT check’s execution on the CheckMK server. Perhaps the output will reveal more clues when Updates exist for installation:
OMD[mysite]:~$ cmk -nv --checks=apt host2
WARNING: '--checks' is deprecated in favour of option 'detect-plugins'
+ FETCHING DATA
[TCPFetcher] Execute data source
[agent] Success, execution time 1.5 sec | execution_time=1.510 user_time=0.170 system_time=0.020 children_user_time=0.000 children_system_time=0.000 cmk_time_agent=1.320
OMD[mysite]:~$
Perhaps the output will reveal more clues when Updates exist for installation:
OMD[mysite]:~$ cmk -nv --checks=apt host2
WARNING: '--checks' is deprecated in favour of option 'detect-plugins'
+ FETCHING DATA
[TCPFetcher] Execute data source
[agent] Success, execution time 1.5 sec | execution_time=1.510 user_time=0.170 >system_time=0.020 children_user_time=0.000 children_system_time=0.000 cmk_time_agent=1.320
OMD[mysite]:~$
I think that is incorrect, this seems to be the correct way of using --detect-plugins:
OMD[mysite]:~$ cmk --debug -vvv --detect-plugins mk_apt host1 | grep apt
<<<apt:cached(1713118494,3600):sep(0)>>> / Transition HostSectionParser -> HostSectionParser
OMD[mysite]:~$ cmk --debug -vvv --detect-plugins mk_apt host2 | grep apt
<<<apt:cached(1713116484,3600):sep(0)>>> / Transition HostSectionParser -> HostSectionParser
OMD[mysite]:~$ cmk --debug -vvv --detect-plugins mk_apt host3 | grep apt
<<<apt:cached(1713115175,3600):sep(0)>>> / Transition HostSectionParser -> HostSectionParser
OMD[mysite]:~$ cmk --debug -vvv --detect-plugins mk_apt host4 | grep apt
<<<apt:cached(1713116836,3600):sep(0)>>> / Transition HostSectionParser -> HostSectionParser
OMD[mysite]:~$
What do you see, when you run cmk -d host2? It will give you the raw agent output, as the Checkmk server sees it. If the apt sections are not in there, it is an agent side problem.
If the data is there, you maybe just forgot to add the service in the service configuration (aka. service discovery), or you have a “Disabled Services” or “Disabled Checks” rule?
1 Like