Hi all! I've expended all my research options so I'm turning to the forums here for a hand.
I'm onto my third Pi.hole setup, having had various issues with things, but loving it and working very solidly now aside from a few small gremlins. That said I have one key issue that has persisted across all three instances; Pi.hole does not boot properly after ANY shutdown/startup sequence, and I have to do sudo systemctl restart lighttpd
in the console and wait 5-10 minutes for it to start back up.
Pi.hole is running in an LXC container on Proxmox, both on the latest version(s). It was set up with Tteck's Proxmox Helper script, found here. It It is my DHCP server, but is otherwise quite default; I have two additional ad block lists in it and one 'block all' group for a few IoT devices.
Expected Behaviour:
On restarting Pi.hole, the container in Proxmox, or the Proxmox host itself, Pi.hole should start up, the console should show the 'welcome' page ending with root@pihole:~# [], and the web interface at http://ipaddress/admin/ should be accessible.
Actual Behaviour:
On any restart of Pi.hole, the console shows no text, only the cursor. The admin interface does not load, and, as Pi.hole is the DHCP server, there is no internet within the network to any devices. Pasting sudo systemctl restart lighttpd in the console and waiting eventually triggers Pi.hole to start, with the last line "you have mail." and the admin interface and internet is restored.
Debug Token:
NOTE: This happened a few days ago - I ran this command within 24 hours of last experiencing the issue and saved the output if required.
https://tricorder.pi-hole.net/yF9zktzX/
Additional Notes:
I do have this persistently shown under tools, but do not suspect it is related.
Warning in dnsmasq
core:
ignoring query from non-local network 169.254.246.245 (logged only once)
I have also had several small issues with DNS not resolving - most notably (and easiest to reproduce) is when updating gravity. Occasionally, doing so will simply return a DNS timeout. Previously this was persistent (and was the downfall of Pi.hole setup #2) but on this setup it only happens infrequently and has not persisted enough to warrant further investigation.