Skip to content

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

Description

@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
  1. 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
  2. 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions