Hide Forgot
Description of problem: After upgrade of server from F32 to F33 my network remained dead, because systemd-resolved took over the port 53 - this prevented the dnsmasq to start and serve the DHCP requests from all over the network. Version-Release number of selected component (if applicable): systemd-246.13-1.fc33.x86_64 How reproducible: On upgrade thru dnf system-upgrade Actual results: May 01 11:39:57 server systemd-resolved[1071]: Failed to emit notification about changed property CurrentDNSServer: Transport endpoint is not connected May 01 11:39:05 server systemd[1]: Failed to start DNS caching server.. May 01 11:39:05 server systemd[1]: dnsmasq.service: Failed with result 'exit-code'. May 01 11:39:05 server dnsmasq[2841]: FAILED to start up May 01 11:39:05 server dnsmasq[2841]: dnsmasq: failed to create listening socket for port 53: Address already in use May 01 11:39:05 server systemd[1]: dnsmasq.service: Control process exited, code=exited, status=2/INVALIDARGUMENT May 01 11:39:05 server dnsmasq[2841]: failed to create listening socket for port 53: Address already in use
You'll need to disable the stub listener. Please create /etc/systemd/resolved.conf.d/stub-listener.conf: [Resolve] DNSStubListener=no I'll close the bug though: it's just something that will need to be handled through an explicit configuration from the admin.
This is however a problem if you update a remote system, and whole network remains without DHCP due to that. I'd propose that this should be handled by package maintainer at last. Either the systemd-resolved should be started after a dnsmasq or similar services, or it should not be configured for start if there is another resolver already configured.
There is an unlimited number of other resolvers that may be running. There is no mechanism to ask "will there be some precess listening on port 53?". I added a section in the Change page to mention this more: https://fedoraproject.org/wiki/Changes/systemd-resolved#Local_stub_resolver_on_port_53