Debug log reports pihole-FTL daemon is inactive

[Mellbourn]

This is a...

• [ ] Request for a new or modified feature
• [x] Issue trying to run the docker image
• [ ] Issue trying to build / test / develop the docker image

Description

I've run pi-hole for years. Recently I decided to try to run it in docker. It seems to be working fine - blocking ads and serving DNS queries. However, when I run "Generate debug log" I get some unexpected results.

Expected Behavior

No errors in the debug log

Actual Behavior

I get this

*** [ DIAGNOSING ]: Networking
[✓] IPv4 address(es) bound to the eth0 interface:
   172.21.0.2/16 does not match the IP found in /etc/pihole/setupVars.conf (https://discourse.pi-hole.net/t/use-ipv6-ula-addresses-for-pi-hole/2127)

[✗] No IPv6 address(es) found on the eth0 interface.

[i] Default IPv4 gateway: 172.21.0.1
   * Pinging 172.21.0.1...
[✓] Gateway responded.

*** [ DIAGNOSING ]: Ports in use
[*:53] is in use by pihole-FTL
[*:53] is in use by pihole-FTL
[127.0.0.1:4711] is in use by pihole-FTL

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] smetn.com is 0.0.0.0 via localhost (127.0.0.1)
[✗] Failed to resolve smetn.com via Pi-hole (192.168.211.11)
[✓] doubleclick.com is 216.58.207.206 via a remote, public DNS server (8.8.8.8)

*** [ DIAGNOSING ]: Pi-hole processes
[✗] lighttpd daemon is inactive
[✗] pihole-FTL daemon is inactive

Debug token https://tricorder.pi-hole.net/h6y7p4iw6s

The 172.21.0.x problems are perhaps normal - internal docker adresses?

But the failed resolve and the inactive daemons are more worrying.

Weirdly, when I look at the processes with ps -ef it looks like these processes are running. Also, docker logs pihole seems to report that the daemons were started

Starting pihole-FTL (no-daemon) as root
Starting lighttpd

Possible Fix

Can I just ignore these errors?

Steps to Reproduce and debugging done

1. Start the raspberry pi
2. Navigate to the "generate debug log" page in the web admin
3. Generate log

Debug steps I have tried

• [x] I have tried destroying my container instance, pulling the newest image version, and re-creating a new container
• [ ] I have tried running the nearly stock docker run example in the readme (removing any customizations I added)
• [ ] I have tried running without my volume data mounts to eliminate volumes as the cause
• [x] I have searched this repository for existing issues and pull requests that look similar

I've tried rebooting the raspberry pi.

Context and extra information

Earlier today I did have a strange event: the raspberry pi, including pi-hole container, became impossible to connect to. I had to hard reboot it. When I checked the logs, it had been running the whole time.

I'm also running a secondary pi-hole as secondary DNS. But I don't see how this would affect the primary pi-hole.

Your Environment

• Docker Host Operating System and OS Version: Linux raspberrypi4docker 4.19.75-v7l+ #1270 SMP Tue Sep 24 18:51:41 BST 2019 armv7l GNU/Linux, Raspbian 10 (buster)
• Docker Version: 19.03.4
• Hardware architecture: ARMv7l

[dschaper]

The debug process is not designed or written for the docker environment. None of the results should be used as reliable information.

[PromoFaux]

~Huh, I could have sworn we patched that out of the Docker images... has it crept back in somewhere?~

My mistake, looks like it was just the update and help functions:

https://github.com/pi-hole/docker-pi-hole/blob/master/install.sh#L102-L104

[dschaper]

There are some changes made in https://github.com/pi-hole/docker-pi-hole/blob/master/bash_functions.sh but I don't remember offhand if debug was part of that.

As for @Mellbourn if you would like to open a bug report on pi-hole/pi-hole to work on the debugger script (either improve or disable in docker) we would appreciate it.

[diginc]

I think service is running command checks + the fake service wrapper for s6-svc = a bad time.

[dschaper]

Yeah, checking using any kind of init system tooling is going to be odd/wrong. But from my rusty memory I think I recall s6/s6-overlay may have something to use?

[diginc]

Yes, the fake service wrapper runs s6-svstat /var/run/s6/services/$service but the output is different than init's output.

Adding && echo 'is running' to the end of the s6-svstat may fix the debugger's detection since it wants grep -E 'is\srunning' to pass.

[dschaper]

That's an interesting approach. Really the debugger was intended to be a coarse and quick snapshot of what might be causing issues on a Pi-hole install. It was never intended to be a healthcheck or something to be run if everything is working.

[dschaper]

That said I think we could have a special version of the debugger (or a separate script entirely) that is for the docker environment and just copy that over the stock script during the creation of the image?

[diginc]

The log output in the existing debug script can be useful to docker still. I could see some unique checks for docker also being a benefit.

[dschaper]

How about changing the existing debug script to conditionally include an additional script if it's in the docker environment?

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.

[PromoFaux]

Can confirm this behaviour still exists on latest :dev container. Though it is just cosmetic:

pi@dockerpi:~ $ docker exec -it pihole pihole status
  [✓] FTL is listening on port 53
     [✓] UDP (IPv4)
     [✓] TCP (IPv4)
     [✓] UDP (IPv6)
     [✓] TCP (IPv6)

  [✓] Pi-hole blocking is enabled

How about changing the existing debug script to conditionally include an additional script if it's in the docker environment?

I've not read every comment on here, but seems there could be a solution proposed - We can test for the PIHOLE_DOCKER_TAG environment variable and add shims / disable things there, like we did for the ss command yesterday

[yubiuser]

Should be fixed by https://github.com/pi-hole/pi-hole/pull/5011

[yubiuser]

Fixed with https://github.com/pi-hole/pi-hole/releases/tag/v5.14