Please follow the below template, it will help us to help you!
Expected Behaviour:
Pi-Hole should remain Enabled when running.
Actual Behaviour:
Immediately after toggling to Enabled, Pi-Hole switches back to Disabled.
As we tracked down the last time this happened, this is due to duplicate "BLOCKING_ENABLED" entries in setupVars.conf, one set True and one set False.
The question is, how did I end up with two entries? This time around, it's a completely different install on a virtual machine (previous install was on a Pi3). The settings I'm using are the same, the only unique customization (with both installs) is that I implemented DNS-over-HTTPS following the guide here: Redirecting...
Permissions on setupVars.conf: -rw-r--r-- 1 root root 654 May 8 17:09 /etc/pihole/setupVars.conf
This time, it looks like it happened after a spontaneous reboot. Not sure (yet) what caused the reboot. I also don't remember if the previous incident occurred after a reboot.
As this seems to be related to UI interaction, would you share which browser your are using? It would also be interesting to know whether that was the same when this occured in July last year.
I am using the same browser, but I can re-create the switching-back-to-disabled behavior across Chrome, Safari, Firefox, and in Incognito windows.
I don't think it is the UI interaction itself that's directly causing the creation of the duplicate BLOCKING_ENABLED keys. Given duplicate keys, I think the resulting behavior is expected, but not correct.
My guess is that, when Blocking is enabled or disabled in this instance the sed deletes the first key, leaving the second in place, then adds another key, so we still have duplicate keys. When the file is re-parsed the last key is the one that's 'remembered'. My real concern is that a duplicate key is created in the first place. This should never happen - it should always only be replacing the single existing key.
A band-aid fix would be to make sed greedy and ensure it replaces all instances of an entry. IE - sed -ig "/BLOCKING_ENABLED=/d" "${setupVars}" (I think that's the right syntax, the added g says to operate across all instances). I don't like not knowing what's causing the duplication in the first place though.
As a point of comparison, I have none of these problems with either Pi-hole V4 or V5 beta, in any browser. Perhaps the problem is unique to your install.
Thank you for putting in the effort to research this a bit.
You are right, behaviour would be expected to be consistent over various browser platforms once the problem manifests itself (i.e. a second entry is already present).
My intention is indeed to track down that very first insertion.
My suspicion for that to be browser specific was a guess, which probably could be rejected if you had used members of different browser platforms (depending on you being able to clearly recall this, of course).
Would you be able to provide any hints at when this first happens (which may well be the second time you use some feature)? Can you recall which of the disable options from Pi-hole's UI have you been using?
Sorry for the long-time in replying. In both cases, the issue didn't seem to be directly related to something I did. I would try to use the internet and notice that I was having a lot of DNS lookup issues. After checking, I'd notice that PiHole was disabled. I know in the second case, the duplication started coinciding with an unscheduled reboot. I'm guessing that happened in the first case as well, but the logs have long since been lost for that.
I frequently do disable PiHole from the web UI for a few minutes to validate whether a site that's not working properly is due to being blocked by PiHole vs some other issue.