your mean /var/log/pihole/pihole.log
?? Or you mean in the web UI??
In the web UI.
How can I check FTL.log? Do I have to open it with “Mousepad” and check for content?
on DietPi we don’t log DNS request to pihole.log because it’s already in the database file.
You might need to check with PiHole guys, why there is no query log displayed in the web interface
I made a test with a backup on Dietpi 9.10: If I update here pihole to v6, query log is working but it uses port 8080 instead of 8089 (doesn’t get dietpi’s tweaks with 9.11 v2) and I get a warning that I’m not using https.
After update to 9.11 v2 and applying the “new” tweaks for pihole 6, I’m not able to see the query log anymore.
thx for testing, much appreciate. What happen if you try following?
pihole-FTL --config dns.queryLogging 'true'
Does this bring back query logging within the web UI or just within /var/log/pihole/pihole.log
Just update pihole and let lighttpd and php installed. I migrated yesterday without any problems, even https works out of the box.
you are on DietPi v6.11? If yes, did you update Pihole to v6 before doing the DietPi update?
Interesting conversation, I applied the new pihole update from the command line with pihole -up and all worked as planned and is operating normally. I do have the https warning as expected per the pihole website Blog ( I just need to change ports of course) and I disabled the lighttpd server because I was not using it for anything else and other than that it is business as usual. My flt log, which I assume you mean the query log from the web gui is also functioning as normal.
I do want to check my dnsmasq config file as pihole does not use it by default now and I am not sure what I put in there 2 years ago, haha.
something you need to enable yourself to get it back working. Had some hours yesterday to get all back what I had setup in dnsmasq.d
No, I first ran dietpi-update and then
pihole -up` and since I’m keeping lighttpd, I can reach pihole under http://:8080/admin/login and https://:8443/admin
So I guess https is working ootb because of the beforehand dietpi-update
, otherwise it just runs without https (as far as I understood if port 80 and 443 is already in use, it just binds to 8080 for http by default?!
With
lighttpd
disabled,pihole-FTL
will attempt to bind to ports 80 for HTTP and 443 for HTTPS. If there is any conflict on these ports, then it will revert to port 8080 for HTTP.
https://pi-hole.net/blog/2025/02/18/introducing-pi-hole-v6/#page-content
yes but we will move it to http 8089 by default to avoid port conflicts with other apps. In your case, on next DietPi update 9.12. At least that’s our idea for system which did not pass our PiHole migration path yet.
In the case that you did the dietpi-update at first and pihole -up as second, you can force an additional “re-dietpi-update” via dietpi-update -1.
Therefore you don’t have to wait until DietPi v9.12.
Yes, query log is back again Very strange thing.
Another point: From v5 to v6, I checked every setting and one was not correctly migrated to v6. In v5 I unchecked Never forward reverse lookups for private IP ranges and in v6 the box was ticked again. But this is just a little thing
I’m fine with that, for some time I wanted to migrate to nginx and now the time has come to do this
Sorry i got a bit confused, which should i upgrade first?
I would say first pihole with pihole -up and then dietpi with dietpi-update
Correct @donbattino452
Migration is done by PiHole tooling outside DietPi control. However @MichaIng might be able to look into as he is supporting PiHole project in this case as well
Indeed strange because I have it set it to false
and it is working as expected.
root@DietPiProd:~# pihole-FTL --config dns.queryLogging
false
root@DietPiProd:~#
The idea behind dns.queryLogging 'false'
is actually to prevent logging to the file /var/log/pihole/pihole.log
, as this can otherwise grow considerably. The data is contained in the database anyway and does not really need to be stored twice in a file. Especially as very few users will search through the file, but rather the database via the web UI.
went smoothly, both lighttpd and php removed during update, port also changed to 8089 for http.