Description of problem: I tried it on lxc f35 container, but I guess it is present on any system. Version-Release number of selected component (if applicable): systemd-249.4-2.fc35.x86_64 How reproducible: reliable Steps to Reproduce: 1. dnf install dhcpcd 2. dnf remove systemd-networkd systemd-resolved 3. systemctl enable dhcpcd 4. rm /etc/resolv.conf 5. reboot Actual results: # ls -l /etc/resolv.conf lrwxrwxrwx. 1 root root 39 lis 6 12:24 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf Expected results: # rm /etc/resolv.conf # systemctl restart dhcpcd # ls -l /etc/resolv.conf -rw-r--r--. 1 root root 160 lis 6 12:41 /etc/resolv.conf Additional info: systemd contains line, which IMHO should not be part of this package, but somewhere in systemd-resolved subpackage. I think it should be activated only when systemd-resolved service is enabled+started. # /usr/lib/tmpfiles.d/etc.conf L! /etc/resolv.conf - - - - ../run/systemd/resolve/stub-resolv.conf
Created PR 21257 [1] on systemd upstream. Avoid creation of such link if user intention is unknown. Ensure it is always present when systemd-resolved.service enabled, but leave its status to any different service otherwise. It seems such solution is more appropriate. 1. https://github.com/systemd/systemd/pull/21257
Tried with podman fedora:rawhide container. Because it prepares /etc/resolv.conf as simple file, which even cannot be removed from the container. Podman works. But it does not allow on any systemd-init enabled container to have /etc/resolv.conf missing. If network is configured in a static way outside the container, I guess resolv.conf should be prepared by any such tooling. Be it cloud-init or anything similar. Even with missing /etc/resolv.conf, container can have working name resolution. It is only required to forward its ports 127.0.0.1:53 and [::1]:53 to the host, which might run common cache for all containers. I guess such configuration is not possible without tmpfiles.d/etc.conf override.