Pi-hole diagnosis

The pihole team has already done a great job, creating (and expanding) the pihole debug log (pihole -d).
The pihole team is also very consistent in requesting a pihole debug log, to help them solve various problems.
It needs to be said a lot of users, asking help, never looked at the output of the debug log for various reasons, one of the reasons being it contains a lot of information, sometimes to complicated to understand for the average user.

Pi-hole already has a mecanism on board to report problems (the message table in the pihole-FTL database), which in turn shows a warning sign, if something has been detected.

Folowing suggestion:

  • add a button to the pihole diagnosis screen, that makes pihole-d run.
  • add logic to the debug script to generate messages. Examples:

This topic describes a timesync problem. By running (in the debug script) timedatectl, grep for "System clock synchronized: yes", you could add a message to the message table.

This topic describes a method to generate an open resolver message

Any other debug log test, that triggers an obvious configuration error...

  • optionally, add the following to /home/pi/.bashrc:
count=$(sqlite3 "/etc/pihole/pihole-FTL.db" "SELECT count(*) FROM message")
if [ "${count}" -ne "0" ];then
	echo "Active pihole diagnostic messages found!"
	echo "Check Tools / Pi-hole diagnosis"

I would not favor this. We already have a tab for generating a debug log.

To test for an open resolver you need to query the IP from outside and see if it returns an answer. How should this be done from within the debug script.

While I like the idea that more issues are reported by the message table I do see two main problems with it:

When we need the debug log to see if/what issues exists, users already have noticed malfunctions. But the message table is a tool to report potential issues. So we would need to run the debug script on a regular basis to early detect issues.

Usually it is not a single line that is misconfigured but an interplay of multiple configurations that might be only an issue in the particular setup a user has. Complex knowledge is required to identify an issue. I'm not sure if we can map that knowledge into code that will detect misconfigurations.

This is an example that might work.