Add additional test to 'pihole restartdns reload-lists'

I'm trying to get acquainted with group management, finally found a business case to implement a regex whitelist, used by certain devices only.

The group management documentation says:

Don't forget to run
pihole restartdns reload-lists
after your database modifications to have FTL flush it's internal domain-blocking cache (separate from the DNS cache).

So after I made changes, using the web interface, and / or using sqlite3 commands,
I run pihole restartdns reload-lists

I have a lot of gravity entries (currently 2.199.056) and some other custom dnsmasq config files. It takes a long time for pihole-FTL to start resolving names again after running pihole restartdns reload-lists

unfortunately, after executing the command, the prompt (pi@raspberrypi:~ $)
returns immediately.

pi@raspberrypi:~ $ pihole restartdns reload-lists
  [βœ“] Reloading DNS lists
pi@raspberrypi:~ $

I was looking for the cause, why, after running pihole restartdns reload-lists, I did NOT have DNS resolution. It took me a while, even rebooted my system a few times (impatient), to figure out pihole-FTL simply wasn't ready yet...

nslookup google.be
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  192.168.2.57

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out

Coming to the point now:
@DanSchaper: Would you consider to add the code, discussed here to the command pihole restartdns reload-lists, so the user knows DNS resolution is temporary unavailable?

Sure, if it's independently confirmed that this is because of Pi-hole.

And you don't need to @ me, I read all the posts.

Can a Beta5 user with a large blocklist please confirm this.

The test:

  • enter the command pihole restartdns reload-lists on the pihole prompt (putty or whatever)
  • open a cmd window on a windows machine that uses pihole as DNS
  • enter nslookup google.be
  • confirm there is a timeout (screenshot)
  • wait a while and repeat the test (nslookup google.be), repeat until it succeeds.

Thank you for your time and effort.

Apologies for coming back to this. NO OFFENCE INTENDED.

today I rebuild a test system, following the instructions provided.
I ran pihole checkout ftl new/CNAME_inspection_details, when this completed I ran pihole checkout web new/CNAME_inspection_details

As you can see, the second command failed:

pi@raspberrypi:~ $ pihole checkout ftl new/CNAME_inspection_details
  Please note that changing branches severely alters your Pi-hole subsystems
  Features that work on the master branch, may not on a development branch
  This feature is NOT supported unless a Pi-hole developer explicitly asks!
  Have you read and understood this? [y/N] y

  [βœ“] Branch new/CNAME_inspection_details exists
  [βœ“] Downloading and Installing FTL
  [βœ“] Restarting pihole-FTL service...
  [βœ“] Enabling pihole-FTL service to start on reboot...
pi@raspberrypi:~ $ pihole checkout web new/CNAME_inspection_details
  Please note that changing branches severely alters your Pi-hole subsystems
  Features that work on the master branch, may not on a development branch
  This feature is NOT supported unless a Pi-hole developer explicitly asks!
  Have you read and understood this? [y/N] y

  [i] Fetching branches from https://github.com/pi-hole/AdminLTE.gitfatal: unable to access 'https://github.com/pi-hole/AdminLTE.git/': Could not resolve host: github.com
  [βœ—] Fetching branches from https://github.com/pi-hole/AdminLTE.git

Again, this was caused by pihole-FTL simply NOT ready to resolve (Could not resolve host: github.com).

I really think, using the countdown timer routine, already in the code, to prevent resolver timeouts, whenever pihole-FTL is starting / reloading / … would improve pihole's reliability.

Unfortunately, nobody else appears to have a problem with this...

Once there's more than one data point then we'll take a look.

This issue should be eliminated with the most recent speed-up improvements coming to release/v5.0 after review:

1 Like