I have a Windows agent installed on a host, where an other application is installed, that uses python as well. Unfortunately it has set the global $PYTHONHOME to the location of it’s own pythonfolder.
This leads the checkmk agent to use the same location. When calling the agent updater I get this:
C:\Program Files (x86)\checkmk\service>check_mk_agent.exe updater
Fatal Python error: init_import_size: Failed to import the site module
Python runtime state: initialized
Traceback (most recent call last):
File "C:\<The other application>\apps\Python39\lib\site.py", line 73, in <module>
import os
File "C:\<The other application>\apps\Python39\lib\os.py", line 29, in <module>
from _collections_abc import _check_methods
File "C:\<The other application>\apps\Python39\lib\_collections_abc.py", line 12, in <module>
GenericAlias = type(list[int])
TypeError: 'type' object is not subscriptable
which seems to fit my problem, but unfortunately I’m not a windows expert and therefore I did not understand it completely. Unsetting the global PYTHONHOME path is not an option, since I don’t know if this causes a conflict with the other application.
Is there a way to set (or unset) the PYTHONHOME path only for the checkmk agent? And if so, how do I configure this in the bakery to make it permanent?
I would recommend issuing a suport case to Tribe for this. We have the same problem. This is mainly a problem for CEE as the agent registration and bakery (who are in the agent) calls python scripts.
The whole python installation is also broken as it contains dll files that will never be needed.
The Python installation is a part of the original Python installation plus CRT Runtime.
Python installation is required to run tribe python scripts(or custom in most cases).
CRT runtime(DLLs) is mandatory for some special cases, like not updated Windows, older Windows, Windows without Service Pack, whatever.
Python installation isn’t broken, of course, it works pretty well
You should not set PYTHONHOME normally. This is just dangerous and usually useless. There are still few exceptions, for example, embedded systems. Or very special systems.
Yes, you are right, if you really need a PYTHONHOME, please, create a corresponding ticket and I will find a solution. I know about this problem.
As I am not a Windows admin, do you have any (offical) links to why this is dangerous (or useless). When I confront my Windows admins with this matter, this will probably be their first question.
As already said, I need a ticket and I will find an appropriate solution ASAP.
There are a lot of information about PYTHONHOME on the Internet. And best practice is to AVOID setting of this environment variable. Yes, you are allowed to set PYTHONHOME, as for example, it is allowed to edit Firewall rules, edit PATH variable, edit registry and so on, but do not expect that after editing some packages may be broken.
You don’t have to set either of them.
For most installations, you should not set these variables since they are not needed for Python to run. Python knows where to find its standard library.
The only reason to set PYTHONPATH is to maintain directories of custom Python libraries that you do not want to install in the global default location (i.e., the site-packages directory).
Warning: Do not use the PYTHONHOME environment variable. If it is set on your system, remove it following the guidelines below. It is extremely fragile, and if you know enough to use it safely, then you know much more than enough to need this article. Its purpose, quickly swapping among Python installations, is almost always better accomplished by modifying the PATH environment variable or by directly referencing the desired Python executable.
so this works and I can even deploy this file via the bakery. Thank you.
Just as a note: You might have to adapt the paths in the content file - in my case it’s (usually) “python-3.8” instead of “python-3”
Any reason why CheckMK needs Sqllite (Tribe hates databases we all know) There are also three different versions of pip (and not sure why the agent needs that anyways)
We as tribe do not need _sqllite. As it was said, all mentioned DLLs are either part of official Python3 installation or part of potentially missing CRT for Windows. I do not know why Python3 installation need sqlite.
3 versions of pip/wheel/easy-install is a side effect of the cabbing files. Normally those files are symlinked (hard linked, whatever), but must use cab file as a container due to performance reason and cab file doesn’t support symlinks (or hard links). But you are right: we should make installation more clean, i.e. remove mess.
It’s not a big problem generally but we have vulnerability scanners running, targeting all our servers and if, for example there would be a vulnerability in sql-lite our security would ask us to immediately remove it, that we would of course do, or upgrade Python, that we could not do.
But once the agent bakery builds a new agent I assume we would get the DLL back…
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.