Pihole Dashboard stuck at 02:00h - and not moving

General Customizing Pi-hole
1

Hi,
I have installed pihole on MicroOS(.opensuse.org)
Everythings up and running, just the dashboard is stuck and does not display the queries etc over time. I'm pretty sure this is an authorisation problem since the process runs under pihole:pihole , but I have no idea where to look at.

Debug log: https://tricorder.pi-hole.net/29va1Wmb/
(ignore the the
fopen(/var/log/pihole/FTL.log): Failed to open stream: No such file or directory in /srv/www/pihole/admin/scripts/pi-hole/php/tailLog.php on line 34
messages - fixed in between)
pihole-ftl daemon is active as systemd-service

Versions:

  • Pi-hole [5.13+git.20221010T220047~17779ba]
  • FTL [5.18.2+git.20221010T215615~6f69dd5]
  • Web Interface [5.16+git.20221010T220044~c2afe42]

Any hint welcome!

2

Note that MicroOS/OpenSuse is not a supported OS.

Your debug log shows the time on your Pi-hole host machine to have jumped considerably:

*** [ DIAGNOSING ]: contents of /var/log/pihole

-rw-rw-r--. 1 pihole www 134K Oct 13 14:33 /var/log/pihole/pihole-FTL.log
   -----head of pihole-FTL.log------
   [2022-10-10 08:11:38.995 1657M] Using log file /var/log/pihole/pihole-FTL.log
(...)
   -----tail of pihole-FTL.log------
   [2022-10-04 00:00:31.812 723M] Database successfully initialized
(...)
   [2022-10-04 00:00:34.912 723M] New upstream server: 172.104.237.57:53 (1/512)
   [2022-10-13 14:32:43.323 723/T884] ERROR: Trying to access query ID 60, but magic byte is 0

The first entry dates from 2022-10-10, but towards the end of that file, the date has fallen back in time to 2022-10-04 and then suddenly switches back to 2022-10-13.

Fixing that timing issue would not only make your logs more reliable to interpret, it may also prevent Pi-hole's UI from reporting no or incorrect values as well as prevent complete DNS failures if DNSSEC would be enabled for Pi-hole.

In addition, Pi-hole's web UI would likely be unable to communicate with pihole-FTL, as that failed to bind its local API port:

   [2022-10-04 00:00:34.463 723M] Listening on port 4711 for incoming IPv6 telnet connections
   [2022-10-04 00:00:34.464 723M] Error binding to socket telnet socket: Permission denied (13)
3

I know :slight_smile: a community member has packed it for openSUSE, and we have been quite busy fixing small things

Thats probably because the Raspi 3, where it runs on, has no real-time clock. If chrony is a bit late that might be the reason. Will look into this, thanks!

OK...MicroOS' permissions are very strict. Will look into this as well!
Thanks!

4

If it runs as pihole:pihole , make sure its got the correct caps:

pi@ph5b:~ $ getpcaps $(pidof -s pihole-FTL)
25031: cap_chown,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_sys_nice=ep

pi@ph5b:~ $ man capabilities
[..]
DESCRIPTION
       For  the  purpose of performing permission checks, traditional UNIX
       implementations distinguish two categories of processes: privileged
       processes  (whose  effective user ID is 0, referred to as superuser
       or root), and unprivileged processes (whose effective UID  is  non‐
       zero).   Privileged  processes bypass all kernel permission checks,
       while unprivileged processes are subject to full permission  check‐
       ing based on the process's credentials (usually: effective UID, ef‐
       fective GID, and supplementary group list).

       Starting with kernel 2.2, Linux divides the  privileges  tradition‐
       ally  associated with superuser into distinct units, known as capa‐
       bilities, which can be independently enabled and  disabled.   Capa‐
       bilities are a per-thread attribute.

   Capabilities list
       The following list shows the capabilities implemented on Linux, and
       the operations or behaviors that each capability permits:

       CAP_AUDIT_CONTROL (since Linux 2.6.11)
              Enable and disable kernel auditing; change  auditing  filter
              rules; retrieve auditing status and filtering rules.
[..]

EDIT: Ow FYI, they are set here:

pi@ph5b:~ $ systemctl cat pihole-FTL
# /run/systemd/generator.late/pihole-FTL.service
# Automatically generated by systemd-sysv-generator
[..]
ExecStart=/etc/init.d/pihole-FTL start
ExecStop=/etc/init.d/pihole-FTL stop
ExecReload=/etc/init.d/pihole-FTL reload

pi@ph5b:~ $ grep -i cap /etc/init.d/pihole-FTL
    if setcap CAP_NET_BIND_SERVICE,CAP_NET_RAW,CAP_NET_ADMIN,CAP_SYS_NICE,CAP_IPC_LOCK,CAP_CHOWN+eip "/usr/bin/pihole-FTL"; then
      echo "Warning: Starting pihole-FTL as root because setting capabilities is not supported on this system"
5

I would not expect this to be the case. Time might wander a bit, but not suddenly jump 6 days.

1 Like
6

You could install fake-hwclock:
https://manpages.debian.org/bullseye/fake-hwclock/fake-hwclock.8.en.html

2 Likes
7

That helped, thanks for the hint!
(is available from Open Build Service as well)

8

Did installing fake-hwclock fix below error?

EDIT: Or did you disable IPv6 with sysctl ?

pi@ph5b:~ $ sysctl net.ipv6.conf.all.disable_ipv6
net.ipv6.conf.all.disable_ipv6 = 0
9

No, it fixed the error with the jumping times, as Bucking_Horn explained right before.
In order to fix this I tried to tie the pihole-FTL service to time-sync.target, but that is reached when the NTP daemon is up, but not when he has synced the time. I have given that to the experts:
https://bugzilla.opensuse.org/show_bug.cgi?id=1204313

Regarding Telnet access - have asked the package maintainer - I guess it is some cap authorisation

No, same result as you on that query

10

Aha well thanks for the update!
Also there are more places to disable IPv6:

pi@ph5b:~ $ sysctl -a -r disable_ipv6
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.eth0.disable_ipv6 = 0
net.ipv6.conf.lo.disable_ipv6 = 0