-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
“lxml & xmlsec libxml2 library version mismatch” error under uWSGI #320
Comments
Some debugging information: >>> import ctypes, lxml, xmlsec
>>> libxml2 = ctypes.CDLL("libxml2.so.2")
>>> ctypes.c_char_p.in_dll(libxml2, "xmlParserVersion").value
b'20913'
>>> lxml.etree.LIBXML_VERSION
(2, 12, 6)
>>> lxml.etree.LIBXML_COMPILED_VERSION
(2, 12, 6)
>>> xmlsec.get_libxml_version()
(2, 12, 6)
>>> xmlsec.get_libxml_compiled_version()
(2, 12, 6)
|
Building these libraries from source requires too much memory, and causes OOMs on a host with 4GB of RAM when still running Zulip. Building from source was enabled in `main` to work around xmlsec/python-xmlsec#320, which does not occur with the xmlsec version in the 8.x branch, as xmlsec/python-xmlsec#314 (incompatibilities with Ubuntu 20.04) causes us to pin xmlsec<1.3.14. As such, we switch back to using prebuilt wheels. The version mismatch from xmlsec/python-xmlsec#320, if real, is not new, so this exposes us to no more risk than before.
Building these libraries from source requires too much memory, and causes OOMs on a host with 4GB of RAM when still running Zulip. Building from source was enabled in `main` to work around xmlsec/python-xmlsec#320, which does not occur with the xmlsec version in the 8.x branch, as xmlsec/python-xmlsec#314 (incompatibilities with Ubuntu 20.04) causes us to pin xmlsec<1.3.14. As such, we switch back to using prebuilt wheels. The version mismatch from xmlsec/python-xmlsec#320, if real, is not new, so this exposes us to no more risk than before.
I'm getting this same error on a container that I just re-compiled and it was working fine. I use python3-saml and that's breaking with this error when I run the container. Here is the log:
Here is my Dockerfile:
And this is the requirements.txt:
I'm stuck. Any help is appreciated. Thanks |
It seems like Not sure who should be in charge of fixing this, but I suppose using [email protected] could work. |
@eliasmazur I have the same use case as you with python3-saml. Based on what @andersk said, I've restricted the package version of LXML like so
My build is working again now. |
Thanks for the help. I realized I was restricting all packages except xmlsec. I restricted to an earlier version and it now works. Looks like python3-saml was installing the latest xmlsec and that was causing the mismatch. |
In my work, we use sigxml and xmlsec. Both install lxml with binaries, causing the same error.
To resolve this, I install using the
|
Hi, we have the similiar issue can you provide us the version which u have mentioned |
For the libxml in Dockerfile: For the lxml and xmlsec in requirements.txt: Hope this helps. |
Would this mean that a new release/wheel is needed also built with [email protected]? I was very excited about being able to install binary wheels again with xmlsec 1.3.14, but it seems that a patch release of libxml broke that again? |
Trying this, the problem is not solved for us:
still produces the uwsgi startup crash, while a normal python interpreter is fine (just as reported in the initial description). I have tried uwsgi 2.0.23 and 2.0.26 so far. Making sure that |
The package is required when building lxml/xmlsec from source, but as of the latest releases, binary wheels can be installed. However, if this package is installed while uwsgi is being built/installed, this causes version mismatch problems. See xmlsec/python-xmlsec#320
Since bumping our lxml/xmlsec requirements, we can utilize the pre-built binaries and no longer have a need for the *-dev system packages. Apart from making things leaner, this also addresses the following issue in python-xmlsec: xmlsec/python-xmlsec#320
Since bumping our lxml/xmlsec requirements, we can utilize the pre-built binaries and no longer have a need for the *-dev system packages. Apart from making things leaner, this also addresses the following issue in python-xmlsec: xmlsec/python-xmlsec#320
Since bumping our lxml/xmlsec requirements, we can utilize the pre-built binaries and no longer have a need for the *-dev system packages. Apart from making things leaner, this also addresses the following issue in python-xmlsec: xmlsec/python-xmlsec#320
I came up with another workaround - compile UWSGI_PROFILE_OVERRIDE=xml=expat pip install uwsgi or UWSGI_PROFILE_OVERRIDE="ssl=false;xml=expat" pip install uwsgi Caveat: Once your |
Thanks @D3X - that was a really good steer. IF you don't need XML support at all (it looks like it's only for supporting xml configuration of uwsgi, and... who does that??), you can:
This is the route I've just taken, and everything seems fine to me. |
When uwsgi runs with xml support, it throws the following error on startup with the latest version of edx-platform: ``` xmlsec.InternalError: (-1, 'lxml & xmlsec libxml2 library version mismatch') ``` See xmlsec/python-xmlsec#320 for more details on this. Essentially, the uWSGI wheel is built against a different version of libxml2 and it causes this version mismach error when trying to load xmlsec. The xml support in uWSGI is only needed for runing with xml configuration files, which tutor does not do. Following the guidance of the above issue, I updated the `openedx` Dockerfile to no longer compile with any xml support as a part of the build. The time to build uWSGI was only slightly more than building from cache so I'm not concerned about major slowdowns in the build time for un-cached builds.
When uwsgi runs with xml support, it throws the following error on startup with the latest version of edx-platform: ``` xmlsec.InternalError: (-1, 'lxml & xmlsec libxml2 library version mismatch') ``` See xmlsec/python-xmlsec#320 for more details on this. Essentially, the uWSGI wheel is built against a different version of libxml2 and it causes this version mismach error when trying to load xmlsec. The xml support in uWSGI is only needed for runing with xml configuration files, which tutor does not do. Following the guidance of the above issue, I updated the `openedx` Dockerfile to no longer compile with any xml support as a part of the build. The time to build uWSGI was only slightly more than building from cache so I'm not concerned about major slowdowns in the build time for un-cached builds.
When uwsgi runs with xml support, it throws the following error on startup with the latest version of edx-platform: ``` xmlsec.InternalError: (-1, 'lxml & xmlsec libxml2 library version mismatch') ``` See xmlsec/python-xmlsec#320 for more details on this. Essentially, the uWSGI wheel is built against a different version of libxml2 and it causes this version mismach error when trying to load xmlsec. The xml support in uWSGI is only needed for runing with xml configuration files, which tutor does not do. Following the guidance of the above issue, I updated the `openedx` Dockerfile to no longer compile with any xml support as a part of the build. The time to build uWSGI was only slightly more than building from cache so I'm not concerned about major slowdowns in the build time for un-cached builds.
When uwsgi runs with xml support, it throws the following error on startup with the latest version of edx-platform: ``` xmlsec.InternalError: (-1, 'lxml & xmlsec libxml2 library version mismatch') ``` See xmlsec/python-xmlsec#320 for more details on this. Essentially, the uWSGI wheel is built against a different version of libxml2 and it causes this version mismach error when trying to load xmlsec. The xml support in uWSGI is only needed for runing with xml configuration files, which tutor does not do. Following the guidance of the above issue, I updated the `openedx` Dockerfile to no longer compile with any xml support as a part of the build. The time to build uWSGI was only slightly more than building from cache so I'm not concerned about major slowdowns in the build time for un-cached builds.
If libxml2-dev was installed when uWSGI was built, then importing
xmlsec
within uWSGI leads to an incorrect errorxmlsec.InternalError: (-1, 'lxml & xmlsec libxml2 library version mismatch')
. There’s no such error outside of uWSGI.(I can work around this error with
--no-binary=lxml --no-binary=xmlsec
, but that wastes a lot more CI time and shouldn’t be necessary.)Reproduction in a fresh container:
The text was updated successfully, but these errors were encountered: