resolver fails to resolve github.com before resolver started

[4-FLOSS-Free-Libre-Open-Source-Software]

results into stalled slow start, while rendering network unuseable

resolver fails to resolve github.com before resolver started, of course. A Classical chicken and egg problem.

This is a: BUG

Details

INFO: FTL branch: master
INFO: FTL version: v6.0.4
INFO: FTL commit: b7eb53bf
INFO: FTL date: 2025-03-04 17:22:10 +0000
INFO: FTL user: pihole
INFO: Compiled for linux/amd64 (compiled on CI) using cc (Alpine 14.2.0) 14.2.0

Related Issues

• I have searched this repository/Pi-hole forums for existing issues and pull requests that look similar

How to reproduce the issue

1. Environment data

• Operating System: Ubuntu
• Hardware: PC
• Kernel Architecture: amd64
• Docker Install Info and version:
  • Software source: official docker-ce, OS provided package
  • Supplimentary Software:
• Hardware architecture: amd64

2. docker-compose.yml contents, docker run shell command, or paste a screenshot of any UI based configuration of containers here

sudo  docker compose up --detach pihole

services:
  pihole:
  container_name: pihole
  image: pihole/pihole
  network_mode: host
  cap_add:
    - NET_ADMIN # In this case, the `NET_ADMIN` capability is added, which allows the container to perform various network-related tasks.
    - NET_BIND_SERVICE # Allows FTLDNS binding to TCP/UDP sockets below 1024 (specifically DNS service on port 53)
    - NET_RAW # use raw and packet sockets (needed for handling DHCPv6 requests, and verifying that an IP is not in use before leasing it)
    # - NET_ADMIN # modify routing tables and other network-related operations (in particular inserting an entry in the neighbor table to answer DHCP requests using unicast packets)
    - SYS_NICE # FTL sets itself as an important process to get some more processing time if the latter is running low
    - CHOWN # we need to be able to change ownership of log files and databases in case FTL is started as a different user than pihole
    - NET_BROADCAST # DHCP broadcast Make socket broadcasts, and listen to multicasts.
    - CAP_SYS_TIME # WARNING Insufficient permissions to set system time (CAP_SYS_TIME required), NTP client not available
    - CAP_SETGID
    - CAP_SETUID
  restart: unless-stopped
  # 	RAM shortage (/dev/shm) ahead: 99% used
  # /dev/shm: 268.1MB used, 268.4MB total, FTL uses 268.1MB
  # Set the shared memory size to 1G
  # Resizing "FTL-queries" from 1007648768 to (17997824 * 56) == 1007878144 (/dev/shm: 1.0GB used, 1.1GB total, FTL uses 1.0GB)
  # WARNING: RAM shortage (/dev/shm) ahead: 93% is used (/dev/shm: 1.0GB used, 1.1GB total, FTL uses 1.0GB)
  # add_message(type=7, message=/dev/shm) - SQL error step DELETE: database is locked
  # Error while trying to close database: database is locked
  # Resizing "FTL-queries" from 1007878144 to (18001920 * 56) == 1008107520 (/dev/shm: 1.0GB used, 1.1GB total, FTL uses 1.0GB)
  # WARNING: RAM shortage (/dev/shm) ahead: 93% is used (/dev/shm: 1.0GB used, 1.1GB total, FTL uses 1.0GB)
  shm_size: "2G"
  environment:
    FTLCONF_debug_caps: true
    PIHOLE_UID: 999
    PIHOLE_GID: 999
    FTLCONF_ntp_ipv4_active: false
    FTLCONF_ntp_ipv6_active: false
    FTLCONF_ntp_sync_active: false
    FTLCONF_dns_cache_optimizer: '0'
    FTLCONF_dhcp_rapidCommit: true
    FTLCONF_webserver_interface_theme: "default-auto"
    FTLCONF_webserver_interface_boxed: false
    PIHOLE_PTR: "HOSTNAMEFQDN"
    FTLCONF_misc_nice: "-1"
 volumes:
    - type: bind
      source: /etc/timezone
      target: /etc/timezone
      read_only: true
    - type: bind
      source: /etc/localtime
      target: /etc/localtime
      read_only: true
    - pihole:/etc/pihole/
  cpu_shares: 2048

volumes:
  pihole:

3. any additional info to help reproduce

These common fixes didn't work for my issue

• I have tried removing/destroying my container, and re-creating a new container
• I have tried fresh volume data by backing up and moving/removing the old volume data
• I have tried running the stock docker run example(s) in the readme (removing any customizations I added)
• I have tried a newer or older version of Docker Pi-hole (depending what version the issue started in for me)
• I have tried running without my volume data mounts to eliminate volumes as the cause

If the above debugging / fixes revealed any new information note it here.
Add any other debugging steps you've taken or theories on root cause that may help.

fatal: unable to access 'https://github.com/pi-hole/pi-hole/': Could not resolve host: github.com
fatal: unable to access 'https://github.com/pi-hole/web/': Could not resolve host: github.com
fatal: unable to access 'https://github.com/pi-hole/FTL/': Could not resolve host: github.com
  [i] Version info:
      Core version is v6.0.5 (Latest: N/A)
      Web version is v6.0.2 (Latest: N/A)
      FTL version is v6.0.4 (Latest: N/A)
INFO: ########## FTL started on docker! ##########
INFO: FTL branch: master
INFO: FTL version: v6.0.4
INFO: FTL commit: b7eb53bf
INFO: FTL date: 2025-03-04 17:22:10 +0000
INFO: FTL user: pihole
INFO: Compiled for linux/amd64 (compiled on CI) using cc (Alpine 14.2.0) 14.2.0

[yubiuser]

You did not provide enough information to debug your issue.
Try to not use the container as DNS server for the host/itself.

[4-FLOSS-Free-Libre-Open-Source-Software]

there is no resolver, pihole is the network wide resolver and DHCP server.

The resolving before resolver is ready perhaps should be delayed until resolver is fully started instead of delaying the start of the resolver itself.

[yubiuser]

there is no resolver, pihole is the network wide resolver and DHCP server.

There is. It's the one configured as for the host, but I guess in your case it defaults to itself/Pi-hole

https://docs.docker.com/engine/network/#dns-services

Try setting DNS for the container to an external DNS server in your compose file.

[PromoFaux]

Interesting.

We specifically wait until FTL is up and running (as told by the log file, at least) before attempting to run pihole updatechecker (which is the part outputting the error in your paste).

docker-pi-hole/src/start.sh

Lines 74 to 79 in 78aee9e

	# Wait until the FTL log contains the "FTL started" message before continuing
	while ! grep -q '########## FTL started' /var/log/pihole/FTL.log; do
	sleep 0.5
	done
	pihole updatechecker

Have you configured Pi-hole to have upstream resolvers, and are they reachable?

[yubiuser]

I think the check fails because some FTL is already running
See #1789