/etc/resolv.conf is regenerated with an invalid config
sweinst opened this issue · comments
I've installed Ubuntu 20.04 via rootfs as indicated on the ubuntu website
I've installed the script, but /etc/resolv.conf is rewritten with an invalid DNS configuration
before the call to /usr/sbin/enter-systemd-namespace
# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 172.28.144.1
After:
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 127.0.0.53
options edns0
It seems to happen during the call to "nsenter"
Is there a way to get around this issue?
That should not happen if you use the scripts as supplied here. These scripts use the basic target which does not start systemd-resolved.service. The only way you should be getting that service started is if your system is incorrectly configured to start multi-user.target instead of basic.target.
Can you list the steps you followed so that I can try to replicate in case I'm mistaken?
@diddledan I can confirm that this is not the case.
An installation of ubuntu-wsl2-systemd-script to my Ubuntu 20.04 WSL2 container does indeed start systemd-resolved.service, which in turn replaces /etc/resolv.conf with a symbolic link to SystemD's own stub resolver.
In addition, systemd-resolved is reliably started by SystemD every time the container is "booted" with SystemD.
In terms of steps, I didn't do anything more than the steps listed in this repository's ReadMe - I logged in to my Ubuntu 20.04 container, cloned the repository, and ran the install script.
However, as far as @sweinst's issue goes, this is easy to fix - simply delete the /etc/resolv.conf symbolic link that was created, and replace it with a valid /etc/resolv.conf file. It seems SystemD only replaces the file with a symbolic link once, and then never does it again. I've shut my container down and back up a good number of times now, and the /etc/resolv.conf I restored manually is still intact.
So, even though systemd-resolved is still running at all times for me, I haven't had any resolver errors after applying this fix.
If you wanted to incorporate this fix into ubuntu-wsl2-systemd-script for new users, all you'd have to do is make a backup of the current /etc/resolv.conf present in the container, then start SystemD, then stop SystemD, and finally restore the backup of /etc/resolv.conf.
I can't reproduce this. Can you please list the steps you followed to get to this state so that I can attempt to recreate the issue?
I've just reproduced the issue with the following steps:
- Create an empty directory on Windows, and download the following file into it:
https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-wsl.rootfs.tar.gz
-
Change to that directory in a Command Prompt
-
Run the following commands from the Command Prompt:
mkdir UbuntuFocalWSL
wsl --import UbuntuFocalWSL UbuntuFocalWSL focal-server-cloudimg-amd64-wsl.rootfs.tar.gz
wsl -d UbuntuFocalWSL
This will start a session in the newly created container. Next, run the next few commands in this bash prompt:
# Observe that the current resolver was generated by WSL
cat /etc/resolv.conf
# Add a non-root user with sudo privileges
adduser ubuntu
usermod -aG sudo ubuntu
# Change to a non-Windows directory
cd
# Install the SystemD script
git clone https://github.com/DamionGans/ubuntu-wsl2-systemd-script.git
cd ubuntu-wsl2-systemd-script/
bash ubuntu-wsl2-systemd-script.sh
# Shut down WSL
wsl.exe --shutdown
Finally, start the container once more, but invoke it as the non-root user so that SystemD starts. From the Windows Command Prompt:
wsl -d UbuntuFocalWSL -e bash -c "su - ubuntu"
And finally, in the new bash session you just started:
# Observe that systemd-resolved has been started
systemctl status systemd-resolved
# Observe that the current resolver has been replaced by SystemD's
cat /etc/resolv.conf
I should note that, while testing this procedure, I realized that /etc/resolv.conf appears to be mounted in the SystemD as a filesystem namespace. In the SystemD namespace this file will be a symbolic link to SystemD's resolver stub. But outside the SystemD namespace, it will appear as the standard WSL-generated file. This may be why you were unable to reproduce the issue.
Regardless, it causes issues when inside the SystemD namespace, and this procedure shows that systemd-resolved is reliably started and overriding that file.
Another reason you may have been unable to reproduce the issue is that WSL appears to temporarily override the file inside the SystemD namespace if you enter the container a second time without stopping SystemD.
For instance, the first time the container was entered, SystemD replaces /etc/resolv.conf, as the above procedure shows. But if you were to exit the bash prompt without shutting down the container, and then ran following command again:
wsl -d UbuntuFocalWSL -e bash -c "su - ubuntu"
you would see that SystemD is already running. If you then checked the file:
cat /etc/resolv.conf
you should see it is now the WSL version of the file, even though we're in the SystemD namespace. It appears that WSL replaces this files on subsequent invocations of the container after SystemD has already been started. But this is only temporary - if you shut down the container, then re-enter it and re-start SystemD, you would once again see SystemD's version of the file.
However, once you remove the symbolic link over /etc/resolv.conf while inside the SystemD namespace, then any subsequent run of SystemD seems to never touch this file again; the symbolic link is created only once, and if you remove it, SystemD does not attempt to override it anymore.
So the confusion here is caused by the fact that SystemD's replacement of the file is namespace-scoped, and that WSL appears to somehow replace the file in both namespaces.
Thanks for the detailed steps - they were very helpful! I've now reproduced the problem and found the root-cause. A PR to fix this is coming shortly.
Thanks . It's working now