Verify that config value applied in WSL

Question

WSL configuration can be set in wsl.conf (for distro) or .wslconfig (global) based on the Advanced Settings doc. Is there a way to verify that a value has been applied?

Something like echo $propName in bash/zsh?

Answer 1

Unfortunately not via an environment variable. I'll be honest - When I first started typing this answer (an hour+ ago), I thought that might be a good idea for a feature request for the WSL team. But then I wondered if it would really be useful -- An environment variable would probably just tell you if the value was parsed, but not really if it had the intended effect. Still, if you want to suggest it, please do so, of course.

However, I'd recommend confirming via observation of the intended effect, whenever possible. I know this isn't "ideal", but, for instance:

For /etc/wsl.conf:

[automount]:

• enabled defaults to true. Setting to false would be easily observable by the lack of mounts at /mnt/c, /mnt/d, etc.

• Likewise, root is easily observable by checking to make sure the location of the C: drive mount is in this location.

• mountFsTab defaults to true. Setting it to false would be observable by the lack of any mounts in /etc/fstab, but only if /etc/fstab was populated.

• options can be seen via mount | grep drvfs, assuming that enabled is true.

[interop]:

• enabled defaults to true. If set to false, running /mnt/c/Windows/System32/notepad.exe should result in an exit code of 1. It's ironic that I found that this appears to be broken on the latest WSL releases while writing this answer. It definitely leads credence towards the possible need for a "was this setting parsed" verification as you are asking.

• appendWindowsPath defaults to true. With apologies for stating the obvious, it's simple to check after setting it to false that the Windows path is not present by echo $PATH.

[boot]:

• systemd (currently, and hopefully always) defaults to false. If set to true, a ps axjf should (at least in recent releases) show /sbin/init instead of /init. And, of course, sudo systemctl status should work.

• command is a bit more difficult. Of course, it's easy to verify that the command is being run by using a simple test like touch /root/abc, but debugging error conditions a more complicated command may require a bit of redirection gynmnastics.

[network]:

• All current settings in this section generate messages in the kernel ring buffer during startup of the distribution (at least on recent WSL releases). If you change any of them from their default value, you can verify that the setting was parsed with something like:

  dmesg | grep resolv.conf
  dmesg | grep hosts
  dmesg | grep hostname
  

  If WSL has detected the wsl.conf change, you'll see something like the following:

  [42221.879637] WSL (1) WARNING: /etc/hosts updating disabled in /etc/wsl.conf
  

  Note: It's probably better to do this after a wsl --shutdown to limit the results to those from the current boot. A sudo dmesg --clear coupled with a wsl --terminate <distro> also works.

[user]:

• Only one setting here, default, which can be confirmed after exiting and terminating the distribution via:

  wsl ~ -d <distroname> -e whoami
  

  The -d <distroname is, of course, optional for the default distribution.

For .wslconfig:

• kernel: Can typically be verified with uname -a. If you do build your own kernel, I do recommend that you change its name slightly so that you can identify it as your own in the uname results.

• swap and memory: Will be displayed by htop and other mechanisms.

• processors: Shown by lscpu

• kernelCommandLine: Shown by changes in /proc/sys values.

• swapFile: Look for the creation of the named file, of course, but I'm not quite sure how to troubleshoot the parsing if the swap disk doesn't change.

• localhostForwarding: A bit more difficult to verify reliably if you suspect that there may be an issue with your localhost forwarding. On recent WSL Preview releases (Windows 11 only, installed from the Microsoft Store), you can also enable the debugShell option in .wslconfig:

  [wsl2]
  localhostForwarding=false
  debugShell=true
  

  Issue a wsl --shutdown. When you restart WSL2, you'll get a second console window that allows you to view the virtual machine in which your distribution is running. In that console, use:

  ps axjf | grep port-tracker | grep -v grep
  

  If localhostForwarding is enabled, you should see a process running that looks something like:

  localhost --port-tracker-fd 7
  

  If localhostForwarding is disabled, the process should not be running.

• guiApplications: When true (default), /mnt/wslg will be mounted and populated. When false, /mnt/wslg will be empty or not exist. Additional debugging can be done from the debugShell mentioned above. The WSLGd daemon will only run in that VM when guiApplications=true.

• vmIdleTimeout can be observed as noted here.

• nestedVirtualization and pageReporting: I don't have a good answer for.