Despite following instructions elsewhere when I have gotten a " Disk shortage (/etc/pihole/pihole-FTL.db) ahead: 91% used" and " Disk shortage (/var/log/pihole/FTL.log) ahead: 91% used" it seems these files take up space faster and faster.
I cleared them yesterday and now they are full. I don't think anything has changed.
I did try and search for solutions but other than manually clearing the log, I really didn't understand the solutions offered.
Aren't these logs supposed to self-reset? How would the get so big.
I have pi-hole running on Ubuntu 22 on a cheap Intel system on a chip from China. Ubuntu and Pi-hole are up to date.
I don't believe anything has changed other than updates.
I tried attaching the diagnostic output but it says the post is too long.
Run the command below. It will check your setup, check your databases, then create a debug log and automatically post it to the private secure debug server for the devs to look at. It will give you a debug token URL which you can post here – just the URL, not the whole log – and that will let them locate it.
I did see that in another post. I looked at mine and there was no entry for Max Days so I added it to 90.
#; Pi-hole FTL config file
#; Comments should start with #; to avoid issues with PHP and bash reading this file
RATE_LIMIT=1000/60
PRIVACYLEVEL=0
MAXDAYS=90
Note that MAXDBDAYS as well as log rotation do address growth by limiting the retention period. They don't impose any restrictions on absolute sizes or growth rate.
The latter is likely what is causing your issue, as your debug log seems to suggest:
*** [ DIAGNOSING ]: Pi-hole diagnosis messages
count last timestamp type message
----- ------------------- --------------- ------------------------------------------------------------
1 2022-11-19 17:00:02 DNSMASQ_WARN Maximum number of concurrent DNS queries reached (max: 150)
1 2022-11-19 17:00:02 RATE_LIMIT 192.168.1.110
Any client excessively sending resolution requests would cause Pi-hole to grow its log and long term database files accordingly, and your debug log shows that happened for your client at 192.168.1.110.
Sometimes, blocking a domain will cause a misbehaving client to go crazy about it. You could try to find out what that client is trying so desperately to resolve.
The following statement may help with that:
pihole-FTL sqlite3 "/etc/pihole/pihole-FTL.db" "SELECT domain, count(domain), reply_type FROM queries WHERE timestamp > strftime('%s','2022-11-19')AND client='192.168.1.110' GROUP BY domain ORDER BY count(domain) DESC LIMIT 10;"
Often, excessive requests may be caused by DNS loops (where an upstream would feed back its queries to Pi-hole), but your debug log contains no immediate hints that you would have configured such a loop.
On the contrary (and unrelated to your issue) - your DHCP server is distributing two public DNS servers besides Pi-hole, allowing clients to by-pass your Pi-hole completely at their discretion:
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
Scanning all your interfaces for DHCP servers
* Received 313 bytes from eno1:192.168.1.1
Offered IP address: 192.168.1.125
DHCP options:
Message type: DHCPOFFER (2)
dns-server: 192.168.1.125
dns-server: 208.67.220.220
dns-server: 208.67.222.222
router: 192.168.1.1
--- end of options ---
Pi-hole has to be the sole DNS server for your network.
I have seen this, and it is a "known" issue. Specifically, it's one of my Synology NAS and it has a BT client running. This "error" seems to occur every day at 9a and 5p every day. I have no idea why it picks those time or why it hammers on the DNS server. Since I haven't noticed a drop in performance, I would just delete the message and move on. Do you think that is a factor? Note that the Pi-Hole is running on different hardware and not on the NAS.
That is OpenDNS, which was what I was using before the Pi-Hole. I left it in as a "back up" if I was to do something, like updating or resetting. The internet would not be completely out during that process. Sounds like I shouldn't do that. Since this is in my home, I'm not too concerned about something or someone bypassing the Pi-Hole.
I found a tool in Ubuntu that estimates folder sizes. Any insight at what I am looking at and if the offending files "can go" is appreciated.
Also note that this is only used for Pi-Hole, so other than the operating system itself, and RustDesk used to connect remotely to the desktop, there shouldn't be anything else making space.
So, I found out that Snapd was causing the issue with some package and log files. I managed to delete them but now I can't add software. Oh, well. I wasn't planning on adding anything anyway.
