Pi-Hole stops responding on LAN

I setup my first Pi-hole about 6 months ago. Every few days it freezes up, not responding when I ping it, and I have to reboot it. I've tried moving the card into another Pi Zero in the past, but it made no difference. I thought that maybe something was bad on the SD card, so this week I took a brand new card, installed a fresh copy of Raspberry Pi OS, installed a fresh copy of Pi-Hole, restored my Pi-Hole config to it, and I'm still having the issue where it randomly stops responding on the network, every few days. Can someone help me try to figure out what my issue is? Debug token is below. Thank you!

https://tricorder.pi-hole.net/VfJdEV5W/

I forgot to mention that I do have any power saving options turned off in the pi. Plus the connection is hardwired network.

I don't find a debug log with this token. Please generate a new log and token. Thanks.

Here's a new one. Thank you!

https://tricorder.pi-hole.net/wNoIYtPs/

Your debug log is normal. Take a look through the system logs for the last few days:

/var/log/syslog (and the .1 and other suffixes) for errors. Also look at the output of the following command from the Pi terminal:

dmesg

It it possible it stops working after a link flap, ex. router restart? I've noticed dhcpcd (which is used to configure interfaces by default, even with static ip's) removed ip address configuration on link down but never seem to get the link up even after that, leaving the interface unconfigured. I couldn't even find a way to not have dhcpcd unconfigure the interface.

I haven't played with it recently, so if there was a bug with the options I tried maybe it's fixed now, else you may want to use another way of configuring your interfaces. For me the fix was just put it besides a switch that never goes down.

There doesn't seem to be any network issues happening when it goes out. All my equipment is on a UPS to avoid power blips restarting the rack. Everything else continues to function fine when pihole is down. I don't have DHCP enabled in pihole, that's handled by my domain controller. When I have a monitor hooked up to the pi when this happens, the screen is just blank. So it seems like the whole device is just dropping out. It's just strange because I've swapped out all the hardware, did fresh installs of the OS and Pihole. The only "old" thing brought over was the config that I imported, so I'm guessing it has to be something in there.

I looked through the logs and nothing stands out as being wrong, so the next time it fails as soon as it comes back up I'll look at the logs and see what the last entries in it were before it went down.

When I do the dmesg these lines are coming up in red.

24.306540] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio f                                                        or chip BCM43430/1
[   24.309983] usbcore: registered new interface driver brcmfmac
[   24.672790] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio f                                                        or chip BCM43430/1
[   24.673122] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio f                                                        or chip BCM43430/1
[   24.673344] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2                                                        ), device may have limited channels available
[   24.674909] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Oct 22                                                         2019 01:59:28 version 7.45.98.94 (r723000 CY) FWID 01-3b33decd

not suggesting this will help (or provide any info) but my main pi-hole (pi 3 running raspbian buster) was doing the very same last week. happened for 6 days on the trot. no SSH connection, no pi-hole but responded to ping. i restarted it manually each day and it was fine until 7am the following day.
updates are installed every couple of days manually.
as of 3 days ago it hasn't stopped responding at all and pi-hole functions as it should.
i had too much on to scrutinise the logs for info at the time.
again, no info here really but i was following the thread (as i had a similar issue) and thought i'd chime in.

It's been I think 6 days and it hasn't gone down yet. I haven't change anything, so it's kind of strange. This is the longest it's ever gone without hanging up. Keeping an eye on it, and if it does happen again I'll look into those logs.

1 Like

I spoke too soon. It just went down tonight again. I'm still getting the same errors in the dmesg log as I listed above. The last entries in the syslog file before it dropped were:

