Pihole 6 (upgraded from v5) fails regulary seems to related to sqlite3 error

Help Community Help
1

A couple of weeks ago I did an in-place upgrade of my pihole v5 install. this was a system that has been running very stably for a very long time. Since moving to v6, it has stopped working on a regularly basis. It simply stops serving DNS requests returning connection errors and only a restart of the FTL service or the host will bring it back.

When looking into the logs. I see that the pihole5 scraper fails after too many retries, indicating that the pihole service is not responding. Subsequently,. I see a lot of SQLite3 errors:

Mar 15 23:22:09 proxydns-01 [853]: SQLite3: cannot open file at line 44994 of [873d4e274b] (14)
Mar 15 23:22:09 proxydns-01 [853]: Writing to FTL's log file failed!
Mar 15 23:22:09 proxydns-01 [853]: SQLite3: os_unix.c:44994: (9) open(/etc/pihole/pihole-FTL.db-wal) -  (14)
Mar 15 23:22:09 proxydns-01 [853]: Writing to FTL's log file failed!
Mar 15 23:22:09 proxydns-01 [853]: SQLite3: unable to open database file in "DELETE FROM network_addresses WHERE lastSeen < 1734214929;" (14)
Mar 15 23:22:09 proxydns-01 [853]: Writing to FTL's log file failed!

The Pihole log shows a lot of network and REFUSED error:

Mar 16 06:36:16 dnsmasq[853]: query[A] grocy.dollerup.live from 192.168.0.11
Mar 16 06:36:16 dnsmasq[853]: config error is REFUSED (EDE: network error)
Mar 16 06:36:16 dnsmasq[853]: query[A] links.dollerup.me from 192.168.0.11
Mar 16 06:36:16 dnsmasq[853]: config error is REFUSED (EDE: network error)
Mar 16 06:36:16 dnsmasq[853]: query[AAAA] links.dollerup.me from 192.168.0.11
Mar 16 06:36:16 dnsmasq[853]: config error is REFUSED (EDE: network error)
Mar 16 06:36:16 dnsmasq[853]: query[A] connectivitycheck.gstatic.com from 192.168.0.124
Mar 16 06:36:16 dnsmasq[853]: config error is REFUSED (EDE: network error)
Mar 16 06:36:16 dnsmasq[853]: query[A] connectivitycheck.gstatic.com from 192.168.0.124
Mar 16 06:36:16 dnsmasq[853]: config error is REFUSED (EDE: network error)
Mar 16 06:36:16 dnsmasq[853]: query[A] connectivitycheck.gstatic.com.dollerup.local from 192.168.0.124
Mar 16 06:36:16 dnsmasq[853]: config connectivitycheck.gstatic.com.dollerup.local is NXDOMAIN
Mar 16 06:36:16 dnsmasq[853]: query[A] connectivitycheck.gstatic.com from 192.168.0.124
Mar 16 06:36:16 dnsmasq[853]: config error is REFUSED (EDE: network error)
Mar 16 06:36:16 dnsmasq[853]: query[A] connectivitycheck.gstatic.com from 192.168.0.124
Mar 16 06:36:16 dnsmasq[853]: config error is REFUSED (EDE: network error)

Finally the FTL-log shows network unreachable errors:

2025-03-16 13:20:08.717 CET [264060M] ERROR: Error while trying to close database: database is locked
2025-03-16 13:20:20.447 CET [264060M] WARNING: WARNING in dnsmasq core: influxdb.dollerup.local is a CNAME, not giving it to the DHCP lease of 192.168.0.94
2025-03-16 13:20:20.449 CET [264060M] WARNING: WARNING in dnsmasq core: ca-srvr-01.dollerup.local is a CNAME, not giving it to the DHCP lease of 192.168.0.74
2025-03-16 13:20:44.856 CET [264060M] WARNING: WARNING in dnsmasq core: influxdb.dollerup.local is a CNAME, not giving it to the DHCP lease of 192.168.0.94
2025-03-16 13:20:44.858 CET [264060M] WARNING: WARNING in dnsmasq core: ca-srvr-01.dollerup.local is a CNAME, not giving it to the DHCP lease of 192.168.0.74
2025-03-16 13:21:07.665 CET [264060M] WARNING: Connection error (2606:4700:4700::1111#53): failed to send UDP request (Network unreachable)
2025-03-16 13:21:08.308 CET [264060M] WARNING: WARNING in dnsmasq core: influxdb.dollerup.local is a CNAME, not giving it to the DHCP lease of 192.168.0.94
2025-03-16 13:21:08.309 CET [264060M] WARNING: WARNING in dnsmasq core: ca-srvr-01.dollerup.local is a CNAME, not giving it to the DHCP lease of 192.168.0.74
2025-03-16 13:21:32.576 CET [264060M] WARNING: WARNING in dnsmasq core: influxdb.dollerup.local is a CNAME, not giving it to the DHCP lease of 192.168.0.94
2025-03-16 13:21:32.578 CET [264060M] WARNING: WARNING in dnsmasq core: ca-srvr-01.dollerup.local is a CNAME, not giving it to the DHCP lease of 192.168.0.74
2025-03-16 13:21:53.065 CET [264060M] WARNING: WARNING in dnsmasq core: influxdb.dollerup.local is a CNAME, not giving it to the DHCP lease of 192.168.0.94
2025-03-16 13:21:53.067 CET [264060M] WARNING: WARNING in dnsmasq core: ca-srvr-01.dollerup.local is a CNAME, not giving it to the DHCP lease of 192.168.0.74
2025-03-16 13:22:07.626 CET [264060M] WARNING: Connection error (2606:4700:4700::1111#53): failed to send UDP request (Network unreachable)
2025-03-16 13:22:18.487 CET [264060M] WARNING: WARNING in dnsmasq core: influxdb.dollerup.local is a CNAME, not giving it to the DHCP lease of 192.168.0.94
2025-03-16 13:22:18.489 CET [264060M] WARNING: WARNING in dnsmasq core: ca-srvr-01.dollerup.local is a CNAME, not giving it to the DHCP lease of 192.168.0.74
2025-03-16 13:22:42.561 CET [264060M] WARNING: WARNING in dnsmasq core: influxdb.dollerup.local is a CNAME, not giving it to the DHCP lease of 192.168.0.94
2025-03-16 13:22:42.562 CET [264060M] WARNING: WARNING in dnsmasq core: ca-srvr-01.dollerup.local is a CNAME, not giving it to the DHCP lease of 192.168.0.74

There are a whole bunch of CNAME error and as far as I can tell the upgrade has messed up -DNS/CNAME names. I'm looking into.

Pihole is running a RPi5 with an SSD (using an RPI HAT with an RPI SSD).

Help would be greatly appriciated.
Here the tricorder token: https://tricorder.pi-hole.net/U6yAceOa/

2

Those are not Pi-hole messages.
They are messages generated by a process proxydnds-01.

Why would a third party process try to open Pi-hole's log files or try to write to Pi-hole's log files?

The rest of your messages are Pi-hole's.
They don't seem to be related to those third-party errors.

That would indicate that Pi-hole's configured upstream DNS servers have been inaccessible at the time of reporting, or no upstream DNS servers have been configured at all.

The following error may contribute to that observation:

Connection error (2606:4700:4700::1111#53): failed to send UDP request (Network unreachable)

(Note that these connection errors would have occurred with Pi-hole v5 as well. It's only Pi-hole v6 that has started logging them.)

Your debug log suggests your network to have link-local IPv6 connectivity only, i.e. it cannot connect to public IPv6 addresses:

*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] catschickens.com is NOERROR on lo (::1)
[✓] catschickens.com is NOERROR on eth0 (fe80::<redacted>80%eth0)
[✓] No IPv6 address available on wlan0
[✓] catschickens.com is NOERROR on br-8cf63c569d01 (fe80::<redacted>43%br-8cf63c569d01)
[✓] catschickens.com is NOERROR on br-c7d3f26d6a24 (fe80::<redacted>b5%br-c7d3f26d6a24)
[✓] catschickens.com is NOERROR on br-d46aeea2ce84 (fe80::<redacted>ad%br-d46aeea2ce84)
[✓] catschickens.com is NOERROR on docker0 (fe80::<redacted>8d%docker0)
[✓] catschickens.com is NOERROR on br-3c6a9ecda0f0 (fe80::<redacted>0b%br-3c6a9ecda0f0)
[✓] catschickens.com is NOERROR on br-6bd371ae08b5 (fe80::<redacted>39%br-6bd371ae08b5)
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (2001:4860:4860::8888)

To address those connection errors, you should remove any IPv6 addresses from your Pi-hole's Upstream DNS servers.

A device at 192.168.0.94 claims to be named influxdb when requesting a DHCP lease through Pi-hole, but Pi-hole's DHCP server cannot allow those names, as you have defined CNAME entries for it, pointing to proxydns-02 at 192.168.0.4:

   cname=influxdb.dollerup.local,proxydns-02

   [dns]
     (…)
     hosts = [
       (…)
       "192.168.0.4 proxydns-02",
       "192.168.0.4 proxydns-02.dollerup.local",

You should decide whether you want influxdb to resolve to 192.168.0.4 or to 192.168.0.94, and adjust your configuration accordingly.

Similar applies to ca-srvr-01, but in this case, you've defined a static DHCP reservation:

   cname=ca-srvr-01.dollerup.local,ca-srvr-01

   [dhcp]
     (…)
       "<MA:CR:ED:AC:TED>,192.168.0.74,ca-srvr-01",

That ca-srvr-01 CNAME seems redundant. You should consider to remove it.

I also note that you define FQDN Local DNS records for your local domain as well.
This isn't necessary, as dollerup.local is configured as your Pi-hole's dns.domain, and dns.expandHosts is enabled.

   [dns]
     (…)
     expandHosts = true ### CHANGED, default = false
     domain = "dollerup.local" ### CHANGED, default = "lan"

Note that automatic expansion doesn't apply to CNAMEs.

You should also note that .local is the TLD reserved for the mDNS protocol, and should not be used with plain DNS. Doing so may create unnecessary additional network traffic and potentially confuse you when DNS and mDNS would yield different resolution results.
Granted, that potential is lower in your case, as your search domain is longer than just .local, but you still should consider to use one of the TLDs reserved for home network usage, like .internal , .lan or .home.arpa.

3

Hi there,

Thanks a bunch for your feedback. Most of them were instantly usable. I do disagree with your first observation.

I checked with the FTL PID file and the PID noted is indeed FTL. "proxydns-01" is the name of the host :wink: And I have no other processes write to the FTL (pihole) log.

I still have SQLite errors and errors such as this:

2025-03-18 22:10:13.206 ERROR add_message(type=5, message=ca-srvr-01.dollerup.local is a CNAME, not giving it to the DHCP lease of 192.168.0.74) - SQL error step DELETE: database is locked
2025-03-18 22:10:13.206 ERROR Error while trying to close database: database is locked

I find it interesting that a "normal" error such as not given a misconfigured server a DHCP lease" would cause a database error.

4

I think you are correct.

From what file did you source those lines?

5

They came from journal, but I pulled similar lines from the FTL log from inside Pi-hole.