Pi-hole operating as expected as it has for months.
FTL reported offline, seems to be flapping. DNS resolution network wide is totally intermittent.
https://tricorder.pi-hole.net/7wCfjbOS/
##Notes:
This PiHole is an LXC container on Proxmox. It serves as a DHCP server for several subnets. Its separate subnet addresses are statically assigned.
From your debug log, you have a connectivity problem on the Pi-hole host platform.
*** [ DIAGNOSING ]: Networking
[✗] No IPv4 address(es) found on the ens18 interface.
[i] Default IPv4 gateway: 172.19.5.1
* Pinging 172.19.5.1...
[✗] Gateway did not respond. (https://discourse.pi-hole.net/t/why-is-a-default-gateway-important-for-pi-hole/3546)
*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✗] Failed to resolve on lo (127.0.0.1)
[✓] No IPv4 address available on ens18
[✓] No IPv4 address available on ens18.2@ens18
[✓] No IPv4 address available on ens18.3@ens18
[✓] No IPv4 address available on ens18.4@ens18
[✓] No IPv4 address available on ens18.5@ens18
[✓] No IPv4 address available on ens18.6@ens18
[✓] No IPv4 address available on ens18.20@ens18
[✓] No IPv4 address available on ens18.30@ens18
[✓] No IPv4 address available on ens18.35@ens18
[✓] No IPv4 address available on ens18.45@ens18
[✓] No IPv4 address available on ens18.50@ens18
[✓] doubleclick.com is 108.177.122.101 via a remote, public DNS server (8.8.8.8)
I'm not sure how that would be the case. Pinging that host (EDIT: From the Pi-Hole) doesn't drop packets, but does occasionally spike from ~500uS to 11ms.
That particular host is a Brocade ICX6610, and other traffic (direct IP, rather than hostname) across that switch is unaffected when DNS goes down.
I did see something in the log about the database being locked as well.
I'm thinking this might be more a database issue.
In the debug log snippet you posted, it was able to resolve doubleclick.com, despite the gateway not responding.
This could be true. Both your database look a bit "unhealthy". Your gravity.db still contains domains, but no adlist
*** [ DIAGNOSING ]: Gravity List and Database
-rw-rw-r-- 1 pihole pihole 5517312 Oct 7 11:56 /etc/pihole/gravity.db
*** [ DIAGNOSING ]: Info table
property value
-------------------- ----------------------------------------
version 14
updated 1633619248
gravity_count 91896
Last gravity run finished at: Thu 07 Oct 2021 11:07:28 AM EDT
----- First 10 Gravity Domains -----
*** [ DIAGNOSING ]: Groups
id enabled name date_added date_modified description
---- ------- -------------------------------------------------- ------------------- ------------------- --------------------------------------------------
0 1 Default 2021-03-04 11:49:37 2021-03-04 11:49:37 The default group
*** [ DIAGNOSING ]: Domainlist (0/1 = exact white-/blacklist, 2/3 = regex white-/blacklist)
*** [ DIAGNOSING ]: Clients
*** [ DIAGNOSING ]: Adlists
And Pi-hole has issues accessing pihole-FTL.db.
[2021-10-07 11:57:11.115 4193/T4199] SQLite3 message: database is locked in "SELECT name FROM network_addresses WHERE name IS NOT NULL AND ip = ?;" (5)
[2021-10-07 11:57:11.116 4193/T4199] getNameFromIP("172.19.45.58") - SQL error prepare: database is locked
[2021-10-07 12:01:08.286 4193/T4199] SQLite3 message: database is locked in "SELECT name FROM network_addresses WHERE name IS NOT NULL AND ip = ?;" (5)
[2021-10-07 12:01:08.287 4193/T4199] getNameFromIP("172.19.45.86") - SQL error prepare: database is locked
[2021-10-07 12:01:12.965 4193M] SQLite3 message: database is locked in "SELECT hwaddr FROM network WHERE id = (SELECT network_id FROM network_addresses WHERE ip = ? GROUP BY ip HAVING max(lastSeen));" (5)
[2021-10-07 12:01:12.965 4193M] getMACfromIP("172.19.3.65") - SQL error prepare: database is locked
Please check if there are database image malformated errors or simlar in /var/log/pihole-FTL.log
I didn't see any errors like that. But it doesn't matter. The uninstaller borked the entire OS (apparently, answering "Y" to remove everything, also removes utilities like ip and ifconfig)
This will still be unsolved, but a complete re-installation on a new VM solved my issue.
EDIT: I stand corrected. The same issue reappeared last night on the brand new VM. Something is locking the database and preventing FTL from starting.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.