No Data on dashboard

no errors related to admin console. errors below are related to my custom page and also fixed it :frowning:

2017-02-08 19:14:18: (mod_fastcgi.c.2702) FastCGI-stderr: PHP Notice: Undefined index: page in /v ar/www/html/index.php on line 32
2017-02-08 19:14:18: (mod_fastcgi.c.2702) FastCGI-stderr: PHP Notice: Undefined offset: 0 in /var /www/html/includes/dashboard.php on line 14
2017-02-08 19:14:18: (mod_fastcgi.c.2702) FastCGI-stderr: PHP Notice: Undefined variable: strTxPo wer in /var/www/html/includes/dashboard.php on line 185

What headers do you get when looking at the API requests in the browser's network dev tool tab?

I'm not sure if I get you correctly, Is this what you need?

Ad Blocking works, the data on the dashboard simply zero. looks looks like logs were not being read by the admin gui?

issue now resolved. change permission of /var/log/pihole.log to 644

1 Like

I suddenly had the same issue this morning, as the system was fine as if last night. Please see attached screenshot. I have a monitor tailing the pihole's log and it is processing queries, bu there is no data in the Web UI at all. Please keep in mind I am not a Linux programmer or user (noob). Strange, as it appears to be blocking and forwarding. I have flushed browser cache.

I updated to 3.3, but that killed pihole. So I downgraded to
Pi-hole Version vDev (HEAD, v3.2.1-0-ge602008) Web Interface Version vDev (HEAD, v3.2.1-0-g31dddd8) FTL Version vDev (v3.0 , v3.0 )

Since then the dashboard has ceased functioning.
If there any way to restore its function?
(I blindly changed permission of /var/log/pihole.log to 644 but no improvement)

I did exactly the same as turbine, with exactly the same result .. any clues why the dashboard has no information?
Query Log says 'No data available in table'

1 Like

BTW, running:
$ uname -a
Linux rpi3 4.4.21-v7+ #911 SMP Thu Sep 15 14:22:38 BST 2016 armv7l GNU/Linux

Not sure what to do now to get back to fully pihole operation, address filtering and live GUI. Unsure whether raspian is still compatible with pihole, or what pihole's requirements are for rpi3 for full operation.

Assume most of us non-devs are likely to blunder into the same wall.

I'm going backwards fast. Tried
pihole uninstall
all new install from the start
no interface at all now.
got as far as:
[✓] Stopping dnsmasq service...

[✓] Stopping lighttpd service...
[i] Using interface: eth0
[i] Using OpenDNS servers
[i] Static IP already configured
[i] Found IPv6 GUA address, using it for blocking IPv6 ads
[i] IPv4 address: 192.168...........
[i] IPv6 address: .......
[i] Web Interface On
[i] Logging On.
[✓] Check for existing repository in /etc/.pihole
[i] Update repo in /etc/.pihole...
Error: Could not update local repository. Contact support.

But no clue yet where support might be (assume not here).
So this 3.3 update has been the death of pihole for me, guess I will have to revert to the old spam world (reconfigure all devices to use open-NDS until pihole is fixed). This latest 3.3 update seems to have nuked my pihole completely.

All fixed now, I know not how. But after updating Raspian, deleting pihole, installing everything afresh. And the GUI can come alive again.

1 Like

OK I have this problem too. Update failed - the log-queries=extra being the reason (after trying to run dnsmasq and seeing it complain).
Downgraded as detailed on page Pi-hole v3.3 Released: It's "Extra" Special
(Also see How do I revert to a previous version of Pi-hole?)

Restarted FTL: systemctl restart pihole-FTL
Dashboard is now empty; see that it is regularly requesting local page /admin/api.php?summary
Visiting that returns JSON:

Find this api.php within /var/www/html/admin, no mention of summary.
Find that it is actually within api_FTL.php which uses function getResponseFTL from /var/www/html/admin/scripts/pi-hole/php/FTL.php
Had a look at GitHub - pi-hole/FTL: The Pi-hole FTL engine
Find that FTL is running on local port 4711 by looking at /var/run/pihole-FTL.port

telnet localhost 4711 connects to running FTL interface

Notice that the PHP functions look for ---EOM--- so run some commands into FTL:

queries in database: 291308
database filesize: 23.01 MB
SQLite version: 3.22.0

version v3.0
tag v3.0
branch v3.0
date 2018-02-14 12:45:47 -0800



memory allocated for internal data structure: 444148 bytes (444.15 KB)
dynamically allocated allocated memory used for strings: 79 bytes (79.00 B)
Sum: 444227 bytes (444.23 KB)

