Updates to wsl.conf no longer immediate

[murrahjm]

Please fill out the below information:

• Your Windows build number: (Type ver at a Windows Command Prompt)

Microsoft Windows [Version 10.0.18362.30]

• 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.)

editing wsl.conf to add this automount section for mounting the C drive with metadata support:

[automount]
options = "metadata,umask=22,fmask=11"

exit and relaunch WSL for the drive to re-mount

• What's wrong / what should be happening instead:

Drive is not remounted with new options. After an unknown period of time (~5 mins?) the change takes effect. This behaviour is seems new in windows 10 "1903". Previous build (1809 - something) the change would take effect immediately upon reload of wsl.

terminating wsl with new command wsl.exe --terminate Ubuntu causes the change to apply immediately

forcibly dismounting and re-mounting the volume with the same mount options works as well (though technicallly not reading the wsl.conf?)

cd ~
sudo umount /mnt/c
sudo mount -t drvfs C: /mnt/c -o metadata,uid=1000,gid=1000,umask=22,fmask=11
cd -

• For WSL launch issues, please collect detailed logs.

See our contributing instructions for assistance.

[benhillis]

Thanks for filing! In 1903 we made a change to keep distribuitons running for a while after your last client exits. You could have hit this in 1809, but the Windows was very small. You'd also hit this if you launched something in the background (keeping the distro alive).

Work-around is to manually terminate your distro after modifying /etc/wsl.conf using:
wsl.exe --terminate <distro_name>

[murrahjm]

that makes sense, thanks for the quick response!

[WSLUser]

we made a change to keep distribuitons running for a while after your last client exits

Could you explain the rationale behind this?

[therealkenc]

^--- I maybe can explain it. The all-singing all-dancing WSL /init acts as a daemon, both for (I think) interop and (definitely) the new post-1903 Insiders with the 9P \wsl$ server. In a more perfect world, those services would be standalone children of init. Think sshd and nfsd respectively.

Now, imagine if instead you fired up sshd and nfsd to serve the purpose. The WSL instance would never exit.

Rather than leave the instance running forever once started, the devs (apparently) opted for a timeout. Or something.

[Since I am here, I finally got around to trying out wsl.exe --terminate. On a quick look it appears to behaves like a kernel panic same as pre-17046 (Spring 2018) days, not a shutdown. This means #2066 and things like it are back if you press the --terminate button. So watch out for that. Ref #3253 which will have to fight another day.]

Chalking up by-design for lack. Terminating isn't really a work-around somuch as it is de-facto SOP. Doing this all "different" is doable, mind, but would be a big ask; the scope of which would go well beyond remounting /mnt/c with new mount options automagically when wsl.conf was edited.

[mattiasghodsian]

Execute command Restart-Service LxssManager in Powershell as admin

[benhillis]

@mattiasghodsian - wsl.exe -t distro

[CMCDragonkai]

None of this works for me.

I've updated my /etc/wsl.conf to:

[automount]
enabled = true
option = "metadata,umask=27"

Then when I run wsl.exe --terminate ubuntu, and I rerun bash, it just shows the same thing for mount.

rootfs on / type lxfs (rw,noatime)
none on /dev type tmpfs (rw,noatime,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
devpts on /dev/pts type devpts (rw,nosuid,noexec,noatime,gid=5,mode=620)
none on /run type tmpfs (rw,nosuid,noexec,noatime,mode=755)
none on /run/lock type tmpfs (rw,nosuid,nodev,noexec,noatime)
none on /run/shm type tmpfs (rw,nosuid,nodev,noatime)
none on /run/user type tmpfs (rw,nosuid,nodev,noexec,noatime,mode=755)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
cgroup on /sys/fs/cgroup type tmpfs (rw,relatime,mode=755)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,relatime,devices)
C:\ on /mnt/c type drvfs (rw,noatime,uid=1000,gid=1000,case=off)

If I try to unmount /mnt/c. It also does not work.

cmcdragonkai@polyhack-surf2:~$ sudo umount /mnt/c
umount: /mnt/c: target is busy.

So how am I supposed to get wsl.conf to activate?

I'm running on windows 1909 build. And this is on a literal fresh restart of the computer.

[CMCDragonkai]

Ok I was able to umount /mnt/c after another restart. But relaunching bash after wsl.exe --terminate ubuntu, the mount options are still not applied.

I had to do this:

sudo mount -t drvfs C: /mnt/c -o metadata,uid=1000,gid=1000,umask=027

[CMCDragonkai]

False alarm! I had a typo in option. I wish something threw an error or something though.

[PetRose]

wsl.exe --terminate <distro_name>
Hi all,
Observing the same, after a longer install sequence of Docker on my Win10 HOME edition...
However, the WSL.exe seems not to accept the switch (no blanks after dashes): --terminate
and I speculate if you mean the terminate command should be passed on to WSL2 ?
If you leave a blank after the dashes, I get this on my WIN CLI:
/bin/bash: terminate: command not found
Are you referring to a command only available in a certain distro ?
Tried also the:
wsl.exe -t
and this throws me: Invalid command line option. Which is true, if one look at the --help.

For my part I use the plain Ubuntu 18.04 LTS, and Win10 Home (constantly updated) 64bit.

Can anyone also elaborate what to specify as . The uname command only says Linux and not anything like Ubuntu.
I know its the 'bionic' stable version, but I doubt one should use this nickname.

[IanLee1521]

Would it make sense to add a note that this step is needed to the documentation on setting the mount options? https://docs.microsoft.com/en-us/windows/wsl/wsl-config#configure-per-distro-launch-settings-with-wslconf