I have two Pi-holes set up behind Nginx reverse proxies (facilitates SSL via step-ca). One got spammed by requests from a client last night, and I noticed when restarting the pihole-FTL service for a configuration change this morning that the web interface was inaccessible for a while afterwards - Nginx would return a 502 Bad Gateway error for a couple of minutes.
FTL.log showed that FTL loaded the database which took about two minutes, then parsed 400k queries in about 30 seconds, then started listening on the configured ports after a couple of seconds. So there was about 2.5 minutes where the web interface was inaccessible.
My read of this is that FTL would not be listening even without the reverse proxy setup. Trying to connect directly to the configured port shows this to be the case.
Prior to v6, the web interface would display errors if FTL was not running, which was a nicer and more informative experience. Any way to improve the current issue?
With Pi-hole v6, pihole-FTL now serves DNS as well as HTTP requests.
Your observation suggests that the web UI may benefit from pihole-FTL considering to start its web service before doing anything else, and/or make it unaffected by prolongued database access. If possible, that would likely require code adjustments.
In the meantime, you could consider to disable database imports on pihole-FTL restarts via database.DBimport, or to reduce the time frame to be shown on Pi-hole's dashboard via webserver.api.maxHistory.
Those options are available via Settings | All settings ยป Database and Webserver and API. All settings is available in Expert mode only.
Thanks, yes I think pihole-FTL starting its web service earlier would be an improvement. I know this is an unusual case (the other pihole, which wasn't getting spammed, got through all those steps in 20s), but any lag in user interface availability is problematic. Shouldn't need to dig through logs to determine that the normal load procedure is just taking a while. How can I suggest that change?
I already have the max long term history set to 24hrs. I think this was just an edge case of the login for one web interface timing out but not bouncing back to the login screen while the script to update stats continued running. The client with both interfaces open was sending DNS lookups to pihole A for the address of pihole B a few times a second for over 24 hours. I've seen that before on pihole v5 when I didn't have local-ttl set. It's not doing it anymore so I think it's sorted for now.