Docker monitoring broken

CMK version: 2.4.0p24
OS version: VMware Photon OS

Error message:

Traceback (most recent call last):
  File "/usr/lib/check_mk_agent/plugins/mk_docker.py", line 758, in <module>
    main()
    ~~~~^^
  File "/usr/lib/check_mk_agent/plugins/mk_docker.py", line 754, in main
    call_container_sections(client, config)
    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^
  File "/usr/lib/check_mk_agent/plugins/mk_docker.py", line 684, in call_container_sections
    job.start()
    ~~~~~~~~~^^
  File "/usr/lib/python3.14/multiprocessing/process.py", line 121, in start
    self._popen = self._Popen(self)
                  ~~~~~~~~~~~^^^^^^
  File "/usr/lib/python3.14/multiprocessing/context.py", line 224, in _Popen
    return _default_context.get_context().Process._Popen(process_obj)
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/usr/lib/python3.14/multiprocessing/context.py", line 300, in _Popen
    return Popen(process_obj)
  File "/usr/lib/python3.14/multiprocessing/popen_forkserver.py", line 35, in __init__
    super().__init__(process_obj)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/usr/lib/python3.14/multiprocessing/popen_fork.py", line 20, in __init__
    self._launch(process_obj)
    ~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/usr/lib/python3.14/multiprocessing/popen_forkserver.py", line 47, in _launch
    reduction.dump(process_obj, buf)
    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.14/multiprocessing/reduction.py", line 60, in dump
    ForkingPickler(file, protocol).dump(obj)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^
_pickle.PicklingError: Can't pickle local object <function UnixHTTPAdapter.__init__.<locals>.<lambda> at 0x7f3394469a60>
when serializing dict item 'dispose_func'
when serializing urllib3._collections.RecentlyUsedContainer state
when serializing urllib3._collections.RecentlyUsedContainer object
when serializing dict item 'pools'
when serializing docker.transport.unixconn.UnixHTTPAdapter state
when serializing docker.transport.unixconn.UnixHTTPAdapter object
when serializing collections.OrderedDict item 'http+docker://'
when serializing collections.OrderedDict object
when serializing dict item 'adapters'
when serializing docker.api.client.APIClient state
when serializing docker.api.client.APIClient object
when serializing dict item 'api'
when serializing MKDockerClient state
when serializing MKDockerClient object
when serializing tuple item 0
when serializing dict item '_args'
when serializing multiprocessing.context.Process state
when serializing multiprocessing.context.Process object

Since upgrading Python to 3.14 all Docker monitoring is totally broken. Running the plugin script produces a lot of monitoring output but crashes then with the error message above. Therefore the CMK server can’t read the output and all my Docker containers are shown as piggyback missing data.

After asking the search machine/AI for some breaking changes in Python 3.14 regarding the multiprocessing library i got this.

Yes there are breaking changes that need some manual code changes.

from What’s new in Python 3.14 — Python 3.14.3 documentation

####################
On Unix platforms other than macOS, ‘forkserver’ is now the default start method for ProcessPoolExecutor (replacing ‘fork’). This change does not affect Windows or macOS, where ‘spawn’ remains the default start method.

If the threading incompatible fork method is required, you must explicitly request it by supplying a multiprocessing context mp_context to ProcessPoolExecutor.

See forkserver restrictions for information and differences with the fork method and how this change may affect existing code with mutable global shared variables and/or shared objects that can not be automatically pickled.

(Contributed by Gregory P. Smith in gh-84559.)

####################

To get back to old behavior you need to declare how the process should be started (before it was fork)

Again from the Python docs for multiprocessing library

fork

The parent process uses os.fork() to fork the Python interpreter. The child process, when it begins, is effectively identical to the parent process. All resources of the parent are inherited by the child process. Note that safely forking a multithreaded process is problematic.

Available on POSIX systems.

Changed in version 3.14: This is no longer the default start method on any platform. Code that requires fork must explicitly specify that via get_context() or set_start_method().
################

I think you can change this inside the mk_docker script to work again.

FYI:
This issue is adressed in a Support Ticket and will most likely become fixed in an upcoming version - Werk 20183