Hi!
I’ve updated pi-hole (with pihole -up) to current versions: Pi-hole v5.2.4 Web Interface v5.3.2 FTL v5.6
DNS resolving and blocking is still working, but it shows no stats on front page of web interface. Tried to reset cache of the browser, different browser, flush dns cache but nothing helps.
I’m running it on Odroid N2+ with DietPi v6.34.3.
Any ideas? Thanks.
Hi,
probably better to check on PiHole board why no stats are displayed. As well you could try to reboot your system. Somethimes it help.
Rebooted several times.
I’ve checked the pi-hole board for solutions, but noticed that if anyone mentions their OS is DietPi they immediately redirect them to MichaIng. So figured I could post right here.
DietPi is nothing else than a Debian. if I’m not mistaken for Odroid a Meveric image is used. At the end PiHole is installed using PiHole own scripts
For those stumbling upon this thread with the same problem:
Time is the culprit, I think the RTC battery of Odroid N2+ is causing some shenanigans, maybe together how DietPi is handling the time sync.
My so far workaround is to run after each update and reboot of the device:
systemctl start systemd-timesyncd
systemctl restart pihole-FTL
For some reason, restarting the device is not helping. Also if you only restart FTL service, it will not stick and soon will revert to not showing the stats again.
Hi,
usually time sync is done during system boot automatically as well as once a day. After reboot, can you check status of the service systemd-timesyncd. As well you could share time sync config cat /boot/dietpi.txt | grep CONFIG_NTP_MODE
CONFIG_NTP_MODE=2
What is the status of systemd-timesyncd right after reboot?
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; disabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
└─disable-with-time-daemon.conf
Active: inactive (dead)
Docs: man:systemd-timesyncd.service(8)
Feb 14 11:12:01 N2plus systemd[1]: Starting Network Time Synchronization...
Feb 14 11:12:01 N2plus systemd-timesyncd[2594]: System clock time unset or jumped backwards, restoring from
recorded timestamp: Fri 2021-02-19 01:25:02 CET
Feb 19 01:25:02 N2plus systemd[1]: Started Network Time Synchronization.
Feb 19 09:41:54 N2plus systemd-timesyncd[2594]: Synchronized to time server for the first time 147.251.48.140:123 (0.cz.pool.ntp.org).
Feb 19 09:41:54 N2plus systemd[1]: Stopping Network Time Synchronization...
Feb 19 09:41:54 N2plus systemd[1]: systemd-timesyncd.service: Succeeded.
Feb 19 09:41:54 N2plus systemd[1]: Stopped Network Time Synchronization.
as you can see, time sync succeeded on reboot. Means you system should have an actual system time after reboot
Yeah, I checked that. Yet, after every reboot I have to run it manually a restart FTL.
My understanding of Linux is very shallow, so I’m only explaining the functional workaround I managed to discover. No idea why is it happening as it does.
as I said, the system time should update itself on a reboot. it can be checked with date command. It should display correct system time right after boot. As well, systemd-timesyncd should have need succeeded
That’s only half of the truth: timesyncd syncs only once and then …
Feb 19 09:41:54 N2plus systemd[1]: systemd-timesyncd.service: Succeeded.
Feb 19 09:41:54 N2plus systemd[1]: Stopped Network Time Synchronization.
… exits.
I think the OP wants to start timesyncd on every boot and to keep timesyncd continously syncing. Therefore he needs to enable the service with the following command:
systemctl enable systemd-timesyncd
Barney
that’s not correct. The time sync succeeded and the service stop. That’s the expected behaviour.
To keep time in sync, there is a con job scheduled in background. According OP, he has set CONFIG_NTP_MODE=2 inside /boot/dietpi.txt (default value). Means, time sync is done on boot as well as on daily basis by /etc/cron.daily/dietpi.
You can check the daily time sync be running journalctl -u systemd-timesyncd.service
Maybe this is the expected behaviour under DietPi, but it’s not the expected behaviour under a Debian/Armbian system. The normal and expected behaviour under a Debian/Armbian system looks like this:
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
└─disable-with-time-daemon.conf
Active: active (running) since Tue 2021-02-23 11:16:28 CET; 6h ago
Docs: man:systemd-timesyncd.service(8)
Main PID: 726 (systemd-timesyn)
Status: "Synchronized to time server 10.91.25.1:123 (10.91.25.1)."
Tasks: 2 (limit: 4915)
CGroup: /system.slice/systemd-timesyncd.service
└─726 /lib/systemd/systemd-timesyncd
Feb 23 11:16:28 stx systemd[1]: Starting Network Time Synchronization...
Feb 23 11:16:28 stx systemd[1]: Started Network Time Synchronization.
Feb 23 11:16:30 stx systemd-timesyncd[726]: Synchronized to time server 10.91.25.1:123 (10.91.25.1).
Feb 23 13:16:29 stx systemd-timesyncd[726]: Synchronized to time server 10.91.25.1:123 (10.91.25.1).
Feb 23 15:05:06 stx systemd-timesyncd[726]: Synchronized to time server 10.91.25.1:123 (10.91.25.1).
Feb 23 16:52:19 stx systemd-timesyncd[726]: Synchronized to time server 10.91.25.1:123 (10.91.25.1).
The normal and expected behaviour under a Debian/Armbian system is to keep on running and continously syncing.
I hate it, when someone changes something without any need, just to be different from main stream. That’s the reason, why I’m leaving DietPi and stay with Armbian in the future.
Well you can change settings easily to be synchronised on an hourly basis. Which is even more that your so called standard.
The standard is to sync, when it is needed. So it depends on the accuracy of your internal clock: the more precise the clock, the longer the interval to sync. That’s always better than the stupid hourly sync.
FYI, after upgrade to 7.02 the problem went away.