I spent a good chunk of time digging through various parts of pihole's source to track down some issues that I was having. Just for the benefit of myself, and obviously others, I'm going to write down the 2 issues I hit and how I fixed them.

This is the first one that I ran into. The baseline issue here was that the graphs/stats in the web interface weren't working. I could log in and use the web interface without issue, but no happy graphs.

I figured, correctly, that this was a file ownership/permissions issue so I spent a good amount of time poking around in /etc/pihole, /var/www/html, /opt/pihole and everything looked good as far as I could tell. I started digging through source code to figure out wtf was happening to render these graphs and it was, essentially, an API call to the running pihole-FTL binary.

This API call is done over the unix socket, and therein was the problem. The socket file, /run/pihole/FTL.sock, was set as 755 with pihole:pihole as owner:group. Changing that so it was group writeable fixed the issue for me.

At a later time, I hit a similar issue, but this time was the fact that I was missing the php-sqlite3 package and so the fpm process couldn't connect to databases.

I was using the external web API to temporarily disable ad blocking when it was needed and after an upgrade to the latest version of pihole, the temporary disable function just stopped working, and in an odd way.

I would actually make the call and get a 200 response with a payload of {“status”: “disabled”} (or something very similar to that). However, if I did a summary check right after, the summary would say that it was enabled. Odd… This was the exact same behavior in the web interface if I did a temporary disable there. The JS call would succeed and update the UI to say it was disabled, but if you refreshed the page, it would say that it was “Active”.

I spent a lot of time digging through the shell code in /usr/local/bin/pihole after running a pihole disable 300s on the command line and getting some odd output saying that pihole wasn't running, but that things were supposedly disabled. As a side note, when you call the web API, the action taken there is to just run the pihole shell script, so at least everything pointed at the script.

Digging through that code, there's a point where it wants to reload the DNS server (pihole-FTL) and that's where it seemed to be failing. With a little digging I found that it's trying to send a SIGHUP to the FTL server to trigger the reload to initiate the blocking as /etc/pihole/setupVars.conf is modified to enable/disable the blocking. It was failing to get the pid from the pid file.

It turns out that, when I was poking around and trying to figure out the previous problem, I manually ran pihole-FTL on the command-line, but did it as root. This meant that the pid file (at /run/pihole-FTL.pid) was owned by root. A quick chown pihole:pihole /run/pihole-FTL.pid plus systemctl restart pihole-FTL and everything was working properly once again.

Long story short for most *nix issues, always check your file permissions/ownership.