I am using a pi zero w with dietpi. Pihole is still running and working fine and i can access it via ssh but i cant access the web GUI. It was working completely fine a few days go. Dietpi and pihole are up to date from what I can see in ssh.
When I try to access the web GUI i get 500 and 503 errors.
65ktp3oqtz
Your debug log shows a couple of errors:
*** [ DIAGNOSING ]: php version
[✗] php version could not be detected.
*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✗] Failed to resolve htpbox.info via localhost (127.0.0.1)
[✗] Failed to resolve htpbox.info via Pi-hole (192.168.1.8)
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (8.8.8.8)
*** [ DIAGNOSING ]: Dashboard and block page
[✗] Block page X-Header: X-Header does not match or could not be retrieved.
HTTP/1.1 503 Service Not Available
*** [ DIAGNOSING ]: contents of /var/log/lighttpd
-rw-r--r-- 1 www-data www-data 380473 Sep 29 21:46 /var/log/lighttpd/error.log
2020-09-29 21:17:02: (gw_backend.c.476) unlink /var/run/lighttpd/php.socket-0 after connect failed: Connection refused
This is despite IPv4 network connectivity and pihole-FTL as well as lighttpd reporting active:
*** [ DIAGNOSING ]: Networking
[✓] IPv4 address(es) bound to the wlan0 interface:
192.168.1.8/24 matches the IP found in /etc/pihole/setupVars.conf
[i] Default IPv4 gateway: 192.168.1.1
[✓] Gateway responded.
*** [ DIAGNOSING ]: Ports in use
[80] is in use by lighttpd
[80] is in use by lighttpd
[53] is in use by pihole-FTL
[53] is in use by pihole-FTL
[4711] is in use by pihole-FTL
[4711] is in use by pihole-FTL
*** [ DIAGNOSING ]: Pi-hole processes
[✓] lighttpd daemon is active
[✓] pihole-FTL daemon is active
I'd normally recommend to try pihole -r with Repair, but seeing that you are running on dietpi, that may compromise your webserver configuration, depending on how you installed it.
Did you intentionally remove PHP from your machine?
EDIT:
Added connecton refused failure from lighttpd/error.log above.
Can you please paste the following output, shortly after you tried to access the web UI:
journalctl -u lighttpd
tail -10 /var/log/lighttpd/error.log
Failed resolving of doubleclick.com via Google DNS is a problem on it's own, as this has nothing to do with webserver, PHP or Pi-hole 
. Could be tested separately:
getent hosts doubleclick.com
Let's see what happened with PHP command:
ls -l "$(which php)"
php -v
And now I see RPi Zero, hence armv6l. Is it a Stretch system? echo $G_DISTRO_NAME
EDIT: Okay it's Buster, so accidental PHP7.4 upgrade should not be the issue here. Thanks to Bucking_Horn for sharing the related diagnose lines.
*** [ DIAGNOSING ]: Operating system
[✓] Raspbian GNU/Linux 10 (buster)
*** [ DIAGNOSING ]: Processor
[✓] armv6l
Hi, I did actually do a pihole -r and it didn't fix anything. Pihole -up didn't fix anything either and actually gave me this error:
Checking apt-get for upgraded packages Kernel update detected. If the install fails, please reboot and try again
but when I tried pihole -up again it said it was up to date, so I dont know what's going on. I installed pihole via the curl command, iirc, i definitely didn't use the dietpi to install pihole.
Also I did definitely did not intentionally remove php from my installation, haha.
That is good to know, however please go through the debug commands (especially Lighttpd logs) above, all but php7.3-fpm (I edited it out) is still helpful.
I was just going to recommend that. 
For jambo's sake, I'd like to add that MichaIng is a reliable source when it comes to DietPi.
Oops, sorry! I saw that you asked me to run those but was then a little unsure because I got confused with the edit, I think, haha.
> root@DietPi:~# journalctl -u lighttpd
-- Logs begin at Wed 2020-09-30 15:38:29 BST, end at Wed 2020-09-30 18:26:42 BST
. --
Sep 30 15:38:29 DietPi lighttpd[20322]: /usr/bin/php-cgi: error while loading sh
ared libraries: libicudata.so.63: cannot open shared object file: No such file o
r directory
Sep 30 15:38:29 DietPi lighttpd[20322]: ignoring unknown attr section !eabi
Sep 30 15:38:29 DietPi lighttpd[20322]: /usr/bin/php-cgi: error while loading sh
ared libraries: libicudata.so.63: cannot open shared object file: No such file o
r directory
Sep 30 15:38:31 DietPi lighttpd[20322]: ignoring unknown attr section !eabi
Sep 30 15:38:31 DietPi lighttpd[20322]: ignoring unknown attr section !eabi
Sep 30 15:38:31 DietPi lighttpd[20322]: /usr/bin/php-cgi: error while loading sh
ared libraries: libicudata.so.63: cannot open shared object file: No such file o
r directory
Sep 30 15:38:31 DietPi lighttpd[20322]: ignoring unknown attr section !eabi
Sep 30 15:38:31 DietPi lighttpd[20322]: ignoring unknown attr section !eabi
Sep 30 15:38:31 DietPi lighttpd[20322]: /usr/bin/php-cgi: error while loading sh
ared libraries: libicudata.so.63: cannot open shared object file: No such file o
r directory
Sep 30 15:38:33 DietPi lighttpd[20322]: ignoring unknown attr section !eabi
Sep 30 15:38:33 DietPi lighttpd[20322]: ignoring unknown attr section !eabi
Sep 30 15:38:33 DietPi lighttpd[20322]: /usr/bin/php-cgi: error while loading sh
ared libraries: libicudata.so.63: cannot open shared object file: No such file o
--More--
> root@DietPi:~# tail -10 /var/log/lighttpd/error.log
2020-09-30 18:27:14: (gw_backend.c.476) unlink /var/run/lighttpd/php.socket-0 after connect failed: Connection refused
2020-09-30 18:27:14: (gw_backend.c.328) child exited: 127 unix:/var/run/lighttpd/php.socket-0
2020-09-30 18:27:15: (gw_backend.c.476) unlink /var/run/lighttpd/php.socket-0 after connect failed: Connection refused
2020-09-30 18:27:16: (gw_backend.c.328) child exited: 127 unix:/var/run/lighttpd/php.socket-0
2020-09-30 18:27:16: (gw_backend.c.476) unlink /var/run/lighttpd/php.socket-0 after connect failed: Connection refused
2020-09-30 18:27:16: (gw_backend.c.328) child exited: 127 unix:/var/run/lighttpd/php.socket-0
2020-09-30 18:27:17: (gw_backend.c.476) unlink /var/run/lighttpd/php.socket-0 after connect failed: Connection refused
2020-09-30 18:27:18: (gw_backend.c.328) child exited: 127 unix:/var/run/lighttpd/php.socket-0
2020-09-30 18:27:18: (gw_backend.c.476) unlink /var/run/lighttpd/php.socket-0 after connect failed: Connection refused
2020-09-30 18:27:18: (gw_backend.c.328) child exited: 127 unix:/var/run/lighttpd/php.socket-0
Thanks all for your help! 
Still missing:
Oops, sorry! Here it is:
root@DietPi:~# ls -l "$(which php)"
lrwxrwxrwx 1 root root 21 Dec 14 2019 /usr/bin/php -> /etc/alternatives/php
root@DietPi:~# php -v
ignoring unknown attr section !eabi
ignoring unknown attr section !eabi
php: error while loading shared libraries: libicudata.so.63: cannot open shared object file: No such file or directory
root@DietPi:~#
apt install --reinstall libicu63
Should be actually present due to package dependencies php7.3-cli > libxml2 > libicu63 but probably it got damaged or removed somehow.
Let's see if this is a symptom because of the missing library or if both are a symptom of something else. A dependency package or contained file is not suddenly missing for no reason, we'll see 
.
Oh my gosh! I think that may have done it!
root@DietPi:~# apt install --reinstall libicu63
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 7,973 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://mirror.pit.teraswitch.com/raspbian/raspbian buster/main armhf libicu63 armhf 63.1-6+deb10u1 [7,973 kB]
Fetched 7,973 kB in 3s (2,972 kB/s)
(Reading database ... 24872 files and directories currently installed.)
Preparing to unpack .../libicu63_63.1-6+deb10u1_armhf.deb ...
Unpacking libicu63:armhf (63.1-6+deb10u1) over (63.1-6+deb10u1) ...
Setting up libicu63:armhf (63.1-6+deb10u1) ...
Processing triggers for libc-bin (2.28-10+rpi1) ...
root@DietPi:~#
Looks like I can access the webGUI now! Thanks! I might be imagining things but I vaguely recall trying to update dietpi through termius on my phone a while ago. This was after I switched to iOS 14. For some reason it didnt maintain a connection when i switched apps like it used to in ios 12. I wonder if that caused it? Regardless, i was able to successfully upgrade on my computer so i dont know if it was that.
A broken SSH session could indeed cause broken package installs, since when SSH connection is lost, the shell and its child processes are terminated.
GNU screen is great to prevent such: Screen - GNU Project - Free Software Foundation
apt install screen
Always wanted to implement this into DietPi, with an option to automatically open a screen session when connecting via SSH. That simply makes sense for so many reasons...
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.