startup of docker container needs more than 1min

[AlBundy33]

since one of the latest updates the startup of the docker container (pihole:latest) needs more than one minute. most of the time seems to be spend between this lines (output from docker logs)

[i] Installing latest logrotate script...
        [i] Existing logrotate file found. No changes made.
  [i] Custom WEB_PORT set to 3080

is it possible to speed this up?

[rdwebdesign]

Can you please:

• generate a debug log? and
• post the compose file or docker command used to start the container?

[AlBundy33]

docker-compose.yml

version: "3"

# More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/
services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    restart: always
    ports:
      - "192.168.1.111:53:53/tcp"
      - "192.168.1.111:53:53/udp"
      - "192.168.1.111:3080:3080/tcp"
    environment:
      TZ: 'Europe/Berlin'
      WEBPASSWORD: '´*************'
      PIHOLE_DNS_: '192.168.1.1;fd00::cece:1eff:fea8:6d0'
      #DNSMASQ_LISTENING: 'local'
      WEB_PORT: 3080
      DNS_BOGUS_PRIV: 'true'
      DNS_FQDN_REQUIRED: 'true'
      REV_SERVER: 'true'
      REV_SERVER_DOMAIN: 'fritz.box'
      REV_SERVER_TARGET: '192.168.1.1'
      REV_SERVER_CIDR: '192.168.1.0/24'
    volumes:
      - './etc-pihole/:/etc/pihole/'
      - './etc-dnsmasq.d/:/etc/dnsmasq.d/'

if the container is started all is working as expected - its just the startup that takes some time and im pretty sure that some versions ago the container was ready after some seconds.

[PromoFaux]

Hmm, this is unusual - and certainly unable to repro on my side.

Could you also please provide a debug token (pihole -d from within the container or use the tools menu on the web interface)

[AlBundy33]

https://tricorder.pi-hole.net/ARWRNTBb/

[AlBundy33]

adding a +x to basic-install.sh seems that a command pihole updatechecker remote seems to be the problem during startup. -> Note I've advertised pi-hole as default-dns in my network and therefore the updatecheck cannot work because it is not started yet

[AlBundy33]

remote update was introduced in 0d5a001916335cf4b27408217063ac9e04cc7e0d and this cannot work if pi-hole is the dns of the network

pi-hole starts much faster after removing the remote-line

[PromoFaux]

Ah, OK. Personally I would set the DNS of the container to be something other than 127.0.0.1 (perhaps 192.168.1.1 as with your rev server)

[AlBundy33]

I've already set

      PIHOLE_DNS_: '192.168.1.1;fd00::cece:1eff:fea8:6d0'
      WEB_PORT: 3080
      DNS_BOGUS_PRIV: 'true'
      DNS_FQDN_REQUIRED: 'true'
      REV_SERVER: 'true'
      REV_SERVER_DOMAIN: 'fritz.box'
      REV_SERVER_TARGET: '192.168.1.1'
      REV_SERVER_CIDR: '192.168.1.0/24'

With this setup all is working as expected:

• my clients are shown with their name on the dashboard (#135)
• lookup of all my hosts works in all containers and the docker-host

maybe you could introduce a new environment-variable to skip the remote-update?

[PromoFaux]

I mean the actual container (i.e overriding /etc/resolv.conf, rather than Pi-hole. e.g:

 dns:
     - 192.168.1.1

In a bare metal install we used to set 127.0.0.1 in /etc/resolv.conf, but this obviously falls over if FTL is not running for whatever reason. All your clients are using Pi-hole, which is then forwarding on, that's good... but the OS/Container that Pi-hole is running on should not rely on Pi-hole to do lookups, else you get stuck like you see.

That all said, I'll take a closer look at the docker scripts - maybe there is a more optimal place for this check

[AlBundy33]

Since the update is also executed in a running container it would be nice if the remote update could be moved after the startup :-)

[AlBundy33]

#1234 seems to fix this issue - i did an Update some minutes ago. after pulling the new image and recreating the container i had no issues resolving names.

Thanx @PromoFaux