-
-
Notifications
You must be signed in to change notification settings - Fork 30.4k
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
platform module functions execute for a long time if user has no permissions to WMI #112278
Comments
It's very hard to work around this or avoid the delay. Even if you do not use |
As an example, merely importing aiohttp or SQLAlchemy in a session over SSH on Windows Server 2019 using Python 3.12:
cc @zooba as the original author |
bumping this, it is a serious issue in my project |
I think we can replace the
Then I think we should set the timeout for the connection to WMI. But https://learn.microsoft.com/en-us/windows/win32/api/wbemcli/nf-wbemcli-iwbemlocator-connectserver said that the timeout can only be set to "2 minutes or less" and there seems to no other way to set it to a custom value. So using a |
This should be backported to 3.12 as well, but they're right in the middle of getting 3.12.1 ready and I don't think this is that urgent. Monkeypatch |
Thank you for fixing this! For 3.12.1 we will use the runtime hooks feature from pyinstaller to override the |
The timeout is too short - I'm getting failures on some of my test machines. It wouldn't surprise me if it's due to them being slower, and so COM takes longer to load and initialize on its first use. We can either make the timeout longer (I'd suggest 1 second), or add a second event that sets just before the connection attempt. That way we can wait for everything to load with a long timeout, but only wait for the connection with a short timeout. |
Increasing the timeout to 1 second will lead to |
Thanks for the PR! That makes the backport a bit more complicated, but I think once we've seen it's stable in 3.13 then we can just backport the entire file - nothing else should've changed here for 3.13. |
We still have timeouts occurring in test runs where they previously passed. Probably just need to add a sleep and a retry in the tests, since it ought to pass. If we add a test configuration where it shouldn't, then we can skip the entire test. |
If the tests timeout in the tests, I think it should also timeout in users' code. Can we just increase the timeout for |
Increasing the timeout doesn't bother me, but no guarantee that it'll actually fix it. We can't tell right now whether it's slow to initialise or slow to connect (having separate error messages might help there too, but it'll make the code way more complicated). |
Got it, added retry and sleep in the WMI tests. |
…m connection timeout (pythonGH-112878)
If the fix in #117818 reduces/fixes the occasional errors we've been getting in CI, then I'll consider this issue complete and close it. Reviews/manual testing appreciated. |
…m connection timeout (pythonGH-112878)
Bug report
Bug description:
From Python 3.12, probably since #89545 was implemented, the invocation of functions from
platform
modules takes a multiple of 5 seconds if the user has no permissions to perform WMI queries. It can be reproduced by connecting to a Windows machine using SSH and executing a Python script from cmd or ps. Access to WMI for remote sessions is turned off by default but this probably can be achieved also by removing permissions usingwmimgmt.msc
application.For example, the execution of the
system
function in Python 3.12:and the same in Python 3.11:
(
timeit
used with-n 1 -r 1
to avoid using cache in the platform module. When results get cached then of course it works fast).The delay comes from de33df2#diff-cb1ba6039236dca71c97ea898f2798c60262c30614192862259889f839e4d503R323 which takes 5 seconds and raises
OSError
:[WinError -2147217405] Windows Error 0x80041003
.platform.system
apparently calls it twice. This applies to all functions from the module that makes WMI queries.Windows version used for tests:
Edition: Windows Server 2016 Standard
Version: 1607
OS Build: 14393.6452
CPython versions tested on:
3.12
Operating systems tested on:
Windows
Linked PRs
The text was updated successfully, but these errors were encountered: