Please follow the below template, it will help us to help you!
Expected Behaviour:
When attempting to start pihole-FTL it should start accepting requests.
Actual Behaviour:
Feb 23 18:25:29 media1.docbill.info systemd[1]: Starting LSB: pihole-FTL daemon...
Feb 23 18:25:29 media1.docbill.info pihole-FTL[44010]: Not running
Feb 23 18:25:29 media1.docbill.info pihole-FTL[44010]: Failed to set DNS configuration: Could not activate remote peer.
Debug Token:
[✗] There was an error uploading your debug log.
Please try again or contact the Pi-hole team for assistance.
A local copy of the debug log can be found at: /var/log/pihole_debug.log
Dnsmasq was installed and configured by the pihole baseinstall.sh script. So I don't see where you get the idea it shouldn't be there. See the version_check_dnsmasq() function in base-install.sh . With 4.3.2 I didn't get this particular error. As soon as I updated to 4.3.3 I started seeing this error with a systemctl status, and the requests logged dropped to zero. Once I restarted dnsmasq manually, the requests returned to their normal rate.
We removed dnsmasq as a dependency when we first released FTL as it it now embedded into that. All the config files for dnsmasq are still in use, (in /etc/dnsmasq.d / /etc/dnsmasq.conf), but the actual application should not be running.
The install script also stops and disables the dnsmasq service:
But to reiterate, the process named dnsmasq should not be running, and it will cause conflicts with pihole-FTL
OK. So the previous version of pihole installed dnsmasq and the current disables it. The issue still remains. pihole is not accepting requests unless I start dnsmasq.
I just tried removing dnsmasq, but it is a dependency of libvirt. I already updated libvirt so when it runs dnsmasq it is not binding to the same interface.
Possibly that could be a source of error. Maybe the new version of pihole-FTL is trying to bind to all interfaces and then misreports this error as could not activate remote peer.
I wonder, then, are there files for it's configuration in /etc/dnsmasq.d? Or even within the file /etc/dnsmasq.conf? Could you please try for another debug token? thanks
The dnsmasq is a complete red herring. It turns out the traffic appears to stop when I went in to test service, because while testing I tend to connect my laptop to vpn. And it turns out 99% of my dns traffic comes from my laptop repeating queries over and over when I'm not connected to vpn.
I still don't know what the impact of "Could not activate remote peer." I think it means that pihole is using google dns instead of opendns.
Be aware that *libvirt* starts a *new* instance of `dnsmasq` for each virtual network (click for more)
This will very likely cause conflicts with Pi-hole’s dnsmasq instance if both instances try to bind the same network interface.
By default, dnsmasq will try to bind all addresses, even if configured to listen only on specific interfaces - it just discards requests from unconfigured interfaces.
To avoid such conflicts, you have to force dnsmasq to bind only the very interfaces it is listening to. You can do that via the bind-interfaces option within dnsmasq.
Whether you should apply this to libvrt’s dnsmasq or Pi-hole’s or both and what interfaces would go where will likely depend on your specfific configuration needs.
I have come across a similar issue a while ago, slightly differing by involving NetworkManager and a KVM virtual machine in addition to libvirt, but the solution may be relevant here as well - have a look at deHakkelaar's solution for Can't get pihole to work on br0 interface - #18 by deHakkelaar. EDIT: (short summary: OP did reconfigure bridge interface to static, deinstalled dnsmasq and removed left-over references to bind-interfaces.)
In addition, with regards to your error, make sure that systemd-resolved is up and running.
I just ran a cursory Google search to see what that could be. I found references to VPN/Wireguard and permissions problems on the configuration files. What are the permissions for the /etc/dnsmasq.d directory and the /etc/dnsmasq.conf file?
Always. Anything else would be like running Windows with the virus scanner, and windows defender turned off. It is never a good idea. There have been a few times when I've risked turning it off just to find out if SELinux was the problem.
Nope. That part surprised me too. But maybe the 4.3.3 version doesn't use that file?
If you run SEL enforcing then you will have to write your own policy files and configure that aspect. We intentionally do not change anything with SEL and have a large notice during installation that says SEL enforce is not supported. I think you actually have to positively confirm that the notice was read?
The configuration files are unlabeled and will not be read/write by the daemons. That's most likely why the error as pihole-FTL can not use the configurations. The remote peer error comes when you can not write to the files.
Edit: If you want to check, try labeling the *.conf's to system_u:object_r:dnsmasq_etc_t:s0, may need to make them user objects but the idea is what I'm proposing.