Agent RPM installing xinetd rather than service/socket systemd files

I have a couple of SLES 15 SP3 servers and when I deploy a Checkmk agent on them, it installs 2 systemd unit files: check_mk.socket and check_mk-async.service. However, on the Checkmk server, also running on SLES 15 SP3, installing that same RPM agent installs xinetd with the appropriate file for checkmk. Am I missing something? I don’t understand why installing the same RPM on the same OS acts differently when that OS is also hosting the Checkmk server.

Also, while looking at check_mk-async.service, I noticed the process forks into a sleep 60. There are better ways to do this with systemd…

If your SLES system has no active xinetd then the systemd unit files are installed.
It looks like your two systems are not exactly the same. The CMK server itself needs xinetd and this is the reason why the agent installs here the xinetd service.

1 Like

Interesting. Do you know why the Checkmk server needs xinetd? Is it for distributed monitoring? I noticed there are no specific config files other than the default ones bundled with xinetd and the check_mk agent in /etc/xinetd.d/.

Also, why use xinetd instead of systemd when both are available? Just curious. I feel like systemd would be much more reliable but I could be wrong.

The xinetd is needed for the livestatus connections between the sites.

This depends on the configuration of the agent installation package.
Inside the enterprise agent bakery you can define how the agent should behave at installation time. I don’t know how the default agent is configured.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.