How to force re-distribution of extensions in a multisite setup?

Hello everybody,

I have an issue during CheckMk extension development:
My main plugin file (in local/lib/check_mk/base/plugins/agent_based) crashes. But changes to this file won’t get active in my multisite setup. I’m changing the file on my master server while the check is performed from a satellite.

When I search for my plugin in the filesystem I do not only find it in local/lib/check_mk but also in local/lib/python3/cmk and var/check_mk/site_configs/<satellite name>/local/lib/python3/cmk. The last two locations contain the old version of the plugin. I suppose they are created during multisite extension distribution.

So how do I force re-distribution of my extension files?

Regards,
Carsten

You can make an extension package only with this file inside. If you change the version number the extension package will be pushed to all sites again.

Unfortunately that did not help.

I’m quite confused now:
I’ve deleted the files containing the old versions of my plugin and recreated the extension package. Now I have the correct version of my file in these folders: local/lib/check_mk (of course) and var/check_mk/site_configs/<satellite name>/local/lib/check_mk. Obviously the satellite-specific files reside in a different directory than the old versions I’ve deleted before. It might be the case that these files existed even before the deletions, unfortunately I didn’t check.
Also I’ve confirmed that the correct version got replicated to the satellites (into folder local/lib/check_mk)

But now the check does not work any more at all. CheckMk reports for the existing services “no matching plugin found” and the service discovery does not show them any more.

So it boils down to the question:
How do the folders local/lib/check_mk and local/lib/python3/cmk relate to each other? Obviously checks only work when they reside in the latter folder while I install them to the first. What triggers them to be copied?

It’s really strange: I’ve deleted my extension and all files belongig to it. Afterwards I’ve re-installed it. Still it does not work…

I have a theory… Maybe I’ve messed up with my site directory structure?
I notice that lib/check_mk is a symbolic link to lib/python3/cmk
But local/lib/check_mk is not a symbolic link to local/lib/python3/cmk. Could this be the issue?
At least all working checks reside in local/lib/pyton3/cmk whereas everything I install to local/lib/check_mk won’t work…

Yes, that assumption is correct: when I create a new site local/lib/check_mk links to local/lib/python3/cmk

I have a zip file that contains all the files for my extension with the correct directory structure. The top most folder in the zip file ist local. To deploy it I just perform unzip extension.zip in the home dir of my site. I suppose this removed the link…

That is a now problem in the activation Process. The Helper Process on the Sites are not restartet and still use the old code.

Make a dummy Update in your MKP File and activate the change on all Sites. After that you need to execute a “cmd restart smc” on all Sites. This will restart the Helper Process with the new code.

Changes in this path did not result in a core restart on remote sites. This will be fixed with werk #12861.

As @LaSoe mentioned, workaround is to manually restart the core on the remote site after activating changes

omd restart cmc

I’ve just noticed that there was still some activity in this thread. So thanks for your answers.
Yes, I’ve also noticed that it sometimes helps to restart cmc.
But the actual issue was – as I tried to describe above – that the extraction of my zip file destroyed the directory structure in local/lib because the link local/lib/check_mk was replaced by an actual folder so data in the link target local/lib/python3/cmk remained unchanged.
I fixed that by replacing the folder local/lib/check_mk by local/lib/python3/cmk in my zip file.