Please follow the below template, it will help us to help you!
Expected Behaviour:
PI-hole to operate
Actual Behaviour:
pi-hole goes off-line.
My pi was running fine for many months and decided to update to the latest version yesterday. I’ve now started from scratch by rebuilding, then updating the OS, then finally installing pihole via curl (I’ve done this 4 times now).
On all occasions affter a clean builld, after a few hours everything goes offline, then the admin console says, “lost connection to the API”. I’ve tried doing the following;
• pihole -up to get the latest’s changes
• curl install
This might not be relevant but I’ve noticed the following.
• the load average for the pi keeps climbing until pi hole eventually goes offline.
• More block lists you have the quicker the load averages goes up and the quicker it fails.
With lots of block lists I’ve seen the load averages get up to 9, there’s absolutely nothing else running on the pi other than what comes with Raspbian Stretch Lite and pi hole. The sd card is re imaged each time I’ve rebuilt it (that's 4 times today). I have no idea what’s happening, this version does not work for me, does anyone have any ideas?
If you look in the help section, there are many reports of FTL going down after the 4.0 update, myself included. Just trying to put our finger on what's causing it.
pi@raspberrypi:~ $ sudo service pihole-FTL status -l
● pihole-FTL.service - LSB: pihole-FTL daemon
Loaded: loaded (/etc/init.d/pihole-FTL; generated; vendor preset: enabled)
Active: active (exited) since Tue 2018-08-21 07:36:30 UTC; 1h 0min ago
Docs: man:systemd-sysv-generator(8)
Process: 3159 ExecStop=/etc/init.d/pihole-FTL stop (code=exited, status=0/SUCCESS)
Process: 3198 ExecStart=/etc/init.d/pihole-FTL start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/pihole-FTL.service
Aug 21 07:36:29 raspberrypi systemd[1]: Starting LSB: pihole-FTL daemon...
Aug 21 07:36:29 raspberrypi pihole-FTL[3198]: Not running
Aug 21 07:36:29 raspberrypi pihole-FTL[3198]: chown: cannot access '/etc/pihole/dhcp.leases': No such file or directory
Aug 21 07:36:30 raspberrypi su[3236]: Successful su for pihole by root
Aug 21 07:36:30 raspberrypi su[3236]: + ??? root:pihole
Aug 21 07:36:30 raspberrypi su[3236]: pam_unix(su:session): session opened for user pihole by (uid=0)
Aug 21 07:36:30 raspberrypi pihole-FTL[3198]: FTL started!
Aug 21 07:36:30 raspberrypi systemd[1]: Started LSB: pihole-FTL daemon.
I rebuilt this morning as I broke it last night trying to downgrade. Rebuild all went well, I started adding my lists in groups of 10. I got to a point in the list where the behavior came back and pi-hole is now slow and unresponsive. So it seems to be something to do with the block lists, I think if I keep the default list then it seems fine. I'm doing this all via the web interface, I tried removing the last 10 added, but it says dns is offline.
This looks likes some limit is being hit. I have no idea whether it’s hardware or software limit. My block list is about 85 entries which equates to about 3million domains. The pi ran happily for 6 months on the previous version with this.
I’ve been trying to find the limit where everything stops working but have been unsuccessful so far. The problem seems to be after a certain number of lists or domains are added pi-hole fails with around 90% memory usage and load averages of 3+, which seems to be mostly IO. FTL continues to run but the load creeps up, eventually everything grinds to a halt. All the while nothing seems to be blocked.
On every occasion where it’s failed the interface always says there are 26 domains on the block list instead of millions.
If the pi has become super unresponsive I disable pi-hole and its then accessible, then I can mess around again.
Also pihole-FTL seems to be the thing that consumes the most system resources according to the top command.
Hi RamSet. As suggested by DL6ER in another post I did the following ‘sudo nano /etc/pihole/pihole-FTL.conf), then add ‘BLOCKINGMODE=NXDOMAIN’ to the file, save, reboot. I then added my block lists in chunks with a couple reboots in between because the web interface took a while to catch-up with the change.
My Pi is now working with minimal resource usage and all block lists loaded.