Yes, the linux systems are IPv4 only.
I’ll take a look at the Windows problem next week and open a new thread for it if necessary.
Thank you very much for your help.
1 Like
Thanks for the feedback: I’ll setup an IPv4 test environment and discuss with the developers. I’d notify you when an updated agent package is available.
Hi there,
upgraded to 2.1.0 as well (including agents) - installation on CentOS7 does not work - agent can only run with xinetd / legacy mode - controller agent is not starting and also the systemd config files are not created during installation of the rpm package.
Output of rpm package install:
[root@jumphost ~]# rpm -ivh check-mk-agent-2.1.0-1.noarch.rpm --force
Preparing… ################################# [100%]
Updating / installing…
1:check-mk-agent-2.1.0-1 ################################# [100%]
The Checkmk agent may require features that are either buggy,
or not even supported in systemd versions prior to 220.
We recommend using xinetd on such old systems.
Deployed xinetd
Creating/updating cmk-agent user account …
Deactivating systemd unit ‘check-mk-agent-async.service’…
Deactivating systemd unit ‘check-mk-agent.socket’…
Deactivating systemd unit ‘cmk-agent-ctl-daemon.service’…
Reloading xinetd
Redirecting to /bin/systemctl reload xinetd.service
Regards
Your problem has nothing to do with the other problems.
CentOS 7 is too old for the agent controller as you have only systemd version 219 in your system.
This message shows the minimum version of systemd needed.
1 Like
Hi Andreas,
thank you for your prompt response. Well, CentOS 7 may be “old” but has support until June 30, 2024 whereby the newer CentOS 8 is already end of life (December 31, 2021).
I am confident many people still use CentOS 7 since AlmaLinux and Co. are still pretty new.
What are your recommendations then or can you make the agent compatible to v219 of systemd ?
Regards
Please install xinetd. Afterwards, just reinstalling the agent or following this should help: Agent Problems after update to 2.1.0 - #11 by Ikkarus13
Hi,
the check-mk-agent is running (in xinetd mode) - trying to register a client is not possible because the cmk controller is looking for a socket (systemd)
[root@jumphost]# cmk-agent-ctl status
Version: 2.1.0
Agent socket: inoperational (!!)
IP allowlist: any
Legacy mode: enabled
No connections
[root@jumphost]# ss -tulpn | grep 6556
tcp LISTEN 0 64 [::]:6556 [::]:* users:((“xinetd”,pid=932,fd=5))
[root@jumphost xinetd.d]#
[root@jumphost]# cmk-agent-ctl register --hostname myclient \
--server cmkserver --site mysite \
ERROR [cmk_agent_ctl] Something seems wrong with the agent socket (/run/check-mk-agent.socket), aborting
[root@jumphost xinetd.d]#
OK, please also stop cmk-agent-ctl-daemon.service then restart xinitd and tell me about the output of ss -tulpn | grep 6556. Just to make sure people like me do not get confused you might start a new thread…
See CMK Agent Controller not working (CentOS 7) - CMK 2.1
Thank you!
1 Like
It seams you use a Debian system. For Debian remove the cmk-agent and purge the configuration, than reinstall the agent, this purges the xinetd configuration.
apt remove --purge check-mk-agent
dpkg -i check-mk-agent_2.1.0-1_all.deb
Now the cmk-agent-ctl-daemon.service should work as expected.
The Linux kernel needs IPv6 enabled, see this link for more information: Agent upgrade to 2.1.0 - cmk-agent-ctl[3883704]: ERROR [cmk_agent_ctl] Address family not supported by protocol (os error 97)
Hello,
I just installed the new CheckMK version 2.1.0p1. After that the three linux hosts get the problem back.
I will make your workaround again for theese three hosts.
Bye, Sascha
Please provide us with:
uname -a
cat /proc/cmdline
sysctl -a | grep ipv
If the output contains sensible information, send an email to mattias.schlenker@tribe29.com.
I send a mail to you.
We have used a large part of our linux systems, historically still xinetd for the checkmk_agent.
During an test for a debian host (default systemd and xinetd for the checkmk-agent), I also had the issue that the change of the super_server to be used (via agentbackery) from xinetd to systemd is maybe buggy, because the xinetd configuration for the check_mk-agent was not cleaned correctly and the xinetd hold the process again and prevents the agent under systemd to be installed.
I think there is a bug with the deinstallation function for the xinetd in the baked agents when you want to switch from xinetd to systemd.
I think, the hint of @WalterH comes there already in the right/same direction.
Sorry - that my 50cents are undocumented.
Hey,
Seeing the same behavior on several hosts. After looking at it, it seems like the socket isn’t listening so the new agent can’t grab data over it.
[root@host checkpoints]# systemctl status check-mk-agent.socket
● check-mk-agent.socket - Local Checkmk agent socket
Loaded: loaded (/usr/lib/systemd/system/check-mk-agent.socket; disabled; vendor preset: disabled)
Active: active (listening) since Wed 2022-06-01 15:48:20 CEST; 1 weeks 0 days ago
Listen: /run/check-mk-agent.socket (Stream)
Accepted: 9881; Connected: 0;
Tasks: 0 (limit: 101044)
Memory: 4.0K
CGroup: /system.slice/check-mk-agent.socket
As you see, the service is disabled at startup.
Issuing systemctl start check-mk-agent.socket will fix it. The good question would be, why is it disabled while it wasn’t before ?
I have two checkmk installations (two WMs).
One is “production” and the other “testing”, and they are monitoring (among other things) each other.
Interesting thing is:
Production machine with CMK 2.0.0p22.cee version does not see “fwupd-refresh failed” problem, which the testing WM with CMK 2.1.0p1.cee version does “detect”.
Hello,
I installed version 2.1.0p4 today and I still have the problem with the agent with two Linux servers. Could only solve it with Mattias’ workaround. Shouldn’t the problem have already been solved with p3?
Bye, Sascha
And the same with Version 2.1.0p5.