Hi!
After updating from DietPi 7.8.x to 7.9.3 (both on Bullseye) I encounter a problem with time syncing. When booting up for the first time after a few hours after poweroff date and time don’t seem to be updated anymore for some reason. Dietpi’s system date/time is the same as when it was powered off before. Running systemctl start systemd-timesyncd helps, but I have to do it manually.
Time syncing worked flawlessly before the Dietpi update in the same situations.
My router isn’t affected, my router still manages to receive the right time after powering it on. So it seems to be connected to the DietPi update.
The DietPi should not have any impact on the time sync service. What we did in one of the last release to don’t depend on time sync service anymore during boot. Means the service is running in background, not delaying the boot process. But it could take a minute or two to complete.
Could you share following 5 minutes after reboot
systemctl status systemd-timesyncd
journalctl -u systemd-timesyncd
Thank you very much for the quick reply.
I tested it this morning after all the devices were powered off during night.
Unfortunately DietPi didn’t sync its time in the background. Here are the logs as requested. I created them today at around 8:20 am after I powered on everything at around 8:00 am. But the system time is still set to 11 pm of the previous day when I switched everything off.
root@DietPi:~# systemctl status systemd-timesyncd
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Thu 2021-12-16 23:26:42 CET; 10min ago
Docs: man:systemd-timesyncd.service(8)
Process: 253 ExecStart=/lib/systemd/systemd-timesyncd (code=exited, status=0/SUCCESS)
Main PID: 253 (code=exited, status=0/SUCCESS)
Status: "Idle."
CPU: 278ms
Dez 16 23:25:04 DietPi systemd[1]: Starting Network Time Synchronization...
Dez 16 23:25:04 DietPi systemd[1]: Started Network Time Synchronization.
Dez 16 23:25:45 DietPi systemd-timesyncd[253]: Timed out waiting for reply from 10.0.0.1:123 (2.de.pool.ntp.org).
Dez 16 23:25:55 DietPi systemd-timesyncd[253]: Timed out waiting for reply from 10.0.0.1:123 (3.de.pool.ntp.org).
Dez 16 23:26:35 DietPi systemd[1]: Stopping Network Time Synchronization...
Dez 16 23:26:42 DietPi systemd[1]: systemd-timesyncd.service: Succeeded.
Dez 16 23:26:42 DietPi systemd[1]: Stopped Network Time Synchronization.
And:
root@DietPi:~# journalctl -u systemd-timesyncd
-- Journal begins at Thu 2021-12-16 23:25:03 CET, ends at Thu 2021-12-16 23:36:23 CET. --
Dez 16 23:25:04 DietPi systemd[1]: Starting Network Time Synchronization...
Dez 16 23:25:04 DietPi systemd[1]: Started Network Time Synchronization.
Dez 16 23:25:45 DietPi systemd-timesyncd[253]: Timed out waiting for reply from 10.0.0.1:123 (2.de.pool.ntp.org).
Dez 16 23:25:55 DietPi systemd-timesyncd[253]: Timed out waiting for reply from 10.0.0.1:123 (3.de.pool.ntp.org).
Dez 16 23:26:35 DietPi systemd[1]: Stopping Network Time Synchronization...
Dez 16 23:26:42 DietPi systemd[1]: systemd-timesyncd.service: Succeeded.
Dez 16 23:26:42 DietPi systemd[1]: Stopped Network Time Synchronization.
I’d really appreciate the previous behaviour of DietPi 7.8.x: I come home, power on my IT devices and can start surfing only a minute or less later. It worked like a charm for me and I didn’t notice any delay. Everything was up and working quickly. Now, i.e. after the update, I would need to wait an undefined period of time, if time sync works at all. But my network depends on my DietPi to have the current time because it is running a DNS resolver. The change even busted an important business call I had because it prevented that I could login to the online call. However, I understand your point, too. So, maybe you could introduce a config setting somewhere that allows to tell DietPI to update the system time instantly when booting (like it was before) or you could explain to me how I can change it manually for my system. 
the issue is not with the time sync service and how it behave. It’s more the time server not being reachable. As you can see, time sync is started correctly but timed out.
Dez 16 23:25:04 DietPi systemd[1]: Started Network Time Synchronization.
Dez 16 23:25:45 DietPi systemd-timesyncd[253]: Timed out waiting for reply from 10.0.0.1:123 (2.de.pool.ntp.org).
Dez 16 23:25:55 DietPi systemd-timesyncd[253]: Timed out waiting for reply from 10.0.0.1:123 (3.de.pool.ntp.org).
For me the IP address 10.0.0.1 seems to be strange as it is not the correct DNS resolution for 2.de.pool.ntp.org or 3.de.pool.ntp.org. Both NTP servers have completely different IP’s. Using dig command I get following
;; QUESTION SECTION:
;2.de.pool.ntp.org. IN A
;; ANSWER SECTION:
2.de.pool.ntp.org. 143 IN A 31.209.85.242
2.de.pool.ntp.org. 143 IN A 168.119.4.163
2.de.pool.ntp.org. 143 IN A 195.201.19.162
2.de.pool.ntp.org. 143 IN A 85.214.83.151
;; QUESTION SECTION:
;3.de.pool.ntp.org. IN A
;; ANSWER SECTION:
3.de.pool.ntp.org. 73 IN A 78.47.249.55
3.de.pool.ntp.org. 73 IN A 78.46.195.176
3.de.pool.ntp.org. 73 IN A 213.202.247.29
3.de.pool.ntp.org. 73 IN A 185.242.112.53
10.0.0.1 is pointing to some local network address. Is that your router? Do you power on your Router + DietPi at the same moment? Or is you Router online all the time? Did you set any manual DNS entries to resolve global NTP server as local IP?
10.0.0.1 is indeed strange. I use 192.168.x.x for my local network, DietPi uses a fixed, permanent 192.168.x.x address as well as, so my router does. Pretty common setup. The only 10.x address is used by a VPN client, but it’s 10.8.8.13 and running on my router, thus out of scope here. Pihole and unbound are running on my DietPi but that shouldn’t have any effect on the reachability of the time server at startup either. I checked the logs, unbound starts up with no errors. It just can’t resolve IPs due to the wrong system time. As soon as I manually start systemd-timesyncd on my Raspi to correct the wrong system time, DNS starts working again, too.
10.0.0.1 > is pointing to some local network address. Is that your router? Do you power on your Router + DietPi at the same moment? Or is you Router online all the time? Did you set any manual DNS entries to resolve global NTP server as local IP?
My Router and DietPi are always powered on and off at the same time. And I use an ethernet cable between my Router and my Raspi (DietPi), no wifi. This setup worked great for a long time. And my router still obtains the current time without problems. So, the problem must be located in my Raspi. And no, no manial DNS entries set for NTP.
What we did in one of the last release to don’t depend on time sync service anymore during boot. Means the service is running in background, not delaying the boot process. But it could take a minute or two to complete.
Could you share following 5 minutes after reboot
Could it be that? As it seems, now time-sync tries to connect to the NAT server, it fails (due to some unclear reason) and gives up for good.
Can you have a look inside dietpi-config what NTP server you have set?
As well can you check following entry?
cat /etc/resolv.conf
For testing, would it be possible to power up the router first, wait for 5 minutes to boot up an start DietPi afterwards. Once DietPi is online, check time server status after 1 or 2 minutes.
The problem seems to be with the DNS resolution for your configured NTP server. Maybe the internet connection is not fully up due to router start process.
“Networ Options: Misc” says
NTP Mirror: de.pool.ntp.org
Boot wait for network: On
G_CHECK_URL Timeout: 10 Seconds
G_CHECK_URL attempts: 2 Tries
Timezone: Europe/Berlin
As well can you check following entry?
cat /etc/resolv.conf
>
\
<br>
```text
nameserver 9.9.9.9
nameserver 9.9.9.10
I find that interesting. I would have guessed that these entries point to my Raspi/internal DNS resolver, but they point to Quad9 directly. But I don’t think this is the mistake because it worked before for over a year. I didn’t change these settings lately.
For testing, would it be possible to power up the router first, wait for 5 minutes to boot up an start DietPi afterwards. Once DietPi is online, check time server status after 1 or 2 minutes.
The problem seems to be with the DNS resolution for your configured NTP server. Maybe the internet connection is not fully up due to router start process.
Sure, I’ll do so and report back later. (It seems the internet connection isn’t fully up, but this was no problem at all for over a year before. it never faiiled at boot. Now it stopped working at each single boot up. So it must be more than just a small timing issue which depends on coincidence.)
Well, as long as your system is resolving the NTP server DNS incorrectly, it will fail to sync on boot. You would need to find out where these strange IP comes from.
Another test could be to use your router as NTP server. Some router provide such features.
Hi! First of all I am sorry for the long delay. It was Christmas and New Year holidays and then some hassle with my telecom provider.
Eventually, the problem is solved now. It was mainly based on a problem with the telecom provider. I even had a technician show up at my place to fix a problem with the sync of the modem. The parameters of the internet line were wrong and hence the modem sometimes could sync only after a while and sometimes after a few seconds. And that lead to the problems I suddenly faced.
So, as per now things work fine again.