Please follow the below template, it will help us to help you!
Expected Behaviour:
The pihole to behave as it has done for the year I have been running it given no discernible changes recently other than keeping it up to date.
Actual Behaviour:
I've had a Pihole set up for quite a while now and have started having major issues.
I'm running:
Distro: Raspbian
Version: 10
on a Raspberry Pi 3B+
I keep the pihole software up to date, running pihole -up and pihole -g daily.
I have a Virgin Media Hub 3 and therefore have to disable the hub's DHCP and use the pihole's one instead. That's all been working fine.
The last few days when I ssh onto the pi (my ritual of running the updates which also includes apt update/upgrade) it sometimes takes a while to connect.
I followed these steps with no luck: https://jrs-s.net/2017/07/01/slow-ssh-logins/
What's worse is that when I do have a ssh connection I get infrequent periods of responsiveness. The rest of the time my inputs take a long time (up to a minute) to register. I have a second raspberry pi on my local network (not running pihole) that continues to behave fine. This includes the times when the pihole is unresponsive.
On top of this I am seeing that only some of my traffic is getting blocked. For example if I click on google add (which should take my via doubleclick and therefore get blocked) I am taken to the page without it being blocked and it is not visible on the query log.
My best (limited knowledge guess) is that not all of my traffic is going via the pihole all of a sudden, though from my router's set up nothing seems to have changed.
Running top and the like on the pihole shows nothing of concern. Only a few % of resources are being used. The pihole is the only software running on the raspberry pi.
I have tried running the repair and I have posted the debug logs below.
By default, Pi-hole is already updating its configured adlists once a week.
The only instance it would possibly make sense to update your lists more often is when you subscribe to some specific adlist that you know for sure is updated by ist maintainer regularly in a much shorter frequency.
And running unattended Pi-hole release updates via pihole -up would preclude you from necessary precautions when switching releases (e.g. backups) and may potentially ruin DNS resolution in a time when you are not around to address the issue immediately.
Your debug log looks normal.
What device resides at IP address 192.168.0.228?
Some of your observations may be explained by running pihole -r and reconfiguring to a new IP address, for clients that wouldn't have renewed their DHCP lease after that change would still try to communicate with Pi-hole's previous IP address (now not available any more).
If that were the case, your issues should subside once all of your clients have renewed their lease.
If the issue persists, please run the following commands on a client that still sees ads:
I only run pihole -up's attended, not via cron, etc. I had thought about setting it up via a cron and decided against it. Glad to hear the same thoughts on this.
192.168.0.228 is the pihole, an ip separate to the static ip of 192.168.0.18 that shows the pihole web ui.
I will definitely try changing the ip.
In the meantime the results of those lookups seem to give intermittent results:
$ nslookup pi.hole
Server: 127.0.0.53
Address: 127.0.0.53#53
** server can't find pi.hole: SERVFAIL
$ nslookup flurry.com
;; connection timed out; no servers could be reached
Your debug log shows just the latter single IP address on the eth0 interface.
How did you configure that .228 IP address?
If that's for the wlan0 interface, that may interfere with Pi-hole receiving DNS in general and correctly resolving hes-pihole in particular and/or routing packets through the correct interfaces.
Given that I am still seeing long pauses of inactivity when interacting with the raspberry pi over SSH since I have reinstalled Raspbian 10 and that I do not see this issue when plugging the same SD card into a different raspberry pi, I think the most likely cause is an issue with the pi's hardware.