Closed elsaco closed 1 year ago
Thanks for reporting this @elsaco. Unfortunately, this is by design: The debug shell does not interact with the service at all, and uses a named pipe channel, unlike the other shells, which track the lifetimes of their processes.
This is designed so the debug shell can always start, even of the service is completely deadlocked.
Experiencing the same issue.
Thanks for reporting this @elsaco. Unfortunately, this is by design: The debug shell does not interact with the service at all, and uses a named pipe channel, unlike the other shells, which track the lifetimes of their processes.
This is designed so the debug shell can always start, even of the service is completely deadlocked.
This does not appear to be accurate - I am uaually able to enter end exit the debug shell normally. However, lately I've started experiencing issues related to disk access. When these do happen I am unable to exit wsl cleanly (as OP). After an exit stalls, I am not able to enter the debug shell at all from a different terminal, contrary to the supposed design choice referenced above:
PS Z:\> wsl --debug-shell
... [ nothing happens further ]
Additional info;
I am able to login back into the debug shell again after shutting down and restarting wsl (expected). After this I still fail to logout from the debug shell. However, if I leave the hung terminal open, I get the following if I try to log back in from a separate one;
PS Z:\> wsl --debug-shell
All pipe instances are busy.
Error code: Wsl/DebugShell/ERROR_PIPE_BUSY
If I close the terminal holding the hung logout I am back to the state from the previous comment; namely wsl --debug-shell
returns no errors and hangs forever. Is this by design?
@sprig did you find any more information about your problem? This is the first description of the sort of problem I've been facing; an indefinite hang that seems triggered by reading a particular file. Just like you mentioned, when wsl --shutdown
, wsl --debug-shell
or really anything doesn't seem to work.
Do you happen to use mounted vhdx files? What about kernelCommandLine=vsyscall=emulate
, guiApplications=false
, autoMemoryReclaim=dropcache
, or sparseVhd=true
in your .wslconfig
? I've personally tried removing this but it never helped. I mention them in case turning on one of these are involved in the problem.
@DavidArchibald I'm not sure what you mean regarding mounted vhdx files. I did move the vhdx files that WSL uses to a different location than the default (a different disk) but was not using any of the other options that you mentioned. I don't 100% remember anymore.
In my case this seems to have also been related to docker (although I'm not sure at this point whether docker was the cause or just experiencing the same issue), and to a specific distro (ubuntu). I ended up using a different distro (Gentoo works rather well, just used a stage3 tarball to install) for some linux tools I need and generally run my code directly on windows, sans containers.
Version
Microsoft Windows [Version 10.0.22621.1105]
WSL Version
Kernel Version
5.15.83.1
Distro Version
Ubuntu 22.04
Other Software
No response
Repro Steps
Run
wsl --debug-shell
in an elevated shell. A WSL instance must be running for the command to work. Unlikewsl --system
it won't start the default distro.Expected Behavior
Exit the debug shell and return to previous shell.
Actual Behavior
Upon
exit
the debug shell just hangs until WSL is terminated:Diagnostic Logs
No response