Note: I previously reported this issue but it was closed due to inability to reproduce at that time. The issue has now reappeared consistently, so I'm reopening it with new evidence.
WSL Version Information
WSL version: 2.5.9.0
Kernel version: 6.6.87.2-1
WSLg version: 1.0.66
MSRDC version: 1.2.6074
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26100.1742
.wslconfig Configuration
[wsl2]
networkingMode=mirrored
vmSwitch=extern
memory=48GB
autoProxy=true
guiApplications=false
vmIdleTimeout=-1
[experimental]
sparseVhd=true
autoMemoryReclaim=Disabled
Problem Description
I'm experiencing an issue where services like ollama within WSL are idled out after a period of inactivity, even though I've set vmIdleTimeout=-1 to prevent this behavior.
This issue seems to have been introduced with the WSL version 2.5.7. In previous versions, I didn't encounter this problem. The WSL process remains running, but the memory usage drops sharply from around 1.5GB (when ollama and Docker daemon are active) to approximately 700MB. This indicates that services like ollama are being terminated or suspended.
Notably, if any terminal within WSL is active, these services aren't released, strongly suggesting that this is related to an idle auto-release policy. The auto-release occurs extremely quickly, in less than a minute. While the intention of resource release is beneficial in theory, it's not acceptable when it renders essential services unavailable, especially considering vmIdleTimeout=-1 should disable such idle-time based terminations.
I've verified that this isn't a power plan issue on Windows, and other services running outside of WSL do not exhibit this behavior. It seems to be specific to services running within WSL. This disruption hinders workflows that rely on these services running continuously and requires manual intervention for restarting, which is not the expected behavior.
Very interesting this case won't repo after I exec the log collection script....I will keep alive and see what will happen
This issue happened again on my new PC. This time, WSL even shut down the SSHD service, which made it impossible for me to connect to it from my remote laptop, causing a lot of trouble. Moreover, even when I'm using the local machine, I don't want it to hang frequently. It takes a long time to enter WSL each time because it involves starting the K8s service and making connections, etc. I'd really appreciate it if you could provide a solution or more insights.
During the log collection process, I started WSL twice and then closed the terminal (cmd). Through Task Manager, I observed that the memory usage of the "VmmemWSL" process dropped from 2500MB to approximately 1490MB, leading me to conclude that it had suspended itself. At this point, the SSH service would be shut down (I have it exposed on port 32500, and I can determine whether the service is available through the connectivity of this port). Therefore, you may observe two instances of startup and suspension behavior in the logs. I hope this will be helpful.
Logs
WslLogs-2025-07-20_00-12-59.zip
/cc Hayden Barnes (@sirredbeard)
WSL Version Information
.wslconfig Configuration
Problem Description
I'm experiencing an issue where services like ollama within WSL are idled out after a period of inactivity, even though I've set
vmIdleTimeout=-1to prevent this behavior.This issue seems to have been introduced with the WSL version 2.5.7. In previous versions, I didn't encounter this problem. The WSL process remains running, but the memory usage drops sharply from around 1.5GB (when ollama and Docker daemon are active) to approximately 700MB. This indicates that services like ollama are being terminated or suspended.
Notably, if any terminal within WSL is active, these services aren't released, strongly suggesting that this is related to an idle auto-release policy. The auto-release occurs extremely quickly, in less than a minute. While the intention of resource release is beneficial in theory, it's not acceptable when it renders essential services unavailable, especially considering
vmIdleTimeout=-1should disable such idle-time based terminations.I've verified that this isn't a power plan issue on Windows, and other services running outside of WSL do not exhibit this behavior. It seems to be specific to services running within WSL. This disruption hinders workflows that rely on these services running continuously and requires manual intervention for restarting, which is not the expected behavior.
This issue happened again on my new PC. This time, WSL even shut down the SSHD service, which made it impossible for me to connect to it from my remote laptop, causing a lot of trouble. Moreover, even when I'm using the local machine, I don't want it to hang frequently. It takes a long time to enter WSL each time because it involves starting the K8s service and making connections, etc. I'd really appreciate it if you could provide a solution or more insights.
During the log collection process, I started WSL twice and then closed the terminal (cmd). Through Task Manager, I observed that the memory usage of the "VmmemWSL" process dropped from 2500MB to approximately 1490MB, leading me to conclude that it had suspended itself. At this point, the SSH service would be shut down (I have it exposed on port 32500, and I can determine whether the service is available through the connectivity of this port). Therefore, you may observe two instances of startup and suspension behavior in the logs. I hope this will be helpful.
Logs
WslLogs-2025-07-20_00-12-59.zip
/cc Hayden Barnes (@sirredbeard)