/etc/resolv.conf gets removed on shutdown/startup

[TotiTolvukall]

Environment

Windows build number: 21387.co_release.210518-1436 / 10.0.21387.1
Your Distribution version: Ubuntu 20.04
Your WSLg version: [Open 'Apps and Features' and check the version of 'Windows Subsystem for Linux GUI app support', e.g: 0.2.3.13]

Steps to reproduce

Create the /etc/wsl.conf containing the two magic lines:
user@host:/etc$ cat wsl.conf
[network]
generateResolvConf = false
user@host:/etc$

Make sure you have your own resolv.conf:
user@host:/etc$ sudo rm -f resolv.conf && sudo cat > resolv.conf << EOT
nameserver 1.1.1.1
nameserver 8.8.8.8
domain mydomain.com
search mydomain.com
EOT
Password:
user@host:/etc$

In CMD, do a wsl --shutdown

Start WSL Ubuntu 20.04 session again, and check for the /etc/resolv.conf.

It will be gone.

WSL logs:

The wsl logs reveal nothing about resolv.conf

Expected behavior

Expected is that MY resolv.conf is left alone. As it did in the WSL (pre-g release) version.

Actual behavior

Actually my resolv.conf is being forcefully removed - which IS making WSLg unusable until a new one has been put in place.

[spronovo]

Thanks for your report @TotiTolvukall, WSLg doesn't touch this file. This sounds like a possible recent regression in WSL core. @benhillis as fyi.

I'll move this issue to the main WSL github to get this investigated further.

[0xbadfca11]

sudo cat > resolv.conf

Suspicious command line.
Isn't this command line unsuccessful anyway?

[TotiTolvukall]

@0xbadfca11 how about at least making an attempt at understanding what's being done before commenting like that?

No, it's not unsuccessful. It's perfectly successful.

try it on a different file.

sudo rm -f filethatdidntexist && sudo cat > filethatdidntexist << EOT
I should have tried this myself before making me look smart on github
EOT

You will be asked for a password - type it in correctly and the SECOND sudo will run without a password.

But THIS is a digression. The original problem is that of resolv.conf being deleted at boot/shutdown and that is what this ticket should address, not script semantics (regardless if you do understand them or not).

[SheepReaper]

Check out #5420 (comment) See if that sequence helps

[TotiTolvukall]

@SheepReaper the problem isn't the shutdown itself (and I wouldn't have reported it unless I'd tried all kinds of WSL shutdowns - including full computer reboots). The problem is the procedure running (I suspect at start-up, not shutdown as you normally want your autogenerated resolv.conf to be generated from the current settings, not the settings when you last turned off your computer) at start-up. Without having dug into it, my gut feeling tells me;
It should be like this:

• if /etc/wsl.conf exists
• • if it contains "generateResolvConf" and it's set to "false"

• : don't do anything
  

• • else

• : delete /etc/resolv.conf
  

• : symlink to /run/resolvconfsomething
  

But is more like this

• delete /etc/resolv.conf
• if /etc/wsl.conf exists
• • if it contains "generateResolvConf" and it's set to "false"

•  : don't do anything
  

• .
• .
• .

Just a gut feeling, but it matches up to what I'm seeing.

For now, I have a /etc/resolv.conf.real which is my actual resolv.conf file, and then at EVERY reboot of my computer or fresh startup of WSL, I do "sudo ln -s /etc/resolv.conf.real /etc/resolv.conf"

[therealkenc]

[clodbrasilino]

Same issue here.

Edition	Windows 10 Pro
Version	Dev
Installed on	‎5/‎23/‎2021
OS build	21387.1
Experience	Windows 10 Feature Experience Pack 321.13101.0.3

EDIT: Linux version - Ubuntu 20.04 LTS

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Install the latest PowerShell for new features and improvements! https://aka.ms/PSWindows

