Setting FTLCONF_dns_port to something other than 53 causes the health check to fail

[nwctenor]

When setting the FTLCONF_dns_port environment variable, the container's healthcheck continues to run the dig command without changing the port to the new port number.

This is a: Bug

Details

In the environment section of my docker-compose.yml I have set "FTLCONF_dns_port: 5353". The healthcheck runs HEALTHCHECK CMD dig +short +norecurse +retry=0 @127.0.0.1 pi.hole || exit 1 which does not include the new port that FTL is running on. (This is based on the Dockerfile)

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: Virtual instance on Vultr
• Kernel Architecture: x86_64
• Docker Install Info and version:
  • Software source: OS provided package
  • Supplimentary Software:
• Hardware architecture: x86_64

2. docker-compose.yml contents, docker run shell command, or paste a screenshot of any UI based configuration of containers here
   name: dns
   services:
   pihole:
   depends_on:
   • dnscrypt
     env_file: "./.env"
     container_name: pihole
     hostname: pihole
     domainname: ##DOMAINNAME##
     image: pihole/pihole:latest
     ports:
   • "${WGSRV0_IPV4}:53:5353/tcp"
   • "${WGC0_IPV4}:53:5353/tcp"
   • "${WGSRV0_IPV4}:53:5353/udp"
   • "${WGC0_IPV4}:53:5353/udp"
   • "${WGC0_IPV4}:80:8080/tcp"
   • "${WGC0_IPV4}:443:8443/tcp"
     dns: 172.28.0.2
     dns_search:
   • ##SEARCH1##
   • ##SEARCH2##
     environment:
     TZ: 'America/Chicago'
     FTLCONF_webserver_api_password: '##PASSWORD##'
     FTLCONF_dns_listeningMode: 'all'
     FTLCONF_dns_upstreams: dnscrypt#5353
     FTLCONF_webserver_port: "8080r,8443s,[::]:8080ro,[::]:8443so"
     FTLCONF_dns_port: 5353
     #FTLCONF_dns.reply.host.IPv4: "10.9.0.2"
     FTLCONF_webserver_domain: "##DOMAIN##"
     volumes:
   • "pihole-etc:/etc/pihole"
   • "pihole-dnsmasq:/etc/dnsmasq.d"
     cap_add:
   • CAP_SYS_TIME
     restart: unless-stopped
     networks:
     dnscrypt-net:
     aliases:
     • "pi.hole"
     • "pihole"
       dnscrypt:
       container_name: dnscrypt
       hostname: ##Hostname##
       image: dnscrypt:latest
       dns:
   • 9.9.9.9
   • 1.1.1.1
     volumes:
   • "/docker/dns/dnscrypt/conf/conf:/config:ro"
     networks:
   • dnscrypt-net
     ports:
   • '##IP##:53:5353/tcp'
   • '##IP##:53:5353/udp'
     volumes:
     pihole-etc:
     external: true
     pihole-dnsmasq:
     external: true
     networks:
     dnscrypt-net:
     ipam:
     config:
     • subnet: 172.28.0.0/29
       aux_addresses:
       dnscrypt: 172.28.0.2
       pihole: 172.28.0.3
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.

I believe this will require the Healthcheck on the container to be updated to make use of the FTLCONF_dns_port environment variable, or use a script instead that could make use of a conditional statement regarding the FTLCONF_dns_port env var being present.

HEALTHCHECK CMD dig -port ${FTLCONF_dns_port} +short +norecurse +retry=0 @127.0.0.1 pi.hole || exit 1

[yubiuser]

Good idea. Implemented with #1746