System doesn't come up on any boot - must run sudo systemctl restart lighttpd

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.

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 (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.

This looks like a networking issue, rather than a Pi-hole one, and it may further be tied to your virtualisation environment. is a link-local IPv4 address.
I can't tell whether those would be normal for Proxmox, but note that link-locals are self-assigned, and would usually only show up if any other means of acquiring an IP address has failed, i.e. no BOOTP or DHCP server was accessible or provided a lease, and no static IP address configuration was present on the device itself.

As you intend to run Pi-hole as a DHCP server, you sure did define its proxmox environment for a static IP address, didn't you?

Definitely. My Proxmox host has a static IP:

And has almost all default options:
Other than that I configured it to start up first with no delay, should the host ever go down.

Notably, I can restart the Pi.hole without touching PvE and get the same result. That doesn't rule out Proxmox, just makes me think it's a Pi.hole issue when the host remains unchanged.

Didn't mention this before as I completely forgot, but the router is a standard old ISP TP-link, and it's relaying DHCP on, not hosting it's own DHCP server.

I wonder what's pinging the Pi.hole with the link-local IP... That I'll have to look further into, though gut says it's unrelated to this issue.

Since you have set a static IP, chances are that pihole-FTL could be up and running before your container's network stack has been fully initialised.
To mitigate this, you could try to add a DELAY_STARTUP to your pihole-FTL.conf.

While that could also contribute to your observation during container startups, its unlikely to explain:

What command do you use to restart Pi-hole?

I'm not familiar with Proxmox, but as you want Pi-hole's DHCP service, you probably should verify that your container allows for the required capabilities, specifically CAP_NET_ADMIN - see also Note on Capabilities.

PvE has a button to restart Pi.hole (or anything) and I usually use that - but I have tried reboot before with the same effect (though I should re-test this as I think that could have been back on Pi.hole #2.)
I'll see if I can work out how to do that - I'll admit, once we get into editing files, I get lost quickly as I have no idea where to put additions or even how to ensure they're saved properly (I barely worked out recently how to open a line via nano - and that has to be given to me ahead of time, no searching for this noob!)

I'm not familiar with Proxmox, but as you want Pi-hole's DHCP service, you probably should verify that your container allows for the required capabilities, specifically CAP_NET_ADMIN - see also Note on Capabilities.

I'll research this tomorrow - thank you for the lead! Will report back shortly. Hopefully that also gives some time for any other ideas to flow in too! Thank you and all!

So I'm not one hundred percent sure this is correct, but I found capsh --print and was able to see that the PvE cluster and the LXC container both appear to have CAP_NET_ADMIN (see example screenshot from the Pihole LXC console below) so I THINK that's okay.

I should add to this that I'm not one hundred percent sure that the service won't start on it's own whenever I reboot the Pi.hole; I do have to wait a bit after running the command anyway - it's just that, so far, whenever I've needed to reboot it or the host, it's been kinda urgent, so I jumped to the command immediately.

I can always do a test - there's a new router coming, so I could try it during downtime.

Other than that... Anyone have any other ideas? Cheers!

Update: I rebooted the Pi.hole LXC container and had two interesting things happen:

  • The Pi.hole came up on it's own at after about 5 minutes - the container itself was clearly up and I could see the timer in Proxmox - I did not run the above mentioned command
  • I still had internet on my desktop PC while it was down

To mitigate this, you could try to add a DELAY_STARTUP to your pihole-FTL.conf.

I added this line but I'm not convinced if it worked or not, as, when I opened it, it seemed empty? Could just be a config file that's there for your use if needed rather than something actively full of settings already. Docs seem to indicate this by opening with the line "you can create this to customise if needed."

On the still-having-internet thing... I did get a new router from a new ISP and wonder if it's doing some fallback DNS stuff in the absence of the DHCP relay. Uncertain about that at this time... But as I've lost internet with the Pi.hole down before, and didn't this time, I can only assume. Will try to sniff that out if I can.