In my household, all network devices (modem, router, Pi-hole, and WiFi AP) are connected to a single power strip with a remote-controlled switch. I typically turn these devices on and off once a day, with an average uptime of 1–3 hours. My Pi-hole runs on a Raspberry Pi Zero W 1.1 with Unbound and is connected via an Ethernet shield directly to the router.
Recently, I’ve noticed two potential issues related to this setup:
Gravity list updates:
I understand that Pi-hole updates its Gravity list automatically every Sunday at a specific time. However, if my devices are powered off during this period, the update doesn’t occur. Would missing these updates cause significant issues? I typically update the Gravity list manually every 1–2 months along with other system updates. Is this sufficient?
DNS request overload during startup:
During the holidays, I kept Pi-hole running for several days and noticed that it operated much more smoothly compared to my usual setup. Normally, when I turn on my network devices, many of them attempt to connect to the internet simultaneously, overwhelming Pi-hole with DNS requests. For example, my main router can send thousands of requests per minute during startup.
When Pi-hole runs continuously, this issue doesn’t occur, and its load remains consistently low, likely because DNS requests are spread out more evenly. Could this be caused by other factors besides my usage pattern, such as how my router or devices behave on startup?
This is not a major issue for me since everything works fine overall, but I wanted to share these observations in case others have experienced something similar or have any insights to offer.
If I had to guess, your modem may still negotiate your ISP connection while your router and AP (and possibly their clients) already start sending DNS towards your Pi-hole.
Pi-hole would only be able to forward allowed DNS requests to public upstreams once the modem is up, after which it will start receiving DNS replies.
But before ISP connectivity is established, clients DNS requests may already have timed out, so they'd start repeating them, which would contribute to a high initial DNS count.
Bringing up the modem before any other device may already allow Pi-hole to supply public replies immediately, but you may still see a initial surge of DNS requests.
Also, some time-outs may still occur, as unbound having to walk the entire recursion chain initially for yet unknown domains is considerably slower than retrieving a cached reply.
To prevent some of those initial DNS requests from registering with Pi-hole at all, you may also try delaying Pi-hole startup for the time it takes your modem to establish connectivity, see DELAY_STARTUP.
Thank you so much for the excellent comment! This could very well be the issue—that my modem is the last device to wake up, and a stable connection is only achieved a few minutes after all devices are powered on. I’ll try implementing the suggested delay for Pi-hole startup right away.
Could you also share your thoughts on the Gravity list updates issue I mentioned?
Edit: I measured how long it takes for my modem to establish a connection, and it takes around 2 minutes and 15 seconds.
Update frequency may vary wildly by blocklist, so a sound answer would to a good deal depend on your specific choice of blocklists, with Pi-hole's default update interval of once per week trying to strike a compromise.
That said, frequency often is around once or twice a week, but may occasionally also be once per day for a specific list during busy periods.
Once or twice a month seems a bit lazy.
To allow automatic gravity updates for your setup, you could consider editing Pi-hole's cron job (at /etc/cron.d/pihole) to start an update at a time where your Pi-hole machine is likely to run. However, you should note that you may have to reapply your changes after upgrading your Pi-hole release.
My number one priority is to increase the frequency of Gravity updates. I’ll likely have to handle this manually since the runtime for my Pi-hole setup varies so much. I’ll also make an effort to delve deeper into what Gravity updates actually do to better understand their significance.
As for the Pi-hole startup delay, it worked as expected! During the first two minutes, Pi-hole remained completely inactive, preventing an overload of DNS requests. I set the delay time to 2 minutes and 20 seconds, giving my modem plenty of time to establish a connection.
If it doesn't restart too often, you may want to have a look at the @restart flag performing an operation after each restart of the system. You could easily orchestrate that with some delay, e.g.,
Running a gravity update at every system start could indeed be a viable solution. However, it’s worth noting that the gravity update process does consume some of the Raspberry Pi’s processing power, which might temporarily impact Pi-hole's normal operation.
In my case, my blocklist is relatively large, containing around 1.4 million addresses. Updating this list takes about 5 minutes, during which the Raspberry Pi often experiences noticeable load spikes. Despite this, I’ll give the suggestion a try and see how it performs in practice. Thanks for the idea!
The gravity process is, however, single-threaded, so even when a CPU core is fully busy doing the gravity update, the other cores are still there to do other stuff. This obviously doesn't count if you have a single-core Raspberry Pi model, though...
I tried to create a cron file for updating Pi-hole according to the instructions. I used the command sudo systemctl status cron to check if the command was working, but I received the following error message:
Error: bad username; while reading /etc/cron.d/pihole-gravity-after-reboot
The error was likely caused by the missing username after the @reboot in the command. I determined the correct username using the whoami command and added it to the command as follows:
@reboot pi /usr/bin/sleep 300 && /usr/local/bin/pihole -g
After that, the cron file worked correctly, and Pi-hole was updated successfully after the reboot.