Skip to content
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

Docker engine at resource saving mode will stick WSL for no reason #12635

Open
1 of 2 tasks
PhiliaTheCat opened this issue Feb 25, 2025 · 9 comments
Open
1 of 2 tasks

Comments

@PhiliaTheCat
Copy link

Windows Version

Microsoft Windows [Version 10.0.26100.3321]

WSL Version

2.4.11.0

Are you using WSL 1 or WSL 2?

  • WSL 2
  • WSL 1

Kernel Version

5.15.167.4-1

Distro Version

Ubuntu 24,04 and kali-linux

Other Software

Docker Desktop 4.38 (latest one I think) on bot arm64 and x86-64

Repro Steps

Install Docker Desktop with wsl2 backend and start up the engine. Give it some time for it entering saving mode.

Expected Behavior

Previous version is working well. Docker engine entering saving mode will not stick WSL instances.

Actual Behavior

WSL instances get stuck for no reason. Mitigated after docker engine exiting saving mode.

Diagnostic Logs

No logs at all.

Copy link

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use collect-networking-logs.ps1, following the instructions here

Once completed please upload the output files to this Github issue.

Click here for more info on logging
If you choose to email these logs instead of attaching to the bug, please send them to [email protected] with the number of the github issue in the subject, and in the message a link to your comment in the github issue and reply with '/emailed-logs'.

@PhiliaTheCat
Copy link
Author

Copy link

Diagnostic information
.wslconfig found
Detected appx version: 2.4.11.0

@OneBlue
Copy link
Collaborator

OneBlue commented Feb 25, 2025

What do you mean by WSL getting stuck ? Could you share /dumps of that ?

@PhiliaTheCat
Copy link
Author

PhiliaTheCat commented Feb 27, 2025

What do you mean by WSL getting stuck ? Could you share /dumps of that ?

@OneBlue Attually it means no responses. It just do not respond to any input given to it, including keyboard and sockets from host machine.

@PhiliaTheCat
Copy link
Author

https://1drv.ms/u/c/ab009846e1c541c2/EV0uU5cTQsdDoIHPP6k-IWABadXcJQ2zZFBsH4It0dtFTQ?e=IgJkn7

What do you mean by WSL getting stuck ? Could you share /dumps of that ?

Dumps are available via the link above.

@justus-camp-microsoft
Copy link
Collaborator

@PhiliaTheCat, it looks to us like the .zip file you uploaded is corrupted. Can you try uploading it again? Thank you!

@jinzhao-hust
Copy link

I encountered a similar problem, and I believe this issue is related to issue #11066. According to the information I found, you can solve it by modifying the AutoMemoryReclaim mode of WSL or by disabling the resource saving mode in Docker Desktop. However, this does not fundamentally solve the problem.

@PhiliaTheCat
Copy link
Author

@PhiliaTheCat, it looks to us like the .zip file you uploaded is corrupted. Can you try uploading it again? Thank you!

Sorry that my upload is corrupted. I have tried to give out a fine output, but it seems the shell script is not finishing correctly when the bug is triggered. It just got stuck at 100%, and stayed there for several minutes (I mean an unreasonably long time compared to other scenarios).
jinzhao-hust has mentioned a working bypass for this issue above. Also, the issue he quoted seems to be exactly the same with mine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants