Restartdns flushes stats, normal?

Help
21

My family is not that big. : )

After moving the file it does not seem to be re-created:

sudo ls /etc/pihole/pihole-FTL.db                                                                                                                          
ls: cannot access '/etc/pihole/pihole-FTL.db': No such file or directory

The integrity check results:

sudo sqlite3 pihole-FTL.db "PRAGMA integrity_check"                                                                                                        
*** in database main ***
On tree page 177795 cell 0: invalid page number 177819
On tree page 177795 cell 222: invalid page number 177818
On tree page 177795 cell 221: invalid page number 177816
On tree page 177795 cell 220: invalid page number 177815
On tree page 177654 cell 0: invalid page number 177817
Error: database disk image is malformed
22

Ok, that's giving us something to work on.

First, rename the malformed db:

mv pihole-FTL.db pihole-FTL.malformed.db

Then try to recover what you can from it:

sqlite3 pihole-FTL.malformed.db ".recover" | sqlite3 pihole-FTL.db

Given the size of your db, this may take a minute or so (give and take), and it may also fail if it runs out of memory.

If it succeeds, try moving that db back to /etc/pihole/.
Restart Pi-hole and see if it works.

23

.recover somehow isn't recognized. Does the period need escaping?


sqlite3 pihole-FTL.malformed.db ".recover" | sqlite3 pihole-FTL.db
Error: unknown command or invalid arguments:  "recover". Enter ".help" for help
24

My bad - .recover is only available since SQLite 3.29.

Try the following instead:

sqlite3  pihole-FTL.malformed.db ".dump" | sqlite3  pihole-FTL.db
25

It took a tad longer (twelve minutes). The new db file has 0 bytes so I guess the recovery didn't work.

26

Bugger - the .dump method is not as clever as .recover.

Let's move back to your Pi-hole then:

pihole-FTL.db will be created once you restart pihole-FTL, give it a try.

While db corruption was likely the cause of your observation, there's still to ponder what caused that corruption in the first place.

Did you have any blackouts or powercuts lately?

Starting of file corruption without any reason could hint at your sd card nearing its EOL, or possibly at a power supply issue.

You could check your logs for recent under-voltage events by running:

grep -ni "voltage" /var/log/syslog*
27

I restarted the service and can see the database file again. There was a power issue four weeks ago. Undervoltage in general was never a problem and I actually recently moved the OS to a flash drive. I'll let it rest for the time being and will keep an eye out for anomalies.

Thank you again for your support, @Bucking_Horn and @yubiuser!

2 Likes
28

Before I forget about those IPv6 issues I mentioned:
Your debug log indicates that your Pi-hole's IPv6 has changed:

*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] 332645.r.axf8.net is  via localhost (::1)
[✗] Failed to resolve 332645.r.axf8.net via Pi-hole (fd00::1b0)
[✓] doubleclick.com is 2a00:1450:4016:801::200e via a remote, public DNS server (2001:4860:4860::8888)

Have a look at your current IPv6 addresses by running:

ip -6 address show

Feel free to post the output here if your unsure what would the best pick.

Once you decide on a current IPv6 address, make Pi-hoe aware of it by running:

pihole -r

and choose Reconfigure.

29

Thank you for not forgetting about this. This is indeed strange.

 ip -6 address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fd00::1ba/128 scope global dynamic noprefixroute
       valid_lft 47709sec preferred_lft 47709sec
    inet6 fd00::a6fb:52b3:ada0:dd07/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 7181sec preferred_lft 3581sec
    inet6 XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 4918sec preferred_lft 2218sec
    inet6 fe80::c6e0:612b:6aa3:1662/64 scope link
       valid_lft forever preferred_lft forever
30

Seems that fd00::1ba/128 has replaced your previous ULA-address fd00::1b0.
I suspect this to be either manually configured or to have been assigned via DHCPv6.

The rest have been self-assigned by your RPI, so all in all, quite normal.

Can we have a look at your network configuration?

grep -v '^#\|^$' /etc/dhcpcd.conf
31

My pihole (now) serves as DHCP server. ipv6 should be generated from the DUID:

hostname
clientid
persistent
option rapid_commit
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
option interface_mtu
require dhcp_server_identifier
slaac private
interface eth0
        static ip_address=192.168.178.25/24
        static routers=192.168.178.1
        static domain_name_servers=127.0.0.1

I could change it to use the hardware address if that helps. Or, just as before, I reconfigure pihole to point to fd00::1ba/128 and give up on searching the cause.

I also run unbind on port 5335 as upstream resolver but that shouldn't matter. Here, the only (known) issue is that a custom upstream DNS cannot be entered in IPv6 notation with #.

32

If Pi-hole is handling DHCPv6, I see no reason why you shouldn't try fd00::1ba (though I am slightly disturbed by the /128 netmask).

Since your dhcpcd.conf works with the default stable private addresses (slaac private for RFC7217 address generation), that global scope ULA may also be a good choice. RFC7217 addresses won't change their interface identifier (the last 64 bits) unless the network changes (i.e., you pick another prefix (the first 64 bits) different from fd00::) or you install your OS afresh.

As for why it changed:
Perhaps you switched your network config at some time since installation, e.g. from wlan0 to eth0?

Anways, just using either fd00:: address should be fine.
Check this after some time, though. Inavailability of Pi-hole via IPv6 may not result in your clients complaining: Due to IPv6 emphasizing auto-configuration, they may just pick another IPv6 DNS server (if available) and sneak by Pi-hole via IPv6 then.

33

I ran through the repair procedure and it picked fd00::1b0 again:

grep IP /etc/pihole/setupVars.conf
DHCP_IPv6=true
IPV4_ADDRESS=192.168.178.25/24
IPV6_ADDRESS=fd00::1b0

There is no fd00::1b0 on my network. May I change it manually?

34

Reconfigure, not Repair. :wink:

(You may get away with changing setupVars.conf and running Repair, but I never tried that)

35

I was afraid I would lose my static DHCP leases. I made a backup and chose reconfigure. It seems to have worked and the static reservations seem to be untouched. Thank you!

36

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