Please follow the below template, it will help us to help you!
Expected Behaviour:
PiHole to respond to DNS requests all the time
Actual Behaviour:
Once or twice an hour, PiHole stops responding to DNS requests. When I ssh in, htop shows CPU at 100% with pihole-FTL accounting for at least 95%. This lasts about 5 minutes, after which DNS starts working again.
In the FTL logs at around the time of the issue I see:
[2020-03-16 16:57:15.702 475] Resizing "/FTL-strings" from 98304 to 102400
tail: /var/log/pihole-FTL.log: file truncated
[2020-03-16 17:33:16.806 10216] Using log file /var/log/pihole-FTL.log
[2020-03-16 17:33:16.808 10216] ########## FTL started! ##########
Pihole log shows this at the same time: Mar 16 17:33:09 dnsmasq[475]: exiting on receipt of SIGTERM
If you suspect the DietPi install is broken, I'd rather look into how it might be broken, so DietPi can be advised to fix it, rather than just start from scratch just for me.
The RAMlog is cleared every hour, so this should not be possible. That the file is truncated is the result from hourly clearing. If I remember right, this shows up on FTL start, hence is not related to the prior failure/SIGTERM.
@dunxd
Additionally to journalctl output, could you paste as well kernel messages, just to role or any kernel/SDcard I/O or memory issues.
The file is not deleted, the following is done with every log file once an hour:
> /var/log/pihole-FTL.log
We had an exemption and special handling for pihole.log in place, clearing it only if grown over 50% of tmpfs space and stopping/starting the service before/after. I had some discussion on GitHub some year ago, if this is (still) required, especially since we never handled the new pihole-FTL.log special and the result was that especially pihole-FTL.log should be very stable against log file manipulation while pihole.log logging can and should be disabled, since it does not contain much more than the web interface query log. So we do pihole -l off now on install.
I can search for the GitHub topic, would be of course important to know if this changed. But really, not a single (other) program of all what Debian offers ever had any issue with a truncated log file, so I doubt that this can crash or overload pihole-FTL. EDIT: Else logrotate would cause the same issue
We do not even know where FTL is entering the high CPU load.
Neither do we know if
is connected to the crash at all.
How many devices do you have connected to your network?
How many queries are they doing roughly?
I already saw your setup is an RPi 2 running DietPi and nothing besides Pi-hole on it. Maybe the large workload is storing something in the database (not too likely) or the tries to re-resolve host names (happening once an hour, not twice).
Have you checked the query log after such a period of intense work? Maybe it is real and your Pi-hole has to reply to thousands of queries per second from some client going mad?