domains_being_blocked 582817
dns_queries_today 0
ads_blocked_today 0
ads_percentage_today 0.000000
unique_domains 0
queries_forwarded 0
queries_cached 0
clients_ever_seen 0
unique_clients 0
status enabled

So obviously the dashboard is updated by connecting to FTL on a socket and running >stats until ---EOM--- is found, then it breaks out.
But the stats are awry. So try to see what FTL has open:
ps aux | grep FTL
pihole 24867 0.4 0.2 57768 2500 ? Sl 21:46 0:03 /usr/bin/pihole-FTL

Query for open files for process 24867:
sudo lsof -p 24867
pihole-FT 24867 pihole cwd DIR 179,2 4096 63522 /etc/pihole
pihole-FT 24867 pihole rtd DIR 179,2 4096 2 /
pihole-FT 24867 pihole txt REG 179,2 1163533 39852 /usr/bin/pihole-FTL
pihole-FT 24867 pihole mem REG 179,2 46820 15702 /lib/arm-linux-gnueabihf/
pihole-FT 24867 pihole mem REG 179,2 38612 15710 /lib/arm-linux-gnueabihf/
pihole-FT 24867 pihole mem REG 179,2 71628 15699 /lib/arm-linux-gnueabihf/
pihole-FT 24867 pihole mem REG 179,2 30592 15700 /lib/arm-linux-gnueabihf/
pihole-FT 24867 pihole mem REG 179,2 1242776 15651 /lib/arm-linux-gnueabihf/
pihole-FT 24867 pihole mem REG 179,2 122308 15722 /lib/arm-linux-gnueabihf/
pihole-FT 24867 pihole mem REG 179,2 18920 17487 /usr/lib/arm-linux-gnueabihf/
pihole-FT 24867 pihole mem REG 179,2 134456 11759 /lib/arm-linux-gnueabihf/
pihole-FT 24867 pihole 0u CHR 1,3 0t0 1028 /dev/null
pihole-FT 24867 pihole 1u CHR 1,3 0t0 1028 /dev/null
pihole-FT 24867 pihole 2u CHR 1,3 0t0 1028 /dev/null
pihole-FT 24867 pihole 3u IPv4 126582 0t0 TCP localhost:4711 (LISTEN)
pihole-FT 24867 pihole 4u IPv6 126584 0t0 TCP localhost:4711 (LISTEN)
pihole-FT 24867 pihole 5u unix 0xb4b81b00 0t0 126585 /var/run/pihole/FTL.sock

Think perhaps the database is awry, delete /etc/pihole/pihole-FTL.db
Restart FTL, no difference.
Delete all pihole logs, no difference.

Try to look at github for history of changes for log parsing as log format has apparently changed... nothing I can see.
Now I'm out of ideas...

Any suggestions??

Are you now on 3.3?

If you want to downgrade, you also have to downgrade FTL:

pihole checkout ftl v2.13.2

Thanks for the help - I am on 3.0 due to inability to grab new dnsmasq at the moment.
Weirdly logging started working on its own accord late yesterday; I only discovered this when I attempted to use pihole checkout ftl v2.13.2 (which reported "Branch v2.13.2 exists").

So this is resolved for me but unfortunately I have no idea why.

I'm having the same issue where suddenly no graphs or client information. Otherwise, things are working fine. I can see DNS resolving in the logs.

Pi-hole Version v3.3 Web Interface Version v3.3 FTL Version v3.0

Your debug token is: zcoi2i3v2v


1 Like

I am running a docker version and I am at 3.3.3 and I am getting a blank dashboard too, although dns resolution is working fine. Any thoughts on what's going on or where to start debugging? Debug token is nhfjj6rc17

1 Like

For docker see:

Are you also using the docker image? If so, see the link above.

Pi-hole Version v3.3 Web Interface Version v3.3 FTL Version v3.0
Seems (fingers crossed) to be running well.
Even pihole -t seems more responsive.

I just had this occur to me. Tracked it down finally to timestamp issues on reboot. When my singleboard computer reboots, its clock is set to some time in the future. If some requests come in while it is in this state, pihole treats that far future date as "today". When ntp finally gets around to updating the time, all incoming requests are now too far in the "past" to be considered valid. Restarting pihole does not correct the issue because it reparses the entries in the log file. You must delete /var/log/pihole.log after the time is set correctly, and optionally remove any future entries from the queries table in the db file.

I've updated my startup scripts to require pihole and dnsmasq to start up after ntp, but I have not yet restarted to verify that the time is set correctly before dnsmasq starts logging entries.