-
Notifications
You must be signed in to change notification settings - Fork 821
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
The I/O operation has been aborted because of either a thread exit or an application request #5633
Comments
I'm hitting the same issue, and am on the same Windows build with WSL1. |
@bityob - Interesting, I'm able to repro this but this didn't hit in our automated testing. I'll figure out what's going on. In the meantime I'd suggest rolling back to the previous version or using WSL2. Looks like conversion is working ok. |
Ok... this issue seems to be related to when the init daemon receives a larger than expected message from our service and has to resize our buffer. You may be able to work around this by temporarily reducing the length of your windows %PATH% variable. |
Alright, I've fixed this and written a test so this kind of thing won't happen again. Sorry about the disruption this caused... I'll try to get the fix into an Insider Fast build ASAP. |
@nathpete-msft - the list issue you mention looks different. Can you file a new issue with more details, please? |
Thanks, this did solve the issue - set PATH=
C:\Windows\System32\wsl.exe or set PATH=C:\Windows\System32
wsl |
Yep. I'm definitely affected by this bug. I started shortening my %PATH%, one program path string at a time until I got down to 989 characters, including spaces (so, assuming a limit of 1024 characters or just below). Once I got it pared down to 989 characters, WSL started working again as normally. But my machine where I test preview builds also has Windows Kits, developer environments, multimedia software, diagnostics, and so forth, all of which need to be in the path to work properly. Why was WSL limited to a certain path length? Any way to work around this without shortening the path in a cmd prompt before running WSL? I have use it to run Linux software side-by-side with Windows on the fly. Haven't been able to do this since updating to Windows 10 build 20175. |
Temporary workaround I started using today is to launch terminal from PowerShell:
Alternatively, a shortcut can be created with the following:
Or, you can use:
Set the "Run:" property on the Shortcut tab to Minimized and click apply. So, until the above bug is fixed, this is what I have started doing for the time being. Similar can be done with individual Linux apps, but with the wt.exe line replaced with the path to your Linux program. Note: If you also use PowerShell through Windows Terminal, you'll also have to add the path to your PowerShell installation in addition, like this:
|
I wrote a simple python script to check the limit in my machine. In my case the limit was not always the same (805/817/878 characters). The script needs Python 3.6+ to run. import os
from subprocess import STDOUT, check_output
import platform
# Get the path to the wsl executable, it's different if python is 32bit or 64bit
# See here - https://stackoverflow.com/a/41631476
system32 = 'SysNative' if platform.architecture()[0] == '32bit' else 'System32'
wsl_command = os.path.join(os.environ['SystemRoot'], system32, 'wsl.exe')
min_num = 800
max_num = 2000
path = ""
try:
for i in range(min_num, max_num):
path = "A" * i
curr_command = f"set PATH={path} && {wsl_command} uptime"
print(f"Length of path: {len(path)}")
# Raise exception in case of error
output = check_output(curr_command, stderr=STDOUT, timeout=60, shell=True)
print(output.decode('utf8').strip())
except Exception as ex:
print(f"FAILED. Output: {ex.output.decode('utf8')}") |
I've shorten my PATH to 770 characters, but still can not start WSL with extractly same error. |
If you're running into the issue with too long of a PATH and you're using Windows Terminal, you can set up a profile with the following
If you're using VSCode, you can resolve this by using the following settings:
|
Not working for me 😢 |
The first one actually worked for me, although I applied a minor tweak to the code of the first example. This is what I put into my profile settings in Windows Terminal for use with WSL Ubuntu:
That worked and it also allows me to run Windows executables from the Linux command line. |
I've reduced the path characters to 456, I might break things in a really bad way if I keep trying to make it short and still no success. When is the next build coming out? |
Did you try the python script above to check the limit in your machine? I guess that empty path is working for you, right? |
@bityob Yes, empty path is working. The limit using the python script and lowering the minimum variable is 760-767. Unfortunately that is not true. The real limit is somewhere around 250 in my case. |
Even with PATH cleared (set PATH =), I can NOT run wsl: |
This doesn't work for you? (from cmd) |
I hope you weren't shortening your actual path environment. That could be bad for some programs. If you are doing it in the command line, however, it's only temporary for that session. So there is nothing to risk if doing it that way. |
If you actually put a space between PATH and the = sign (like you did above), that probably is why it didn't work for you. There should be no space between the words PATH and =. It should be set PATH=. |
I'm also can not run wsl even set PATH to empty. |
Could you post exactly what command line string it is that you are using to try to start and use WSL? And, where you are trying to launch WSL from? |
I've tried in many ways, such as:
And I've tried many ways to launch:
None of them works for me 😭 |
Wow. Not sure what is going on there, to be honest. But I am reasonably sure your system has more problems than just with WSL. This time, run the command |
Hi, same issue here. The set PATH= workaround works. |
Open up your Terminal settings.json file in the Run dialog:
Here is what I put into mine to workaround the problem in Windows Terminal:
Each property must be on its own line, and must end with a comma, and you must have the proper number of escape characters, as above. Okay, installed VS Code and tried out the code that was given above. I modified it to agree with my current situation. Open (or create) the following by executing the following command: Paste the following into the file to adjust WSL:
Save the file. So far, whenever I open WSL as the default Terminal in VS Code, I get the following: |
Hi, that works. "code" command is in user app data, So my path line is now like: It is indeed picky on correct formatting. You don't need comma at the end of on the last entry, but there may not be space after \bin! I tried %USERPROFILE%, that did not resolve to anything useful. |
Seems to be another issue with WSL that may or may not be related to the above. WSL isn't converting spaces in paths properly. Seeing the following in BASH:
Escaping is properly set in the path command in the settings.json file, according to VS Code and Visual Studio 2019. No errors reported but WSL truncates the path when converting it and then BASH reports "No such file or directory." |
Hmm that thing I submited above works for me: The spaces are as they should, and "code" command opens VS Code as expected. |
Things just keep getting more bizarre! Doesn't matter where I put the double ampersand operator. I still get a path that is truncated, and my code is identical to yours with the exception of the extra ones you appended to yours. But we get two different results in WSL. Really strange! So, I added spaces as Unicode escape sequences and I now see the entire path as set. |
Do you use WSL1 or WSL2? I use WSL1. |
I also am using WSL1. WSL2 is too buggy for my purposes at the moment (until they make improvements in networking interoperability).
|
@dcharlespyle that kinda sounds like a locale issue, not WSL related. Might be worth a ticket with Windows Terminal folks? |
I thought that this was a distinct possibility. However, on further tinkering around, it isn't just in Windows Terminal. I found the same issue running direct through command line using cmd, and also in PowerShell. It definitely seems to be something with WSL, and not isolated to Windows Terminal. Not quite sure how or where to narrow it down at this moment, but hoping to figure it out sooner than later. They'll probably have it fixed before I do, though. :-) |
My WSL was OK when I using Win10 Insider Preview 20170(Intel) on laptop & 20160 on my PC(AMD). But when I upgrade them to 20175 last week, WSL1 on my laptop and PC all stop working. Cause I use my laptop often, so I rollback it to win10 20170, WSL1 works again. And set path to |
That's just it, though. A lot of WSL1 users are having problems with WSL in build 20175 (including myself), but your system on that build was a special case because nothing worked with WSL, not even the workarounds that worked around the issue for everybody else. That was my point. What is working for everybody else, however, didn't work for your machine--at all. Something in 20175 breaks WSL, but in your case even more was wrong with that build on your computer. |
@dcharlespyle I'm still wondering on that unicode. Do you have beta UTF-8 setting on? Settings-Region-Additional Settings- Administrative-Change System Locale. There is a tick for beta UTF-8. Mine is off. |
|
and the locale in Ubuntu? I have |
Here is what I get:
|
I have 100% same.. I really think that this workaround might have revealed a new issue. Maybe worth a new ticket. |
I agree that this is mysterious. Another fellow who has posted here has had not one workaround work for him on build 20175. That is when my problems began, but I am holding out from rolling back this time around. I almost rolled back when I started noticing the problem with WSL on this build. |
All of the workarounds above used to work for me, but now they do not. |
I don't know how to make a poll here, but are the effected all WSL1, or is WSL2 the same thing? |
@dcharlespyle FYI, WSL2 works ok on my 20175. I just not want to use it, it doesn't make sense to me |
Unregistering (using |
I have no .vhdx file that I am aware of. Went searching for it, too, but turned up nothing. |
Use the path workaround, WSL2, or roll back to previous insider build. Fix is inbound. |
/fixed 20190. |
Environment
Steps to reproduce
Just opening the WSL (Ubuntu) after a windows update (insider build).
lxcore details logs -
lxcore-files.zip
Expected behavior
Should work
Actual behavior
Error:
The I/O operation has been aborted because of either a thread exit or an application request
The text was updated successfully, but these errors were encountered: