vmIdleTimeout has no effect

[Seeky90]

Version

Version 10.0.22000.739

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.10.102.1

Distro Version

Ubuntu 20.04

Other Software

No response

Repro Steps

Into %userprofile%/.wslconfig add:
[wsl2] vmIdleTimeout=-1
in order to completely disable the timeout.

In Powershell run
wsl --shutdown

Start WSL by opening a Terminal.
Close the Terminal so that nothing is running.

Check the current state of the machine by running in powershell:
wsl --list --verbose

It should show STATE Running.

Expected Behavior

Check again, after for example 5 minutes.
It should show STATE Running.

Actual Behavior

Check again, after for example 5 minutes.
It shows the STATE Stopped.

Diagnostic Logs

#8642

[NotTheDr01ds]

I was thinking the same thing for most of today, but believe it or not, it appears to be working as intended. The documentation wording on this feature is accurate, but confusing:

key	value	default	notes
vmIdleTimeout	number*	60000	The number of milliseconds that a VM is idle, before it is shut down. Only available for Windows 11.

Technically, it should say "the VM", because there's only one WSL2 virtual machine running.

The confusion is that this refers to the managed VM running WSL2 itself, not the WSL2 distribution/container/instance.

There are two timers that are in play here:

• The first timer is how long a WSL instance is idle before it is terminated. Think of this as a wsl --terminate <distro> that occurs when there are no more running processes in it other than init. This is non-configurable, but Add the ability to change the timeout period of a WSL instance #6782 is a feature request for the ability to configure it. As far as I can tell, this is hard-coded at about 15 seconds.

  This has been around since shortly after WSL1 was launched 6 years ago. It occurs for both WSL1 and WSL2 instances.

• The second timer is specific to the WSL2 managed (as in, we can't see it or interact with it, for the most part) VM. This is a single shared VM, which is why I say it would be more accurate to call it *"the VM" in the docs. Even after an instance is terminated, the WSL2 VM continues to run and consume memory.

  A wsl --shutdown essentially terminates this virtual machine (and presumably some other activities).

  You can see this by looking for several processes in the task manager:

  • Vmmem: vmmem.exe
  • Virtual Machine Worker Process: vmwp.exe

  These will show up when you first run a WSL2 instance (which starts the VM) and will go away when the VM is shutdown (either via vmIdleTimeout or wsl --shutdown)

  You can also see the VM start up and shut down in the Event Viewer under Applications and Services Logs -> Microsoft -> Windows -> Hyper-V-Worker -> Admin.

  The vmIdleTimeout is specific to the VM, and that timer starts once all WSL2 distributions/instances/containers have terminated.

So once you exit the last WSL2 distribution/instance, assuming no other processes are running in the background:

• A 15 second timer starts, after which the instance itself is terminated
• Then, once the last instance is terminated, the "idle" state timer begins. 60 seconds (by default) after this, the WSL2 VM will shut down.

So setting vmIdleTimeout=-1 will simply keep the VM, but not the instance, running.

Side note: You can also watch the VM shut down if you turn on debugConsole=true.

[johnvranos]

I have two WSL2 instances installed.

wsl.exe -l -o

shows all the available to install.

So the wording about "a VM" can refer to one VM of many.

Myself have the same problem, vmIdleTimeout used to work some time ago.

I had done tests, and it was really working.

My thought is that they may have reduced the maximum value accepted by the vmIdleTimeout.

I will do some tests, in the range of the like 60000 - 180000 (60 seconds - 180 seconds), and I will post an answer here.

[NotTheDr01ds]

wsl.exe -l -o

shows all the available to install.

So the wording about "a VM" can refer to one VM of many.

Well, no. There's one WSL2 VM running at most. You can install and run multiple distributions (a.k.a. "instances") simultaneously, but they all run in the same VM. Each distribution runs in its own namespace container, similar to the way that Docker (and other) containers work.

That said, it's easy to use the wrong term. I used "VM" in a place in my answer above where it should have said "instance" (or "distribution"). I've fixed that now.

Myself have the same problem, vmIdleTimeout used to work some time ago.

I had done tests, and it was really working.

I was convinced of that as well at one point, but I finally figured out that the distribution I was running (that stayed up, even after the shell was exited) was running keychain. This is similar to tmux in that it is a user-process, started from the interactive shell. As such, once it is running, the WSL2 instance will not terminate. As a result, the WSL2 VM also will not terminate.

Any long-running process such as tmux or keychain that is started from the user's interactive shell can keep the distribution running in the background.

If you run Docker Desktop, it will also keep the distributions running using a dummy process called wslkeepalive.

[EagleJinWt]

Ehh, so, are there any way to just keep wsl instance alive, without a terminal window? I have a webserver running on it, and always having a terminal in background is kinda annoying to me.

[aki-k]

@EagleJinWt Start your WSL 2 instance like this and it'll keep on running:

wsl.exe --distribution Ubuntu-22.04 --exec dbus-launch true

Please test if it shuts down after 24 hours like somebody mentioned elsewhere.

[JavenLiPl]

So, till now, if I want to keep wsl2 instance running always, (assume that I have lots of docker container running on that, no matter there is active user session or not), the only way is to keep a user session open somewhere and ensure there will be always at least one active session?

[aki-k]

This discussion seems to have ended even though the problem remains. You can enable systemd in WSL 2 with https://github.com/DamionGans/ubuntu-wsl2-systemd-script ( for Ubuntu-22.04 you need to patch enter-systemd-namespace with this DamionGans/ubuntu-wsl2-systemd-script#36 (comment) )

After this, WSL 2 keeps on running even if you close all shells/terminals.

Edit: by default that script enables systemd target basic.target but you can change that in both enter-systemd-namespace and start-systemd-namespace

[johnvranos]

I am running Windows 11, with the WSL2 from the Microsoft Store (NOT the one from "Turn Windows features on or off").

I have enabled the systemd with /etc/wsl.conf:

[boot]
systemd=true

but the vmIdleTimeout issue remains.

[aki-k]

To me it just says that Microsoft doesn't want that users keep WSL 2 running how the users wish to run it, and impose this kind of restriction.

[johnvranos]

I just made some tests, always using wsl.exe --shutdown, after every vmIdleTimeout modification I made.

Whatever the vmIdleTimeout value, the Debian WSL2 instance was automatically stopped, 15 seconds after closing its terminal window.

I watched its status, by running:

wsl.exe -l -v

in a command prompt.

[johnvranos]

I talked with the Bing AI, and here is the last part of the discussion.

I installed the tmux package in Debian WSL2. When I ran it once, as a user (not root), and closed the terminal window, the Debian instance kept running indefinitely.

This is the solution indeed.

[aki-k]

Here's the solution without the need to run tmux:

#8659 (comment)

[NotTheDr01ds]

As noted in the README for that project, it's no longer maintained. The primary reason is that WSL now includes the ability to enable Systemd in a much more robust (but still not perfect) fashion. See my Ask Ubuntu answer on the topic for more information. I really, highly recommend against custom Systemd-enablement scripts, especially for something like this.

tmux, keychain, or other long-running user processes can fill this need much better than creating a new namespace (which is what the Systemd scripts do).

[aki-k]

The primary reason is that WSL now includes the ability to enable Systemd in a much more robust (but still not perfect) fashion.

That script does a better job than a billion dollar company can (or refuses) to do.