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.
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:
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
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.
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.
FTL is going down for me each day ... seems to be tied to the nightly log purge? I run the purge at 23:58 (instead of midnight because I have chronometer e-mail me some stats first). Notice there's nothing in the pihole-FTL.log after 23:58 until I restarted it at 8:44am this morning:
[2017-05-03 23:58:10.581] NOTICE: pihole.log has been flushed
[2017-05-03 23:58:10.581] Resetting internal data structure
[2017-05-03 23:58:10.582] Queries in memory before flushing: 24144
[2017-05-04 08:44:42.538] ########## FTL started! ##########
[2017-05-04 08:44:42.538] FTL branch: (no branch)
[2017-05-04 08:44:42.538] FTL hash: v2.6
[2017-05-04 08:44:42.539] FTL date: 2017-04-22 16:15:35 +0200
[2017-05-04 08:44:42.539] FTL user: pi
[2017-05-04 08:44:42.540] Warning: Starting pihole-FTL directly is not recommended.
[2017-05-04 08:44:42.540] Instead, use system commands for starting pihole-FTL as service (systemctl / service).
[2017-05-04 08:44:42.540] Notice: Found no readable FTL config file
[2017-05-04 08:44:42.541] Using default settings
Not sure how that can happen. FTL is constructed such that it should catch all errors and write them into the logfile before quitting. The only exception to this is if it gets killed by SIGKILL (because I cannot catch that by construction).
I suggest to use this instructions to couple the debugger to FTL:
It should catch even SIGKILL and even if not but the pihole-FTL crashes, we are in the best position to do debugging.
