Hi Michael, I'm certainly the least expert in this case - I was just trying to help mapping that other case I have seen.
Your ouput tells (me oO) that your resolvd talks to: 1. a link scope DNS 192.168.2.254 on wlp4s0 2. is set up to talk to a gloabl dns at 127.0.0.1 IIRC it will ask both and whoever answers first is the reply it gives (can be bad at times if the nack of server A is faster than the detail from server B). On 127.0.0.53 that is resolvd itself listening. The libvirt dnsmasq usually has "except-interface=lo" so it should not listen on 127.0.0.1. The case I mentioned in c#25 was a manual config change that made resolved call the dnsmasq causing the loop. I agree that you can't easily derive if you are "looped" now from the output you have. Maybe you could check in your case if/who does listen on 127.0.0.1:53? $ sudo netstat -ltaupn | sed -rne 2p -e '/:53\b/p' Does libvirt know the pid of the dnsmasq it spawned, maybe this can be used to make this check more find grained? Like "is any of our pids binding :53 on something in systemd-resolved --status" maybe. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1670959 Title: systemd-resolved using 100% CPU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1670959/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
