Add the ability to change the timeout period of a WSL instance

[hrkrx]

Environment

Windows build number: Microsoft Windows [Version 10.0.21343.1000]
Your Distribution version: Ubuntu 20.04
Whether the issue is on WSL 2 and/or WSL 1: Linux version 5.4.72-microsoft-standard-WSL2 (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 SMP Wed Oct 28 23:40:43 UTC 2020

I have a linux server that provides multiple NFS network drives. As NFS performance under windows is abysmal I use wsl2 to mount the NFS drives.

Steps to reproduce

Mount any NFS drive using wsl.exe as starting point.

That is working well performance wise (which is why i am doing this, as NFS under native windows is abysmal) but the issue is whenever I mount a network drive through wsl2 it gets unmounted rather quickly after a short time of idling.

WSL logs:

Expected behavior

A mounted drive should not be unmounted except the user is specifically unmounting it.

I have solved this issue by adding a watch df -h at the end of the script, but that is in my opinion not the best solution.

Actual behavior

mounted network drives are not accessible anymore after a short time of idling and if you accidentially write to them you add a file to an empty folder which makes a remount impossible without clearing the folder.

[craigloewen-msft]

This issue is caused by the fact that after a period of idle activity, we shut down the WSL 2 VM for you. We do this to help conserve system resources and to make WSL 2 feel lightweight and transparent for users developer scenarios (AKA it starts when you need it to, is fast and shuts down when you're finished with it). WSL 2 instances aren't inherently made to be continuous file servers. I'd say that the best way to log this for the WSL team could be to change this to a feature request to change the timeout parameter for WSL 2, and we can evaluate that feature request in the future. If that seems like a path where your feedback is heard to you, then I can go ahead and do that. Thank you for filing this! :)

[hrkrx]

This issue is caused by the fact that after a period of idle activity, we shut down the WSL 2 VM for you. We do this to help conserve system resources and to make WSL 2 feel lightweight and transparent for users developer scenarios (AKA it starts when you need it to, is fast and shuts down when you're finished with it). WSL 2 instances aren't inherently made to be continuous file servers. I'd say that the best way to log this for the WSL team could be to change this to a feature request to change the timeout parameter for WSL 2, and we can evaluate that feature request in the future. If that seems like a path where your feedback is heard to you, then I can go ahead and do that. Thank you for filing this! :)

I think to being able to set the timeout as parameter for the wsl command would be absolutely acceptable!

[craigloewen-msft]

Got it! I've changed the label of this to a feature and I've edited the title so it will be clear to our team on what this item is tracking. Thank you for the feedback 😁

[Biswa96]

Doesn't vmIdleTimeout option do the trick? https://docs.microsoft.com/en-us/windows/wsl/release-notes#build-20190

[hrkrx]

Doesn't vmIdleTimeout option do the trick? https://docs.microsoft.com/en-us/windows/wsl/release-notes#build-20190

that handles the timeout for all instances instead of only one doesn't it?

[chmely]

any update on this?

[dcharlespyle]

This is annoying. I used to be able to keep WSL running. I liked having Linux applications at the ready. It was almost bare metal launch speeds. But now I have wait for services to load and the app take several seconds or more before it loads. Used to be two seconds or less. And now DNS doesn't even work anymore when trying to use systemd. Can we have the option to keep Linux running at all times if we have at least 16 GBytes of RAM? I really liked having the ability to run Windows and Linux apps simultaneously at near native speeds. Now I have to wait for everything after the Linux instance times out and shuts down.

[alexchexes]

Another use case: developing a web app on a server stack like nginx+php-fpm+postgresql locally. After switching to systemd on Debian in WSL2, it became impossible to work without keeping a terminal window with Debian open; otherwise WSL dies in 15 seconds. Very annoying. And the most annoying part is that this is not configurable. IMO, critical options like that should never be hard-coded for no good reason other than to "...make WSL 2 feel lightweight...". Some people want it and other don't.

We do this ... to make WSL 2 feel lightweight and transparent

In what universe does adding obscure hard-coded timers that work in one scenario but not in another (the timer didn't trigger for us before enabling systemd on the latest WSL2+Debian distro), and making them non-configurable, unmentioned anywhere, make things "transparent"? Are we even speaking the same language here? Sorry, just can't get how decisions like this ever make it to production.

[thegitworker]

This issue is caused by the fact that after a period of idle activity, we shut down the WSL 2 VM for you. We do this to help conserve system resources and to make WSL 2 feel lightweight and transparent for users developer scenarios (AKA it starts when you need it to, is fast and shuts down when you're finished with it). WSL 2 instances aren't inherently made to be continuous file servers. I'd say that the best way to log this for the WSL team could be to change this to a feature request to change the timeout parameter for WSL 2, and we can evaluate that feature request in the future. If that seems like a path where your feedback is heard to you, then I can go ahead and do that. Thank you for filing this! :)

It's been 4 years, any update on this from Microsoft?

I run web servers under WSL and had no issues under WSL 1 in Windows 10. After recently upgrading to Windows 11 and WSL 2 my web servers are being shutdown after 15 seconds of closing a WSL Terminal. This behaviour is unacceptable and the only workaround is to keep an extra window open which clouds up activities such as using Alt+Tab.

[alexchexes]

For anyone who's in the same situation and needs a solution (until Microsoft truly fixes it), here's a workaround I use. Add this to a .bat file (adjust the distro name as needed):

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "$p = Get-CimInstance Win32_Process | Where-Object { $_.Name -eq 'wsl.exe' -and $_.CommandLine -match '-d Debian sleep infinity' }; if (-not $p) { Start-Process -WindowStyle Hidden -FilePath wsl.exe -ArgumentList '-d','Debian','sleep','infinity' }"

Run it once to start WSL. It will keep it alive; no need to keep the terminal open.

It starts a process that keeps the WSL distro alive. The command is idempotent, meaning that if a process with those arguments is already running, it won't start another one.

And no, because of how Microsoft has done this shit, you cannot start something like that from inside WSL — you must do it specifically from Windows, as shown above.

[janosharsanyi]

Alex (@alexchexes) have you tried this .wslconfig setting? (i haven't tested it myself yet, but it sounds like it could solve this problem)

general.instanceIdleTimeout (2.5.4+)

#9401 (comment)

https://www.reddit.com/r/bashonubuntuonwindows/comments/1lj47pf/comment/n01q3w3/

[assist726]

For anyone who's in the same situation and needs a solution (until Microsoft truly fixes it), here's a workaround I use. Add this to a .bat file (adjust the distro name as needed):

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "$p = Get-CimInstance Win32_Process | Where-Object { $.Name -eq 'wsl.exe' -and $.CommandLine -match '-d Debian sleep infinity' }; if (-not $p) { Start-Process -WindowStyle Hidden -FilePath wsl.exe -ArgumentList '-d','Debian','sleep','infinity' }"
Run it once to start WSL. It will keep it alive; no need to keep the terminal open.

It starts a process that keeps the WSL distro alive. The command is idempotent, meaning that if a process with those arguments is already running, it won't start another one.

And no, because of how Microsoft has done this shit, you cannot start something like that from inside WSL — you must do it specifically from Windows, as shown above.

The Start-Process trick seems to do the job if in run it alone, however there is an error in the scripting with the -not, when $p is empty it can't run correctly

At line:1 char:141

• ... mandLine -match '-d CrowdComputed sleep infinity' }; if (-not ) { Sta ...

Missing expression after unary operator '-not'.

[alexchexes]

Janos Harsanyi (@janosharsanyi) Yep, once 2.5.4 is released (still in "Pre-release" state as of today), it should solve the issue by finally providing the desired config option. Thanks — googling led me to this issue, not #10138 or #9401 where the new feature is mentioned.