[wsl2] values from /etc/sysctl.conf not applied on container start

[bketelsen]

• Your Windows build number: (Type ver at a Windows Command Prompt) Microsoft Windows [Version 10.0.18922.1000]

• What you're doing and what's happening: (Copy&paste the full set of specific command-line steps necessary to reproduce the behavior, and their output. Include screen shots if that helps demonstrate the problem.)

Trying to increase max_user_watches according to vs-code instructions. Edit /etc/sysctl.conf, then apply values with sudo sysctl -p Reboot, reopen vs-code, get same error. cat /proc/sys/fs/inotify/max_user_watches --> 8192, not the 524288 value listed in sysctl.conf actually apply the sysctl values manually: sudo sysctl -p cat /proc/sys/fs/inotify/max_user_watches --> 524288

• What's wrong / what should be happening instead: some process in /init should be applying sysctl values from /etc/sysctl.conf, but that isn't happening.

• workaround: add sudo sysctl -p to .bashrc or similar. Not ideal, not guaranteed to be triggered unless a bash process is started.

[therealkenc]

This is variation everything systemd. Nothing is reading /etc/sysctl.conf. [Nothing is reading /etc/environment ref #1405 either.]

I believe SOP for now would be to stick it in .bashrc with sudors tricks (make a script and give the script full reign). Or go ballz #994. Or alt approach hypothetical open-ended #2530 flips status.

I am tentatively (really super tentatively) looking at posting something to get us by, for a while, on these. No promises. Not really fair to dupe #994 #2530 either. So, yeah.

[ed: Pulled suggestion maybe WSL2 should just have a bigger default in the kernel. Doesn't seem as great/simple an idea on the second day.]

[magneticflux-]

Ran in to this as well following the VSCode WSL setup. Slight change to the shell init script workaround: use sudo sysctl -qp to prevent it printing the set values at the start of every new shell.

[jiangbo0216]

I use sudo passwd root to enable root user , then cd /root then I create a init.sh file in /root then I sudo chown root:root init.sh and sudo chmod 755 then vim /etc/sudoers add %sudo ALL=(ALL:ALL) NOPASSWD:/root/init.sh then vim .profile add sudo /root/init.sh

the result : fail

4293

please help!!

[jiangbo0216]

I complete this with https://github.com/shayne/wsl2-hacks nice job!

[murbanowicz]

does this issue have any attention from maintainers? It's critical bug, because it makes user responsible to e.g. increase notify limits every system start which is ridiculous... To be honest its last thing which hold me from switching completely from Linux to Windows...

[Stanzilla]

@craigloewen-msft any update on this?

[wdrdres3qew5ts21]

I confirm that this is bug /etc/sysctl.conf is not apply. Also when you restart computer you also need to set the value again I had test on /etc/sysctl.conf : vm.max_map_count too.

[krojew]

Just stumbled upon this. Is anyone working on it?

[mitsos1os]

Also confirmed on Microsoft Windows [Version 10.0.19041.508] Setting vm.swappiness does not have any effect after restart. Have to manually set

[mariotoffia]

I too have the same issue - I'm running GreenGrass and it requires some settings to be applied in sysctl. Currently I've got this in a sudo script but it would be nice to have those applied when firing up the container.

[shelllee]

maybe run a powershell script when windows startup can help?

wsl bash -c "echo your_password | sudo -S sysctl -p && sysctl -a|grep vm.max_map_count && exit"

ps: use pipeline to redirect output password to sh input

[benyaminl]

maybe run a powershell script when windows startup can help?

wsl bash -c "echo your_password | sudo -S sysctl -p && sysctl -a|grep vm.max_map_count && exit"

ps: use pipeline to redirect output password to sh input

Seems not secure as password is written on shortcut and shown on powershell history

[jdhorner]

One of my containers is an elasticsearch instance, and I have the issue where I need to increase vm.max_map_count in order to get it to work properly.

I've added vm.max_map_count=262144 to /etc/sysctl.conf and then load the value with sysctl -p and the ES instance then loads properly. But once my computer is rebooted, that value, while still written, isn't loaded. Is there still no movement on this issue after two years? Are people beating it another way?

[RaulSokolova]

I tried all the approaches and non worked for me... However I was able to set it permanently like this.

1. Create a bat file for example (set_vm_max.bat)
2. Write the command inside the file "wsl -d docker-desktop sysctl -w vm.max_map_count=262144"
3. Now will have to copy the file to the startup location, press "Windows + R"
4. Type "shell:startup" and press Enter.
5. Copy the file you just created to start location.

To verify it works:

1. Reboot
2. wsl -d docker-desktop
3. cat /proc/sys/vm/max_map_count

Hope it works for you.

[shelllee]

maybe run a powershell script when windows startup can help?

wsl bash -c "echo your_password | sudo -S sysctl -p && sysctl -a|grep vm.max_map_count && exit"

ps: use pipeline to redirect output password to sh input

Seems not secure as password is written on shortcut and shown on powershell history

yean, it's not secure

[Biswa96]

Use wsl.exe -u root command to access sudo level access. No need to use sudo or password in WSL environment.

[p10tyr]

Use wsl.exe -u root command to access sudo level access. No need to use sudo or password in WSL environment.

Thank you so much for this. I did not know you can drop into the the root wsl vm like this. I dropped into the shell ran this for Elastic Search docker (or sonarqube docker) sudo sysctl -w vm.max_map_count=262144

Recreated the docker compose.. boom. working Thank you @Biswa96 !!

[NotTheDr01ds]

Quite a few people have found my solution on Stack Overflow, but for those that come across this first, I'll repost here.

There are multiple ways to automatically set kernel parameters in WSL2 when booting. IMHO, both of these are preferable to the techniques mentioned in this issue already:

• Best option: .wslconfig using kernelCommandLine

  Any kernel parameters that can be changed via /etc/sysctl.conf can be set through the .wslconfig. This file does not exist by default, so if you don't have one, you'll need to create it in your Windows user profile directory (typically C:\Users\username\.wslconfig).

  Place the following in that file:

  [wsl2]
  kernelCommandLine = sysctl.vm.max_map_count=262144

  If you have multiple parameters to modify:

  [wsl2]
  kernelCommandLine = sysctl.vm.max_map_count=262144  sysctl.fs.nr_open=2097152 sysctl.net.ipv4.ping_group_range=\"0 2147483647\"

• Option 2: Windows 11 [boot].command in /etc/wsl.conf:

  Windows 11 users can take advantage of a new WSL feature to run any command as root during the WSL distribution startup. As sudo, create or modify /etc/wsl.conf:

  [boot]
  command="sysctl -w vm.max_map_count=262144"

[NotTheDr01ds]

If any of the WSL team come across this one, I'd recommend this could be closed based on "workaround-available" (I don't think kernelCommandLine was available when this issue was originally written) and the fact that the root issue is tracked in #994.

[rlSimonLi]

• Option 2: Windows 11 [boot].command in /etc/wsl.conf: Windows 11 users can take advantage of a new WSL feature to run any command as root during the WSL distribution startup. As sudo, create or modify /etc/wsl.conf:

Interestingly, it seems that only /usr/local/bin:/usr/bin gets loaded to $PATH when WSL executes commands in /etc/wsl.conf.

# /etc/wsl.conf
[boot]
command="sysctl -V > /out 2> /out2"

# /out2
sh: line 1: sysctl: command not found

So you might need to do this instead:

[boot]
command="/usr/sbin/sysctl -w vm.max_map_count=262144"

I am not too familiar with the intricacy of how $PATH gets loaded during boot, would be great if anyone can verify and shed some light on this.

[NotTheDr01ds]

@rlSimonLi Hmm -- That's odd. It's probably safer to call it with a fully qualified path anyway, but I'm wondering why yours isn't found on the search path.

Are you using a Preview release, and if so which one? And what distribution are you using?

[rlSimonLi]

@NotTheDr01ds I am using WSL Preview from MS Store and the distro is Fedora 36 installed via Fedora Container Base roofs. I can confirm this behaviour doesn't happen with Ubuntu downloaded from MS Store. It might just be that the container base does things differently, but again I don't know how $PATH is loaded on vanilla Linux as well as WSL to investigate this further.

[magnen]

I just stumbled upon this, and it looks like systemd support is available but not enabled by default. Enabling it either in .wslconfig or wsl.conf will start systemd and apply the sysctl.conf changes.

[tusharsnx]

I just stumbled upon this, and it looks like systemd support is available but not enabled by default. Enabling it either in .wslconfig or wsl.conf will start systemd and apply the sysctl.conf changes.

This will lead to a situation where kernel parameters will depend on the distro whose /etc/sysctl.conf is applied first.