These reports are all showing that the FTL engine is not active or not responding to queries. We're taking a look at what may cause this issue to happen.
I did this:
pi@raspberrypi:~ $ sudo rm -r -f /etc/pihole
pi@raspberrypi:~ $ sudo rm -r -f /etc/.pihole
pi@raspberrypi:~ $ sudo rm -r -f /etc/.piholed
pi@raspberrypi:~ $ sudo rm -r -f /var/www/html/admin
pi@raspberrypi:~ $ curl -sSL https://install.pi-hole.net | bash
And, the FTL still is crashing out after restarting... 
Now the web interface is running. But when I open dashboard on Chrome, it consumes ~500MB of RAM and it is very slow. Also graph is
By default (i.e. unless changed by an FTL setting), FTL will only listen locally, so you can restrict your rule to the loopback device, if you like.
1 Like
This looks like your browser still caches the JavaScript of earlier times. Unfortunately, most users won't flush the JS cache, even if you request to clear all browsing data...
Try closing the browser altogether and restarting it.
Another possibility is to go to the "Developer Tools" (press F12), go to "Network" and select "Disable cache" (might be named differently depending on your browser). Then reload the web interface of Pi-hole and keep the Developer Tools opened. The first loading might be slow (because no caching will be done), but hopefully it works in resolving your issue.
I also suspected the same thing, I cleaned the cache. But nothing happened. I uninstalled and reinstalled pihole, now everything is working fine. However it's showing 'queries over time' graph only and graphs (pie chart) about 'query types' and 'forward destinations' are missing....
Any luck on this? I was wondering if there's a way to revert to the last version until the next release? I'm finding the current 3.0, aside from FTL crashing, seems to not be blocking ads properly until I reboot the Pi.
We are still trying to narrow it down. Your logs are showing that the init system in linux is killing the FTL engine. Due to the nature of all of us being volunteer free-time developers, getting all of us together across 4 continents is difficult at times. I sincerely apologize for this and we would not have released if we didn't feel it was ready.
I will check and see if there is a way to roll back to an earlier release, there may need to be some special commands to get there and your interface would show that it is out of date, but if we can find a way to set you back to where you were when it was working we will get that information to you as soon as we possibly can.
4 Likes
Not sure if below info is useful but here goes anyway.
When I read this at first, I tried to crash FTL but couldnt.
Until I noticed if I kill it, systemctl status would show it wasnt running anymore and starting, systemctl start, didnt work.
Had to do stop/start or restart to get here up and running again.
Not sure if this behaviour is confusing systemd with these old school systemv scripts.
I even tried rewriting it using ntpd as example but it gave a similar behaviour:
I see someone has resolved a similar issue a few mins ago here FTL not working - #4 by Tntdruid is this the final solution?
The question is: With which user are running FTL? If you are using the pihole user (as the service file suggests`), you have to make sure the ownership is like
sudo chown pihole:pihole /var/log/pihole-FTL.log
If you run it manually (e.g., as user pi), the ownership has to be
sudo chown pi:pi /var/log/pihole-FTL.log
etc.
We discussed this in the past and the script actually does exactly the same wehter you run start or restart, see here:
https://github.com/pi-hole/pi-hole/blob/master/advanced/pihole-FTL.service#L71
The fact that this does not work on some systems, means what you said: systemd seems to be confused somehow and does something different than we want. Not sure if we can control that 
No worries at all, Dan! I realize and appreciate all your efforts. When pi-hole is down you realize how nasty the unfiltered web can be!
I'm wondering if you have a base system you use - eg which release of the pi image you develop with (eg raspian jessie? Which release?). I'm willing to start totally from a new install if it means we can make this work.
For the Pi, we base off of Raspbian Jessie Lite. That gets the most heavily tested release work done for it.
I found it necessary to do an uninstall and reinstall moving to using FTL.
Just to add to that: I suspect in the end part of the problem was a browser caching issue. Even after uninstalling and reinstalling, the dashboard screen was not rendering properly. After I blew my cache in Chrome away everything rendered properly.
I generated another debug log - even though my FTL seems to be running since last night with no new changes. Funny the debug log generation was stuck on parsing the lighttpd/error.log for nearly 30 minutes (on a Pi3). My Pi is based on a Raspian Jessie full installation, if I recall.
Token: wtzkw0itvm
Although the FTL was working at the time, I also tried:
pi@raspberrypi:~ $ sudo netstat -tulpn | grep FTL
tcp 0 0 127.0.0.1:4711 0.0.0.0:* LISTEN 721/pihole-FTL
pi@raspberrypi:~ $ pihole-FTL running
FATAL: Opening of FTL log (/var/log/pihole-FTL.log) failed!
Make sure it exists and is writeable by user pi
pi@raspberrypi:~ $ sudo chown pi:pi /var/log/pihole-FTL.log
pi@raspberrypi:~ $ pihole-FTL running
Yes: Found a running FTL process
Thanks for the note on the debugger. We've had another one or two reports of lockups. That code hasn't really changed, so will have to tear it apart to see what's going on.