Could not activate remote peer.

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

Starting dnsmasq manually gets everything up and running. I'm not really sure what the impact of this error is.

This will temporarily reset the nameserver on the Pi to bypass Pi-Hole DNS.

sudo nano /etc/resolv.conf

edit nameserver 127.0.0.1 to nameserver 9.9.9.9 or your preferred third party DNS service, save and exit

Run pihole -d and upload the debug log

dnsmasq should not be running at the same time as pihole-FTL. dnsmasq shouldn't even be installed.

Are you running a VPN or Wireguard on the same device?

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

Same error uploading the debug log. If there is a way to upload it manually, I could try that.

libvirt uses a different config file:

/var/lib/libvirt/dnsmasq/default.conf

You can DM it to me here, or you can email it to me at adam.warner@pi-hole.net

Failing that, use something like pastebin and share the link :slight_smile:

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.

@DL6ER, you've got the best working knowledge of the dnsmasq/FTL internals, any thoughts on this one please?

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?

[briemers@briemers ~]$ ls -laZR /etc/dnsmasq.*
-rw-r--r--. 1 root dnsmasq system_u:object_r:dnsmasq_etc_t:s0 27503 Aug 28 13:41 /etc/dnsmasq.conf

/etc/dnsmasq.d:
total 16
drwxr-xr-x.   2 root dnsmasq system_u:object_r:dnsmasq_etc_t:s0  4096 Aug 28 13:41 .
drwxr-xr-x. 161 root root    system_u:object_r:etc_t:s0         12288 Feb 24 08:20 ..

My rabbit hole took me to:

systemd-resolved.service 

In that I found a vpn package that does not work unless this service is running. But installing and running this did not have any effect.

Are you SELinux enforcing?

Edit: None of the 01-pihole.conf files or anything like that in /etc/dnsmasq.d either?

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?

I ran the uninstall and install again. Not only is the 01-pihole.conf file back again, but the custom file I created has also been restored.

But pihole-FTL still reports the same error...

[root@media1 automated install]# ls -latZ /etc/dnsmasq.*
-rw-r--r--  1 root root    ?                                    24 Feb 24 14:47 /etc/dnsmasq.conf
-rw-r--r--  1 root root    ?                                    24 Feb 24 14:47 /etc/dnsmasq.conf.old

/etc/dnsmasq.d:
total 24
-rw-r--r--    1 root root    ?                                   1404 Feb 24 14:47 01-pihole.conf
drwxr-xr-x.   2 root dnsmasq system_u:object_r:dnsmasq_etc_t:s0  4096 Feb 24 14:47 .
drwxr-xr-x. 164 root root    system_u:object_r:etc_t:s0         12288 Feb 24 14:47 ..
-rw-r--r--    1 root root    ?                                     56 Feb 23 12:57 01-pihole-custom.conf

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.