Nov 16 20:17:42 pihole systemd[1]: systemd-rfkill.service: Succeeded.
Nov 16 20:17:43 pihole systemd[476]: gpgconf: running /usr/bin/gpg-agent failed (exitcode=2): General error
Nov 16 20:17:43 pihole systemd[476]: gpgconf: fatal error (exit status 1)
Nov 16 20:17:43 pihole vncserver-x11[417,root]: ConsoleDisplay: Found running X server (pid=489, binary=/usr/lib/xorg/Xorg)
Nov 16 20:17:43 pihole systemd[1]: Started Disk Manager.
Nov 16 20:17:43 pihole udisksd[320]: Acquired the name org.freedesktop.UDisks2 on the system message bus
Nov 16 20:17:44 pihole dbus-daemon[270]: [system] Successfully activated service 'org.freedesktop.hostname1'
Nov 16 20:17:44 pihole systemd[1]: Started Hostname Service.
Nov 16 20:17:45 pihole systemd[476]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
Nov 16 20:17:45 pihole systemd[476]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
Nov 16 20:17:45 pihole systemd[476]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Nov 16 20:17:45 pihole systemd[476]: Reached target Paths.
Nov 16 20:17:45 pihole systemd[476]: Listening on GnuPG network certificate management daemon.
Nov 16 20:17:45 pihole systemd[476]: Reached target Timers.
Nov 16 20:17:45 pihole systemd[476]: Listening on Sound System.
Nov 16 20:17:45 pihole systemd[476]: Starting D-Bus User Message Bus Socket.
Nov 16 20:17:45 pihole systemd[476]: Listening on GnuPG cryptographic agent and passphrase cache.
Nov 16 20:17:45 pihole systemd[476]: Listening on D-Bus User Message Bus Socket.
Nov 16 20:17:45 pihole systemd[476]: Reached target Sockets.
Nov 16 20:17:45 pihole systemd[476]: Reached target Basic System.
Nov 16 20:17:45 pihole systemd[1]: Started User Manager for UID 999.
Nov 16 20:17:45 pihole systemd[476]: Reached target Default.
Nov 16 20:17:45 pihole systemd[476]: Startup finished in 4.035s.
Nov 16 20:17:45 pihole systemd[1]: Started Session c1 of user pihole.
Nov 16 20:17:48 pihole systemd[1]: Created slice User Slice of UID 1000.
Nov 16 20:17:48 pihole systemd[1]: Starting User Runtime Directory /run/user/1000...
Nov 16 20:17:48 pihole systemd[1]: Started User Runtime Directory /run/user/1000.
Nov 16 20:17:48 pihole systemd[1]: Starting User Manager for UID 1000...
Nov 16 20:17:49 pihole vncserver-x11[417,root]: AgentInitCheck: no response from agent
Nov 16 20:17:50 pihole lightdm[583]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files
Nov 16 20:17:50 pihole systemd[1]: systemd-fsckd.service: Succeeded.
Nov 16 20:17:51 pihole systemd[569]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
Nov 16 20:17:51 pihole systemd[569]: Reached target Timers.
Nov 16 20:17:51 pihole systemd[569]: Listening on GnuPG network certificate management daemon.
Nov 16 20:17:51 pihole systemd[569]: Reached target Paths.
Nov 16 20:17:51 pihole systemd[569]: Listening on GnuPG cryptographic agent and passphrase cache.
Nov 16 20:17:51 pihole systemd[569]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
Nov 16 20:17:51 pihole systemd[569]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Nov 16 20:17:51 pihole systemd[569]: Starting D-Bus User Message Bus Socket.
Nov 16 20:17:51 pihole systemd[569]: Listening on Sound System.
Nov 16 20:17:51 pihole systemd[569]: Listening on D-Bus User Message Bus Socket.
Nov 16 20:17:51 pihole systemd[569]: Reached target Sockets.
Nov 16 20:17:51 pihole systemd[569]: Reached target Basic System.
Nov 16 20:17:51 pihole systemd[1]: Started User Manager for UID 1000.
Nov 16 20:17:51 pihole systemd[569]: Reached target Default.
Nov 16 20:17:51 pihole systemd[569]: Startup finished in 2.592s.
Nov 16 20:17:51 pihole systemd[1]: Started Session 6 of user pi.
Nov 16 20:17:52 pihole systemd[1]: Started Session 4 of user pi.
Nov 16 20:17:53 pihole systemd[569]: Started D-Bus User Message Bus.
Nov 16 21:13:18 pihole systemd-timesyncd[230]: Synchronized to time server for the first time 31.28.161.68:123 (2.debian.pool.ntp.org).

Those two statements are contradictory:
Failure to ping your Zero's IP would indeed suggest a networking issue.

Since you are running Pi-hole on an RPi Zero, that makes me guess you are using an Ethernet dongle.
Did you try to verify whether that would be causing your issue?
E.g. if you check your router's list of connected devices, does your Zero still show up when you are affected by a failure?

When I have a monitor hooked up to the pi when this happens the screen is blank but there is still power running to it.

I use the same model dongle on several other pis I have running, and none of those ever go offline.

Failure to ping does not necessarily suggest it's definitely a network issue. If a Windows computer or other device freezes it won't respond to a ping.

That's a problem that would not be related to Pi-hole.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.