Windows Subsystem for Linux "Could not set timeout on TCP stream: [Errno 92] Protocol not available"
See original GitHub issuedistributed/comm/tcp.py
gives the warning “Could not set timeout on TCP stream: [Errno 92] Protocol not available” when spawning workers using Windows Subsystem for Linux as it expects “TCP_USER_TIMEOUT” to work – and it doesn’t appear to in WSL. I have created an issue over here: https://github.com/Microsoft/WSL/issues/3873 as I think this is an OS type issue, but I just wanted to bring it up over here to discuss workarounds/proper documentation. Currently it appears (though I’m having trouble confirming conclusively) that this allows worker processes to be orphaned following exceptions, and while some get cleaned up with the message "distributed.comm.tcp - WARNING - Closing dangling stream in <TCP local=tcp://127.0.0.1:46476 remote=tcp://127.0.0.1:46457>
" many others remain running after the program has terminated.
What can we do to mitigate this or how do we better document this limitation?
Host OS: Windows 10.0.17134.619 Container OS: Ubuntu 18.04.2 LTS
jwilson@M:~$ python3
Python 3.6.7 (default, Oct 22 2018, 11:32:17)
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.version()
'#523-Microsoft Mon Dec 31 17:49:00 PST 2018'
>>> import sys
>>> sys.platform
'linux'
Thanks
Issue Analytics
- State:
- Created 5 years ago
- Reactions:4
- Comments:15 (2 by maintainers)
Top GitHub Comments
That’s cool!
I’m considering upgrading to WSL 2, the only problem is that I store all my files in the Windows system, and the FAQ from Microsoft says that version 2 doesn’t have great performance across file systems.
#2802 has been closed for now, but it would be particularly awesome if the distributed scheduler could work under WSL. Unfortunately, I lack the expertise to be of much assistance. Did you manage to find a workaround @jwilson8767?