I've been using WSL on VSCode. I've noticed recently that after closing either VSCode, or a single WSL terminal, a process called vmmem keeps using lots of RAM.

I've found how to shut it down manually in CMD or PowerShell using the following command:

wsl --shutdown

But I've been trying to find a way to make it close itself when I either close the WSL terminal or VSCode.

This problem hasn't occurred in the past, meaning it's most likely cause by a Windows update.

I've tried updating my WSL and updating my Windows version, but all my research has led to nothing so far.

Here is the current version I'm on for WSL:

Version WSL : 0.70.4.0
Version du noyau : 5.15.68.1
Version WSLg : 1.0.45
Version MSRDC : 1.2.3575
Version direct3D : 1.606.4
Version de DXCore : 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
version Windows : 10.0.22000.1098

CodePudding user response：

Yes, Vmmem is a process that runs as part of the WSL2 Virtual Machine. And yes, a wsl --shutdown will terminate the VM itself (along with any distributions running inside it).

Typically, WSL2 terminates in two stages:

• First, when there are no "interactively started processes" (foreground or background) in a WSL2 distribution, it will terminate after 15 seconds. This is currently non-configurable.

• Second, when all running WSL2 distributions have terminated, the WSL2 VM itself will shutdown after 60 seconds. This value is configurable on recent WSL2 releases on Windows 11. At this point, Vmmem should end and release its memory.

The first thing to check when Vmmem won't terminate is whether a distribution is still running. From PowerShell or CMD:

wsl -l -v
# wsl --list --verbose

If any WSL2 distributions are still in the Running state (and my guess is that one is, for you), then the WSL2 VM (and thus the Vmmem process) will also still be running.

Assuming that you are running just one distribution:

wsl -e ps axjff

If you aren't running Systemd, the only things that should be running are:

• init processes
• The ps command itself
• plan9, a fairly new process in WSL2 (starting in 0.70.0), but that won't prevent the distribution from terminating.

If you are running Systemd, then there will be a lot of additional services. However, anything started by Systemd itself (the /sbin/init) should not prevent a WSL2 distribution from terminating.

I noticed a spurious xsel in one of my (non-Systemd) releases when checking just now, but I think that was simply due to installing the Fish shell. It was, however, preventing Ubuntu from terminating, and thus preventing the WSL2 VM from shutting down.

Is anything from the VSCode "WSL server" left over for you? Or something from your development that is spawning a background process?