27 Jun 2022 12:33 PM - last edited on 28 Jun 2022 06:27 AM by MaciejNeumann
Hello Plugin Developers!,
I've recently developed a plugin (AG 1.0) that depends on another 3rd party library (pyexasol). When executing this plugin on a Linux AG with NO system-wide python installation the plugin will fail with this error:
2022-06-23 13:45:04.009 UTC ERROR [Python][14869391503175389801][][140106916681472][ThreadPoolExecutor-0_12] - [query] Traceback (most recent call last):
File "/opt/dynatrace/remotepluginmodule/plugin_deployment/custom.remote.python.exasol/dynatrace_activegate_exasol_plugin.py", line 66, in query
db = pyexasol.connect(dsn=self.connectionstring, user=self.username, password=self.password, encryption=True, fetch_dict=True, websocket_sslopt={'cert_reqs': ssl.CERT_NONE})
File "/opt/dynatrace/remotepluginmodule/plugin_deployment/custom.remote.python.exasol/pyexasol/__init__.py", line 68, in connect
return ExaConnection(**kwargs)
File "/opt/dynatrace/remotepluginmodule/plugin_deployment/custom.remote.python.exasol/pyexasol/connection.py", line 186, in __init__
self._login()
File "/opt/dynatrace/remotepluginmodule/plugin_deployment/custom.remote.python.exasol/pyexasol/connection.py", line 601, in _login
'clientOs': platform.platform(),
File "/opt/dynatrace/remotepluginmodule/agent/plugin/python3.8/platform.py", line 1206, in platform
libcname, libcversion = libc_ver(sys.executable)
File "/opt/dynatrace/remotepluginmodule/agent/plugin/python3.8/platform.py", line 193, in libc_ver
with open(executable, 'rb') as f:
IsADirectoryError: [Errno 21] Is a directory: '/opt/dynatrace/remotepluginmodule/agent/lib64'
Basically what happens is that the external library at some point calls sys.executable to get the python interpreter binary path (for whatever reason) and some python meta-information.
In case there is no python installed it seems that this call returns a path to the remoteplugin library directory and then fails with with IsADirectoryError when trying to determine the libc version.
My guess is that this has to do how the runtime is called/embedded within the remotepluginmodule. Does anyone with some knowledge around the embedded python is doing this know why this would happen and how this could be prevented?
Cheers!
Solved! Go to Solution.
27 Jun 2022 01:17 PM
Based on your stacktrace it fails in the call:
platform.platform()
and that should provide you with the platform info.
Basically, I think you can
27 Jun 2022 10:43 PM
Thanks @Julius_Loman
Overwriting the platform.platform() method is a good idea and simple enough in the plugin code.
Though I'm still eager to understand how the python interpreter is loaded by the AG so that this call is actually not possible/fails. If python can be loaded/executed that way, then it should be also safe to use something like platform.platform() or sys.executable. IMO thats something that python itself should take care of or the one (Dynatrace) that embeds python?
28 Jun 2022 07:18 AM
The python interpreter is just embedded in the oneagentremoteplugin binary. I'm not familiar with the details, but this looks like a bug in the python interpreter itself when running embedded (or bug with the version Dynatrace is using).
Please report back if the workaround with overwriting the method worked for you.
28 Jun 2022 09:50 AM
Hi @Julius_Loman ,
yes I'm now overwriting two platform methods in my own plugin code. I will make this a good practice in case my plugins include some third party library that eventually would use those:
'''
overwriting platform functions that are used by a 3rd party library
but fail on embedded python
'''
platform.platform = lambda: "Dynatrace Active Gate Plugin"
platform.python_version = lambda: "3.8.0 (embedded)"