Pi-hole dashboard stops working after DietPi upgrade

Since one year pi-hole seems to have a problem with php and I have never been able to solve it. On a clean install, pi-hole dashboard works even after I update pi-hole but as soon as I update DietPi, something gets messed up and on the dashboard “Total-queries”, “Queries Blocked” and “Percentage Blocked” show — and the other graphs are totally missing.

My solution so far has been to delete the installation and go back to a clean install to get pi-hole dash working again but I guess someone found solution? I went through many, many topics already that suggest installation of some php packages or tweaking with permissions but nothing works… :frowning:

Does anybody have the golden clue?

did you tried to report it to PiHole guys directly? They might be more helpful why graphs are missing.

Another option is to reboot and/or to clear browser cache.

Thanks for reply :slight_smile:

No, I didn’t report it to the pihole guys as updating dietpi breaks it and I am guessing more people run pihole :slight_smile:

Reboot and browser cache didn’t help anything

Yes Pihole is quite popular app. But you are the only one reporting such issue. Personally, my Pihole is working fine on each update.

The missing graphics I have seen a couple of times on PiHole forum. Probably the guys over there have an idea what it could be.

Missing dashboard stats usually mean a permissions issue, but when half the stats are showing up, the other half not, this doesn’t fit into the picture :thinking:. From which DietPi version are you updating? There should be nothing that affects Pi-hole, but just to verify. More likely is that it is due to APT package upgrades, like Lighttpd or PHP. Can you replicate the issue when upgrading all APT packages?

apt update
apt upgrade

If so, can you show the output of these commands:

groups www-data
ls -l /etc/pihole

Also check Lighttpd and PHP logs:

tail -20 /var/log/lighttpd/error.log
tail -20 /var/log/php7.4-fpm.log

(Assuming that it is a Bullseye system)
Also check the browser console, probably it shows some errors/hints.

I actually had this problem.
I upgraded DietPi to 8.0.2 last night. I also did the update from Bucksnort to Blueberry or whatever. I pretty sloppily plowed through copy-paste instructions (thank you for those) and didn’t really test until the end.
PiHole was wounded.
I found that

/etc/pihole/setupVars.conf

had multiple, conflicting values for

BLOCKING_ENABLED=

This let PiHole kind of work, but it disabled itself within a second of you looking at it. It seems the problem isn’t unheard of by the PiHole group, but I suspect that this is a text file that has too many things that write to it without locking and some code is sourcing it (last man wins) and some code is doing a sed on it (probably the first one) and it’s just not found the culprit. In-place updates of system software are notoriously hard to get right and especially if you do a couple in a row.

Beyond that, my Pi3 is now happily running Bunnyrabbit (man, I hate exposed code names) and my Pi is dutifully saving my home network from the onslaught of crap that is the modern web. Thank you, everyone!

You are so right! First I installed “php-sqlite3” but that didn’t help at all.

Searching for the error in /var/log/lighttpd/error.log :
/var/www/html/admin/scripts/pi-hole/php/database.php(65): SQLite3_connect_try(‘/etc/pihole/gra…’, ‘SQLITE3_OPEN_RE…’, true)

This page had he solution :

sudo apt-get install php7.3-sqlite

Reboot dietpi and all is working!! Thanks for the help/tips/pointers everyone!

RandomDude
Let’s skip Debian version code names then :smiley:, so you mean you upgraded from Debian 10 to Debian 11, I guess? cat /etc/debian_version reveals the version string. While it usually works well, this indeed can cause the need for some tinkering, like updating some config files manually and so on. We try to catch all known issues and extend our HowTo about this upgrade accordingly, but for distro upgrades there is no guarantee that they go through without any issue, which is the reason why we clearly recommend to flash a new image instead, when the upgrade is needed, and why many other distros simply don’t support it, i.e. don’t offer help for distro upgrades or support for system after an upgrade. On Debian, it simply means that packages get major version upgrades, which by definition mean backwards incompatibility, possibly with configs and also stored software data :wink:.

However, we faced a similar high (and in the long term higher) number of issues related to outdated distro versions compared to upgraded distros, so we decided to support and provide a HowTo for best practice and to cover all issues we know or get reports about. In case of Debian 10, it is however not required to do that, as we support it for at least another 1.5 years, I hope our info “campaign” didn’t give a false impression :wink:.

/etc/pihole/setupVars.conf shouldn’t be touched by DietPi or Debian updates/upgrades :thinking:. Can you show it, masking private IP/hostname info? It is mostly used by the installer/updater only, if there are duplicate entries, it is safe to remove them manually and leave one with the wanted setting. Since duplicates shouldn’t be created in the first place, you may indeed want to report this to Pi-hole forum or GitHub. Feel free to ping me @MichaIng in both cases.

linuxfreak
So you are on Debian 9 (Stretch)? Always install PHP modules with the version string, else it may pull a totally different PHP version, especially on Stretch where PHP7.3 is installed from Ondrej’s PHP repository, the Debian PHP package maintainer which ships newer PHP versions for older Debian versions with a dedicated package repository. Otherwise Stretch would ship PHP7.0 only, which isn’t supported anymore by a lot of web applications. The package php-sqlite3, I guess, pulled PHP8.1, while the webserver is configured to use PHP7.3. You can cleanup the unneeded/doubled PHP instance with:

G_AGP 'php8.1-*'

It hence makes sense that installing the versioned SQLite module worked. I’m just wondering why it wasn’t installed in the first place, as dietpi-software of course does that, the Pi-hole installer else would do by itself :thinking:. Generally, safest to repair Pi-hole, webserver, PHP and database setup is a reinstall:

dietpi-software reinstall 31

This preserves all data and configs but assures that all dependencies are (re)installed and, in case, components repaired.

to be sure the version you are on

cat /etc/os-release