[ OK ] DietPi-Bugreport | Bug report sent, reference code: db81edf8-d74a-43e4-b7b0-1a2f12e29968
Try with just the stock lists enabled. The list below looks to be malformed.
-rw-r--r-- 1 root root 20 Feb 10 18:12 /etc/pihole/adlists.list
https://dbl.oisd.nl
Is there a quick way to switch back to the stock lists? I removed them all instead of disabling.
Once I have done that, do you want me to send any debugs etc. or just wait and see what happens tomorrow?
Set /etc/pihole/adlists.list to the following:
https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
https://mirror1.malwaredomains.com/files/justdomains
http://sysctl.org/cameleon/hosts
https://s3.amazonaws.com/lists.disconnect.me/simple_tracking.txt
https://s3.amazonaws.com/lists.disconnect.me/simple_ad.txt
https://hosts-file.net/ad_servers.txt
1 Like
Okay, one thing I found is that ddclient (like noip2/dyndns to update DNS records for dynamic IPs) fails, then retries regularly. At least something you could look into, but should not be related: journalctl -u ddclient
Everything else looks pretty fine 
. Just to rule it out, you could disable cron + timers for half an hour and see if next :03/:33 minutes the restart does not happen.
systemctl stop cron.service phpsessionclean.timer man-db.timer
To revert:
systemctl start cron.service phpsessionclean.timer man-db.timer
Apt removed ddclient for now. Did you mean for me to run those other commands, or were they a way to disable ddclient?
I meant, as a test, to run first:
systemctl stop cron.service phpsessionclean.timer man-db.timer
wait for half an hour, check journalctl -u pihole-FTL if it was again restarted during that 30 minutes.
If it indeed is NOT restarted, probably even within a second 30 minutes, then we would need to have a closer look into each cron job.
Then, to re-enable thinks:
systemctl start cron.service phpsessionclean.timer man-db.timer
Ok. Will do this tomorrow. It's late here in UK.
I stopped the Cron services as suggested, but then ran journalctl -u pihole-FTL out of curiousity. It does look like the last pihole-FTL stop was two days ago.
Going to start the cron services again and see whether there are further crashes today.
Will report back if I spot any.
@DanSchaper I've disabled dbl.oisd.nl, and put back the default lists. Memory use for pihole-FTL is down from 35% to 6%. I don't think this has anything to do with the issues I was facing but thought I'd share.
I haven't been experiencing high load or failure to resolve DNS for the last couple of days, so it looks like something you asked me to do had a positive impact. This was before I changed the blocklist, so something else. I didn't stop the phpsessionclean.timer and man-db.timer so it is something else.
I have noticed that pihole-FTL.log is 0 bytes, whereas at some point it was much larger. I don't recall setting pihole to stop logging but it looks like it has.
I don't know if you want to keep poking at this to find out what is going on, or if life is to short. I'm happy either way. I can always pipe up if things turn south 
Thanks so much for the assistance you and @MichaIng provided. Very impressed!
1 Like
If there are no entries for the log, it will remain empty and that is normal. This log is not one that is frequently written, unless you have debug options enabled.
Hehe, I thought the journalctl -u pihole-FTL output was just truncated, but then indeed it stopped restarting on Mar 16 already. That is great, whatever was the reason. I would leave it like that now, if you experience something similar again, and this topic is already closed, open a new one, giving it tag "dietpi" (I am watching this tag now, hence will get an email) or open an issue here on our GitHub, if it looks more system-related then Pi-hole related: GitHub · Where software is built
Just to be sure, systemctl status cron is running again, right? 
And pihole-FTL.log is cleared every hour as part of our RAMlog implementation. If you need long-term logs for a particular one, you can link it to another location, e.g.:
systemctl stop pihole-FTL
mv /var/log/pihole-FTL.log /root/pihole-FTL.log
ln -s /root/pihole-FTL.log /var/log/pihole-FTL.log
systemctl start pihole-FTL
But as long as the actual file is in RAM, it needs to be cleared regularly, to not unconditionally fill the system memory.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.