Dashboard status says "offline" but is working

[weitzner]

The dashboard has a status of "offline" but everything seems to be working.

Connecting to the container and checking out /etc/sudoers.d/pihole shows the same formatting as described here, but I am unsure if that is something that can be changed here or needs to be looked into upstream.

[juampe]

I ever update from mainstream, the container add s6 layer and unbound configurations. I relelase updated versions. I hope it was fixed from mainstream.

[weitzner]

Seems to still be broken - I'll check in with upstream

[juampe]

From my point of view It seems to be a regression in new edge version
My actual setup

Updating to juampe/pihole-dot:edge the problem was evident

[juampe]

As described in your link, my actual setup have this sudo file and seems to work without "special spaces"

root@pihole:/# cat /etc/sudoers.d/pihole
# Pi-hole: A black hole for Internet advertisements
# (c) 2017 Pi-hole, LLC (https://pi-hole.net)
# Network-wide ad blocking via your own hardware.
#
# Allows the WebUI to use Pi-hole commands
#
# This file is copyright under the latest version of the EUPL.
# Please see LICENSE file for your rights under this license.
#
www-data ALL=NOPASSWD: /usr/local/bin/pihole

But the diference was huge
My setup

root@pihole:/# sudo -u www-data sudo pihole status web
1
root@pihole:/# 

edge

root@pihole:/# sudo -u www-data sudo pihole status web

root@pihole:/# 

But the problem is not sudo mechanism itself, the problem is the pihole script.

root@pihole:/# pihole status web

root@pihole:/#

[juampe]

AFAIK the regression is in this commit
pi-hole/pi-hole@ef30a85

[weitzner]

Oh interesting!

[PromoFaux]

I've not looked deeply into this yet, but AFAIK this is not an upstream issue - as I don't see it in our nightly or Dev containers (or even bare metal)

I suspect the issue may lie in how your image switches branches on the components but... I'll take a look after work!

[juampe]

Some additional test
add debug to script in edge

#!/usr/bin/env bash
set -xe
----8<----
+ case "${1}" in
+ statusFunc web
+ local listening pid port
++ getFTLPID
++ local pid
++ '[' -s /run/pihole-FTL.pid ']'
++ pid=508
++ [[ 508 =~ [^[:digit:]] ]]
++ echo 508
+ pid=508
+ [[ 508 -eq -1 ]]
++ echo '>dns-port >quit'
++ nc 127.0.0.1 4711
+ port=
+ [[ '' == \0 ]]
+ [[ web != \w\e\b ]]
+ grep -q BLOCKING_ENABLED=false /etc/pihole/setupVars.conf
+ grep -q BLOCKING_ENABLED=true /etc/pihole/setupVars.conf
+ case "${1}" in
+ echo ''

I see that the status changes using the enable/disable bloking buttom, an the unknow status doesn't appear anymore

Now the BLOCKING_ENABLED is in the /etc/pihole/setupVars.conf file.
I can conclude that the lack of status is due to the environment variable in the configuration file (BLOCKING_ENABLED)
To fix in our work we can recomend to set BLOCKING_ENABLED as environment in the container process run.

[PromoFaux]

Ah wait, this rings a bell...

