Move pihole-FTL.db for ro filesystems

I run my device on a ro filesystem. Having pihole-FTL.db live in /etc/pihole is a problem. I'd suggest having its location be set via a config file. (For updates I remount the filesystem rw, update, then remount ro. Works well, the sd cards last a lot longer this way.) Currently hunting through the code to figure out how to change the location.
Thanks!

Do you have any numbers for this?
I'm asking because I run Pi-hole (along all of its development) now for more than one year on an SD card that was in almost 24/7 operation since I bought my first Raspberry (4 years ago). I haven't seen any issue with any SD card due to its age. When I saw corrupted cards, it was almost always attributable to unclean power issues on the Raspberry.

Now to your question :slight_smile:

Have you tried to move the database to the location you prefer and simply add a symlink in /etc/pihole ? I haven't tried that myself, but it is an easy thing to test. If we would move the file around, any other interface - including, but not limited to the upcoming new long-term features on the dash board - would have to be aware of the different path. I think a symlink should be able to solve that in an elegant way.

https://github.com/pi-hole/FTL/blob/master/structs.c#L18

Pulled, changed, compiled, and installed and it appears to work fine.

I haven't tried the symlink trick either for two reasons. First is the desire to resolve as close to the source as I can so, in this case, it literally is the source (hence this request). Second reason was that I wasn't sure what behaviours to expect. Since the link would be pointing to a tmp filesystem the target file would not exist after a reboot. If the program tried to remove the link it would fail (ro filesystem) but if it expected to have state in that (semi) existing file, that would also fail. I'm not an expert

Right after I posted the request I found the string I was looking for in the /usr/bin/pihole-FTL binary. I'd been looking in /etc. You mention other features using this path but I didn't find it used anywhere else on my install. Is it used for other things currently, or only for future features?

I hesitated on putting in the info about sd cards lasting longer ro because all I have is anecdotal evidence. I've seen this debated without resolution a number of times. All I have is my experience. Regardless of root cause for the filesystem being corrupted (power supply, user error, ...), moving to ro made my repeated problems of a corrupted filesystem go away. As it's in the critical path for my home's internet and any downtime is accompanied by "Dad, how come there's no internet?", "Dad, did you fix the internet yet?", "Dad, I have homework due tomorrow.", "Dad, when's the internet coming back? Mom wants to know.", I'm eager to make it as reliable as I possibly can! :slight_smile: I didn't have any sd card failures prior to the RPi becoming router (it's my router/parental control device/dhcp server/firewall/floor wax/dessert topping device). I assumed that the failures were due to dnsmasq verbose logging, but again, no evidence and no real desire to investigate. The RPi in question is ancient, with the large SD cards. I have a small stack of cards I've used and reused before going through the effort of making it work with a read-only filesystem.

Appreciate the support, the software, and the avatar.

Keith

I also still use the RPi B+, basically because Pi-hole is fine with this device and I haven't had the need to change.

We will add a long-term statistics section to the web interface (in the next release). It will query the database file directly instead of communicating with FTL.

If the database file does not exist on startup, then it will be created. FTL will never try to delete the file. Side note: You can disable the database altogether! This might be the correct approach for you, as it doesn't seem to make much sense to store a long-term database which is eventually deleted on reboot...

See MAXDBDAYS: