Closed sweinst closed 3 years ago
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:
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
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
After:
It seems to happen during the call to "nsenter"
Is there a way to get around this issue?