It should already be fixed in the development branch of Pi-hole core ----repository (and thus should be fixed in the nightly image of Pi-hole docker which pulls in all the dev branches.

---

Just as a secondary point here (and maybe it is worth a new issue ) I'm not sure I understand why you are re-downloading FTL as in each of your Dockerfiles - the upstream image is multiarch and already contains the correct binary. It appears that, maybe unintentionaly, in your nightly image you are overwriting the dev version of FTL with the released one. Same goes for the other components in the edge version

• pihole/pihole:nightly already has the development versions of each core component checked out, shouldn't need to do anything here
• pihole/pihole:dev uses only the dev branch from docker-pi-hole repository, but otherwise the core components are the currently released versions
• pihole/pihole:latest is the master branch of docker-pi-hole, and the released versions of everything else.

[juampe]

OK, we trust in upstream containers, so as you commented is not necesary update from git.
I disabled the update scripts to respect the upstream release decisions.

[PromoFaux]

To the title issue, however, I don't think your solution will work :)

There is nothing in the upstream to parse the env var BLOCKING_ENABLED. When was the last time your containers were built? The only one that it should have been an issue in was edge and nightly, but the fix to add BLOCKING_ENABLED if it did not already exist was added into the core repo last week sometime.. so I'd be interested if you were still able to reproduce it with all the latest changes :)

[juampe]

Thanks, let's go to some deep insight.
I triggered the github action an hour ago, and new edge is built.
The status function seems not to handle right the situation

root@pihole:/# cat /etc/pihole/GitHubVersions
v5.8.1 v5.10.1 v5.13
root@pihole:/#
root@pihole:/# cat /etc/pihole/setupVars.conf|grep BLOCK
BLOCKING_ENABLED=true
root@pihole:/# pihole status web

root@pihole:/#

DEBUG RUN

+ [[ 2 = 0 ]]
+ case "${1}" in
+ [[ ! 0 -eq 0 ]]
+ case "${1}" in
+ statusFunc web
+ local listening pid port
++ getFTLPID
++ local pid
++ '[' -s /run/pihole-FTL.pid ']'
++ pid=501
++ [[ 501 =~ [^[:digit:]] ]]
++ echo 501
+ pid=501
+ [[ 501 -eq -1 ]]
++ echo '>dns-port >quit'
++ nc 127.0.0.1 4711
+ port=
+ [[ '' == \0 ]]
+ [[ web != \w\e\b ]]
+ grep -q BLOCKING_ENABLED=false /etc/pihole/setupVars.conf
+ grep -q BLOCKING_ENABLED=true /etc/pihole/setupVars.conf
+ case "${1}" in
+ echo ''
  <-\n @THE STATUS RETURN NOTHING
root@pihole:/#

In my run, the line 330 does no return the port, so in line 355 returns nothing

#get the port pihole-FTL is listening on by using FTL's telnet API
    port="$(echo ">dns-port >quit" | nc 127.0.0.1 4711)"

Some additional netcat tests, that returns nothing

root@pihole:/# netstat -putan|head
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.11:35887        0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.1:8953          0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.1:4711          0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:5353            0.0.0.0:*               LISTEN      -

root@pihole:/#  echo ">dns-port >quit" | nc 127.0.0.1 4711
root@pihole:/#
root@pihole:/# echo ">dns-port >quit" | nc 127.0.0.1 4711 |echo $?
0
root@pihole:/#

And to finish some suggestion/fix go get something useful
port="$(echo ">dns-port >quit" | nc 127.0.0.1 4711|echo $?)"

TEST RUN

root@pihole:/# pihole status web
1
root@pihole:/#

And the status come active again

[PromoFaux]

Your edge tag is based on our dev tag which, in turn has the release versions of the Pi-hole, which do not contain the aforementioned PR that fixes the check for the case of a missing BLOCKING_ENABLED

Do you still see this issue in your nightly tag?

[juampe]

I see the issue in the nightly tag

root@pihole:/# pihole status web

root@pihole:/#
root@pihole:/etc/pihole# cat /etc/lighttpd/conf-enabled/15-fastcgi-php.conf|grep DOCKER
                        "PIHOLE_DOCKER_TAG" => "nightly",
root@pihole:/#

[PromoFaux]

Hummm. The only thing I can see here that might (not certain here as I'm working on theory!) be causing an issue. According to your version footer there, both Pi-hole core and Web are on the dev branches - but FTL is just on the mainstream v5.11 release.

I am not seeing the same issue on the latest upstream :nightly with the following versions

[juampe]

OK, sorry was my fault, I forgot commit changes to not update from git.
The nightly and edge/dev are OK

root@pihole:/# pihole status web
53
root@pihole:/#

[yubiuser]

The reason it works now is pi-hole/FTL#1264

This is not in master yet, but development only.

[juampe]

Solved in master