System Details:
Operating System - Raspbian GNU/Linux 12 (bookworm)
PiHole - Core [v6.1.2] FTL [v6.2.3] Web interface [v6.2.1]
Hardware - RPi Zero 2 W (armv7l)
Expected Behaviour:
DHCP server active configuration setting (held in pihole.toml) should only be changed manually, or via the management GUI.
Actual Behaviour:
On occasion, I've found the above [dhcp] "active = true" setting gets reset back to false, the result of which is that a given Pi-hole node no longer provides DHCP services should that node become active.
Indeed, on more than one occasion, during a failover session, DHCP leases started to expire and devices started dropping off the network.
Details:
I'm running two identical Pi-hole configurations on Raspberry Pi Zero 2 W devices, in a failover mode using keepalived to manage the active node on a VIP address. This works well, and means DNS services continue should I need to do any maintenance on one of the Raspbery Pi devices.
I'm also using Pi-hole to provide DHCP services for my home network, with known devices being allocated fixed IP reservations. This makes sense for me rather than maintaining my network router as DHCP provider.
Since the update to V6, the DHCP configuration settings have been moved to the pihole.toml file, rather than /etc/dnsmasq.d, which is fine. The files on both nodes are configured with similar DHCP entries, including host reservations.
The DHCP server has been enabled on both configuration files, on the basis that should failover occur, the backup node will also provide DHCP services for my network; viz, in pihole.toml:
[dhcp]
# Is the embedded DHCP server enabled?
active = true ### CHANGED, default = false
As a precaution, I've also added a custom dnsmasq.d entry on the backup node, to delay responses, should pihole-FTL end up being active on both devices at the same time (for whatever reason).
$ cat /etc/dnsmasq.d/99-custom.conf
# Custom entries
#
# *** you must enable the misc.etc_dnsmasq_d setting in Pihole for this directory to be processed ***
#
# Add a delay to DHCP replies from this server (if enabled). This means this server can act as a
# backup DHCP server, since clients should only accept this offer if the primary server is down.
#
dhcp-reply-delay=2
Now to my problem.
On occasion, I've found the above [dhcp] active = true setting gets reset back to false, the result of which is that node no longer provides DHCP services should the node become active. Indeed, on one occasion, during a failover session, DHCP leases started to expire and devices started dropping off the network.
So what Pi-hole event is causing this update to the pihole.toml file, and why?
I've tried manually running each of the pihole cron entries, and that doesn't seem to trigger the file change, viz:
- pihole updateGravity
- pihole flush once quiet
- pihole updatechecker
However, following a reboot, I get the following change compared to my reference configuration.
$ ls -la /etc/pihole/pihole.toml*
-rw------- 1 pihole pihole 58179 Jul 11 16:47 /etc/pihole/pihole.toml
-rw-r--r-- 1 pihole pihole 58207 Jul 8 21:01 /etc/pihole/pihole.toml.REF
$ diff /etc/pihole/pihole.toml /etc/pihole/pihole.toml.REF
4c4
< # Last updated on 2025-07-11 16:47:53 BST
---
> # Last updated on 2025-07-04 20:28:57 BST
406c406
< active = false
---
> active = true ### CHANGED, default = false
1236,1237c1236,1237
< # 155 total entries out of which 138 entries are default
< # --> 17 entries are modified
---
> # 155 total entries out of which 137 entries are default
> # --> 18 entries are modified
So pihole is doing something on a reboot (via cron?), despite the pihole-FTL service not being enabled on that node.
Is it checking to see if there's already an active DHCP service on the network, and if so deciding it should disable any local setting that would start a potentially conflicting DHCP service? If so, I don't believe it should do so.
I'd appreciate if the developers would care to comment on this issue.
PS - my workaround for now has been to set up a cron entry, which regularly checks to see if the DHCP setting has been reset in the /etc/pihole/pihole.toml file, and if so restore the reference copy, and send a notification email to that effect.