PS C:\WINDOWS\system32> wsl
clod@DESKTOP-9QBVQDR:/mnt/c/WINDOWS/system32$ sudo su
[sudo] password for clod:
root@DESKTOP-9QBVQDR:/mnt/c/WINDOWS/system32# cat /etc/resolv.conf
cat: /etc/resolv.conf: No such file or directory
root@DESKTOP-9QBVQDR:/mnt/c/WINDOWS/system32# touch /etc/resolv.conf
root@DESKTOP-9QBVQDR:/mnt/c/WINDOWS/system32# echo 'nameserver 1.1.1.1' > /etc/resolv.conf
root@DESKTOP-9QBVQDR:/mnt/c/WINDOWS/system32# cat /etc/resolv.conf
nameserver 1.1.1.1
root@DESKTOP-9QBVQDR:/mnt/c/WINDOWS/system32# cat /etc/wsl.conf
[network]
generateResolvConf = false
root@DESKTOP-9QBVQDR:/mnt/c/WINDOWS/system32# exit
exit
clod@DESKTOP-9QBVQDR:/mnt/c/WINDOWS/system32$ exit
logout
PS C:\WINDOWS\system32> wsl --shutdown
PS C:\WINDOWS\system32> wsl
clod@DESKTOP-9QBVQDR:/mnt/c/WINDOWS/system32$ sudo cat /etc/resolv.conf
[sudo] password for clod:
cat: /etc/resolv.conf: No such file or directory
clod@DESKTOP-9QBVQDR:/mnt/c/WINDOWS/system32$

[wjzhou]

I got the same result.

a working workaround for now:
sudo chattr +i /etc/resolv.conf

Full configuration:

# add config to /etc/wsl.conf
# or manually edit if you have other config in wsl.conf
sudo tee /etc/wsl.conf << EOF
[network]
generateResolvConf = false
EOF
# some document says need restart the wsl once for the configure to work
# for me, it works without it, keep it here for reference
# run in windows command
# wsl --shutdown

# /etc/resolv.conf is a symbol link, delete it to create a regular file
sudo rm /etc/resolv.conf
sudo tee /etc/resolv.conf << EOF
nameserver 8.8.8.8
nameserver 8.8.4.4
# search local
EOF

# this is the real bug in wsl GUI version reported here
# for some reason it always delete the /etc/resolv.conf when generateResolvConf = false
# this +i will prevent delete of the file
# to edit the file again please use
# sudo chattr -i /etc/resolv.conf
sudo chattr +i /etc/resolv.conf

The real bug here is that the /etc/resolv.conf file got deleted when generateResolvConf = false. (without creating new file)
So (my guess), there is a delete statement that deletes blinding without checking the generateResolvConf = false option.

But despite the current bug, I still think this whole process needs some design, at least more clear document in /etc/resolv.conf

1. need to /etc/wsl.conf, the document is clear, so it's ok
2. some document says need to wsl --shutdown for the option to take effect
3. need to rm /etc/resolv.conf to remove the symbol link, this step is very easy to forget

[ajfpay]

I got the same result.

a working workaround for now:
sudo chattr +i /etc/resolv.conf

Full configuration:

# add config to /etc/wsl.conf
# or manually edit if you have other config in wsl.conf
sudo tee /etc/wsl.conf << EOF
[network]
generateResolvConf = false
EOF
# some document says need restart the wsl once for the configure to work
# for me, it works without it, keep it here for reference
# run in windows command
# wsl --shutdown

# /etc/resolv.conf is a symbol link, delete it to create a regular file
sudo rm /etc/resolv.conf
sudo tee /etc/resolv.conf << EOF
nameserver 8.8.8.8
nameserver 8.8.4.4
# search local
EOF

# this is the real bug in wsl GUI version reported here
# for some reason it always delete the /etc/resolv.conf when generateResolvConf = false
# this +i will prevent delete of the file
# to edit the file again please use
# sudo chattr -i /etc/resolv.conf
sudo chattr +i /etc/resolv.conf

The real bug here is that the /etc/resolv.conf file got deleted when generateResolvConf = false. (without creating new file)
So (my guess), there is a delete statement that deletes blinding without checking the generateResolvConf = false option.

But despite the current bug, I still think this whole process needs some design, at least more clear document in /etc/resolv.conf

1. need to /etc/wsl.conf, the document is clear, so it's ok
2. some document says need to wsl --shutdown for the option to take effect
3. need to rm /etc/resolv.conf to remove the symbol link, this step is very easy to forget

Omg, this script worked, thank you very very much

[benhillis]

Typically this is happening because /etc/resolv.conf is a symlink to tmpfs. If you want to take ownership of this file, set the /etc/wsl.conf setting, and replace the /etc/resolv.conf symlink with a regular file.

[TotiTolvukall]

It would be respectful to ALL the people in this thread @benhillis to at least glance over the discussion so far before replying with an entry that has zero weight.

It has already been concluded that by disabling WSL from messing with the resolver, it removes all traces of resolv.conf - symbolic links as well as regular files. And does so repeatedly (i.e. on every startup/restart.)

Thus the issue.

[benhillis]

@TotiTolvukall - I appreciate you taking the time to file this issue, turns out there was some refactoring that introduced this issue. I'll get this sorted out.

This issue has a very common signature of a common pitfall people often run into, I apologize I got this conflated with that one.