StuffIveLearned.org

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== About ======
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.

===== Stats Not Working in Web Interface =====
==== The Issue ====
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.

==== The Fix ====
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.

===== Pihole Disable Not Working =====
==== The Issue ====
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".

==== The Fix ====
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.