-
Notifications
You must be signed in to change notification settings - Fork 822
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
timeouts making python aiohttp requests in recent WSL2 kernel but not WSL1 or older WSL2 kernel #9565
Comments
@ntextreme3 I started experiencing similar issues two days ago as well, both using Django This issue may be related #5018 (comment) |
@ntextreme3 does updating to today's released version of WSL fix your problem? See this thread: #9508 (comment) |
Sample output using
Didn't try other Python versions. WSL used for testing:
|
Edit (in case this helps anyone)tl;dr - updating MTU fixed this for me and no longer times out. It was late when I originally resolved this1. I updated Windows and didn't realize I didn't have my VPN turned back on after restarting. After noticing that VPN was the issue, it was easier to find a fix -- as there are plenty of similar issues full of people reporting that changing the MTU resolved their issue:
Note: It still works fine for my co-worker on the older kernel even with VPN connected. I did another Current
Footnotes
|
Version
Microsoft Windows [Version 10.0.19043.2364]
WSL Version
Kernel Version
5.15.79.1-microsoft-standard-WSL2
Distro Version
Ubuntu 20.04 and 22.04
Other Software
tested in python3.8.16, 3.10.6, 3.11.1
latest aiohttp==3.8.3
Repro Steps
steps
I ran into this on Ubuntu-20.04, but just to be sure I:
aiohttp==3.8.3
in the various virtualenvsscript
minimal reproducible example
NOTE: I'm behind a corporate proxy which is why I'm using
trust_env
in the script, so I can call this likehttps_proxy=blah python issue.py
and hit public URLs for just this example -- however the real example of this that led me here is hitting internal URLs and does not use a proxy. Proxy should be irrelevant here.observations
When I run it as WSL2 with kernel
5.15.79.1-microsoft-standard-WSL2
, it hangs, consistently after the 7th result is printed 😵. Always happening on >7th looks like it's because only workers 0 and 1 ever complete and continue to pull items from the queue; and 2, 3, and 4 hang from the start and never unblock, leaving only those 3 at the end to timeout.I then had a friend test this on their [slightly] older WSL2 kernel
5.10.102.1-microsoft-standard-WSL2
, and it succeeds there.As I was starting to wonder if this was a kernel issue, I tried to see what WSL1 would give me. If I take that same brand new Ubuntu-22 and run
wsl --set-version Ubuntu-22.04 1
to convert it to WSL1, with kernel4.4.0-19041-Microsoft
, it succeeds perfectly every time; same as on my friend's older kernel.I can swap back and forth between converting that distro from WSL2 to WSL1 and back and it always consistently fails the same way in my WSL2.
I see that the wslconfig spec does include custom kernel paths, but I don't know enough about building a custom kernel to know if I was doing it right, if I would have to rebuild/reinstall Python, system libs, etc. to know if I was accurately testing the right thing. (tbh, I'm not sure if just doing
--set-version
to WSL1 is an accurate test in that respect either 😅).Expected Behavior
This script should succeed and not hang or timeout.
expected output
Actual Behavior
output from a failing run
If I take out the timeout and just let it hang and just ctrl+C out of it, I get:
If I check strace, at the time when it's hanging it's on
epoll_wait
Diagnostic Logs
No response
The text was updated successfully, but these errors were encountered: