Hi!
After powering off my rPi for a few hours (e.g. night), DietPi doesn’t get the new time when powered on again. Rebooting DietPi doesn’t help. Wrong system time makes my DietPi behave as if there was no online connection (b/c unbound’s DNS resolution fails).
My work around: I stop fake-hwclock.service, manually type in the new time, start fake-hwlock and all things work fine again instantly.
Question: Do I have to install NTP and use ntpd to get the new time automatically during boot up or is there anything I can do with the tools aboard DietPi?
Yeah…is there a NTP setting to have it check at boot and every hour or so?
Yes, there is.
Try “ntpd -q -g [time server]”, e.g. as a cronjob at reboot. But this needs ntp to be installed.
I am wondering though if there is a way to update the system time without having to install ntp.
huidbui25
Actually DietPi uses the by default integrated systemd-timesyncd to update system time on boot. Please check: dietpi-config > Advanced Options > Time sync mode
You can run manually what this does at boot (and daily if chosen): /DietPi/dietpi/func/run_ntpd 1
Verify that this succeeds. If this somehow fails on boot, you could try the daemon + drift mode to enable systemd-timesyncd as daemon.
fake-hwclock.service btw should not be active, is it? It runs as oneshot during veeery early boot time to set the system clock to the one saved on last shutdown, long before network is established. This emulates a real hwclock moreless fine. At least you will not face 1970s timestamps until network is up 
.
Thank you. I didn’t know this command. I tried but unfortunately it doesn’t work either.
It says right after reboot (and system time is wrong):
root@DietPi:~# /DietPi/dietpi/func/run_ntpd 1
[ OK ] DietPi-Run_NTPD | Root access verified.
[ INFO ] DietPi-Run_NTPD | Concurrent execution of DietPi-Run_NTPD detected: Retry (0/5), please wait...
[ INFO ] DietPi-Run_NTPD | Concurrent execution of DietPi-Run_NTPD detected: Retry (1/5), please wait...
[ INFO ] DietPi-Run_NTPD | Concurrent execution of DietPi-Run_NTPD detected: Retry (2/5), please wait...
[ INFO ] DietPi-Run_NTPD | Concurrent execution of DietPi-Run_NTPD detected: Retry (3/5), please wait...
[ INFO ] DietPi-Run_NTPD | Concurrent execution of DietPi-Run_NTPD detected: Retry (4/5), please wait...
[FAILED] DietPi-Run_NTPD | Canceled DietPi-Run_NTPD due to concurrent execution
DietPi pops up the following window afterwards:
WARNING: Concurrent execution of DietPi-Run_NTPD detected │
│ │
│ Please check if one of the following applies: │
│ - This script already runs on another terminal/SSH session. │
│ - Currently a cron or systemd background job executes the script. │
│ - You started this script from within another DietPi program, causing a loop. │
│ │
│ Please assure that the concurrent execution has finished, before retrying, otherwise cancel this instance. │
│ │
│ The following info might help: │
│ 1517 root pts/0 \_ /bin/bash /DietPi/dietpi/func/run_ntpd 1 │
│ 1541 root pts/0 \_ /bin/bash /DietPi/dietpi/func/run_ntpd 1 │
│ 1006 root ? \_ /bin/sh -c /DietPi/dietpi/func/run_ntpd 1 │
│ 1007 root ? \_ /bin/bash /DietPi/dietpi/func/run_ntpd 1
I tried with DietPi-Config TimeSync modes “Boot + Daily” (error messages see above) and “Custom” … time update fails in both cases. My only guess would be that DietPi is continuosly trying to set the time (hence concurrent execution???) but fails due to impossible DNS resolution because unbound (my DNS resolver on my Raspberry Pi) doesn’t work with a wrongly set system time.
The working solution for me is a simple command in crontab:
@reboot /usr/bin/sntp -S 1.2.3.4
whereas 1.2.3.4 is the IP-address of a time server (not the domain name)
This just as feedback for you. I’m on DietPi 6.22.3, upgraded to Buster sid from Strech stable.
PS.: And yes, fake-hwclock.service is active, but I am quite sure I didn’t switch it on. It’s enabled by default at each reboot as it appears to me.
huidbui25
Jep fake-hwclock should be active/enabled by default:
systemctl status fake-hwclock
Jep obviously time sync fails on boot, please check:
systemctl status systemd-timesyncd
If DNS resolving does not work reliable on your system then this is most likely the reason since default NTP servers are: [0-3].debian.pool.ntp.org
Open: dietpi-config > Network Options: Misc > NTP mirror
- Either choose “custom” to add your custom time server IP,
- or choose “gateway”, if your router serves as NTP server, which is true in most cases and then the recommended setup,
- and replace your cron job by this.
Hello there,
i recently set up an ODROID XU4 with dietpi and pi-hole with active dnssec. Due to the daily time-sync, the dns queries all fail (BOGUS) because dnssec needs a valid time but dietpi can’t get a correct time because dns fails…
The reason I’m posting this here: The switch to “Gateway” in NTP Mirror helped to get rid of this problem and maybe its an option to ask for such a change in the pi-hole installation procedure?
Unfortunatly I have no idea what to do if there is no ntp server available, perhaps ataching a battery or an external RTC device helps.
Anyway: Thanks a lot for pointing me in the right direction here. You guys rock, dietpi is such a good OS for low budget hardware!
You’re aware you can buy an RTC for the XU$from hardkernel?
I have been having some issues with the restoration of time on a Pi4 on boot on a Raspbian system and noted a similar problem may occur with DietPi.
Both fake-hwclock and timedatectl systems save the current datetime periodically (and also on shutdown), but I was finding that on boot, especially if there was a hard power off, the 2 were in conflict, both restoring different times. timedatectl is more sophisticated as the frequency of the check with an NTP server is determined by the clock drift and is my preferred option.
I have ended up removing fake-hwclock from the system as it was not needed as timedatectl was enabled. I also changed the PollIntervalMaxSec to 300 in /usr/lib/systemd/timesyncd.conf to ensure the last save time was very recent.
My suggestion is that DietPi should remove fake-hwclock and just rely on timedatectl to manage time when option 4 is selected.
A menu item could be offered to modify the poll period.
baz123
Many thanks for reporting. I remember reading through some Debian bug report about conflicts between fake-hwclock and systemd-timeyncd, not sure if there has been some solution to reasonably resolve the conflict on testing (Bullseye). The issue with purging fake-hwclock is:
- DietPi by default has systemd-timesyncd disabled and only calls it on boot/daily/hourly (based on choice) to sync the time. As it consumes ~5 MiB RAM this is especially reasonable on low RAM devices.
- Even if systemd-timesyncd is enabled (based on choice: daemon mode), it may prevent itself from doing anything if another time sync daemon is present, e.g. ntp or chrony. AFAIK it as well does not store the system time to disk then, leading to 1970s time on boot.
So as of above, I prefer to stay with fake-hwclock installed by default. It cannot break anything, just lead to a max 1h past system time on boot, compared to a current systemd-timesyncd store. That is acceptable and should not break any internal tasks until network time sync is started.
I was looking for a way to easily check systemd-timesyncd condition result. The systemd unit prevents to start if if finds any known time sync daemon. Would be great if we could apply NTP choice “custom” in such case automatically, but I did not find a beautiful way to check this without actually starting the service. If we found a nice way, we can then also reliably know if systemd-timesyncd is really running and hence know whether fake-hwclock can be removed or not.
… Ah, just found another topic about this on RPi forum: https://www.raspberrypi.org/forums/viewtopic.php?p=1394683#p1615843
systemd-timesyncd starts too late at boot to assure that all tasks that require it have a moreless current system time, in this case systemd-fsck, but there might be others. Makes sense since it is a time sync daemon which requires network, while restoring system time from a save file does not require network and is basically a different task. Both tasks must run at different times.
Just checked it on current Raspbian Bullseye:
2020-05-18 14:52:24 root@micha:/mnt/sda# systemctl show -p Before,After systemd-timesyncd
Before=time-set.target sysinit.target shutdown.target
After=systemd-tmpfiles-setup.service system.slice systemd-sysusers.service tmp.mount systemd-remount-fs.service systemd-journald.socket -.mount
2020-05-18 14:52:32 root@micha:/mnt/sda# systemctl show -p Before,After fake-hwclock
Before=sysinit.target shutdown.target
After=systemd-journald.socket system.slice
systemd-timesyncd does not wait for network, but definitely waits for a few more services 
.
MichaIng Thanks.
One of the issues I had in debugging this was that fake-hwclock does not appear to log what it does on boot.
Timesync does store the date/time in /var/lib/systemd/timesync/clock (https://wiki.archlinux.org/index.php/systemd-timesyncd) and the rate it does that is configurable.
Yes, timesync does need a network to sync, but I think on boot it initially loads the stored time if it is the newest time it has. This is no different to fake-hwclock. However, I found fake-hwclock to unreliably save the current datetime at shutdown.
I was only suggesting the purge if the daemon method was selected i.e. as part of the switch to the daemon method.
Yes it needs to be the only timesync present, but again, this assumes the time control is being handled by the DietPi config. If anyone fiddles with that they deserve issues!
$ timedatectl show-timesync --all
Returns the datestamp of the last sync or else check the clock file Datestamp.
That item on the RPi forum is quite old - systemd has moved on. Of note is that fake-hwclock does not set the time-sync.target (renamed to time-set in Buster it seems) so services that rely on time, cannot use that to control startup. That it only needs to complete before sysinit.target also implies fake-hwclock may start later.
All I can say is that since purging fake-hwclock and reducing the timesyncd poll time to 60s, I have had far fewer issues with time at startup!
Has the time sync issue been resolved? I have tried literally everything in this topic and on internet and still cannot get current time from any server, router, wifi, santaclaus…
Hi,
usually there is no time sync issue. Pls can you check what the following give to you
/boot/dietpi/func/run_ntpd 1
systemctl status systemd-timesyncd.service
/boot/dietpi/func/run_ntpd 1 returns this:
...
[ INFO ] DietPi-Run_NTPD | Waiting for completion of systemd-timesyncd (60/60)
[ INFO ] DietPi-Run_NTPD | Timed out waiting for systemd-timesyncd
systemctl status systemd-timesyncd.service returns this:
● 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: active (running) since Wed 2020-09-09 14:17:01 CEST; 31s ago
Docs: man:systemd-timesyncd.service(8)
Main PID: 12362 (systemd-timesyn)
Status: "Connecting to time server 216.239.35.4:123 (time.google.com)."
Tasks: 2 (limit: 2013)
CGroup: /system.slice/systemd-timesyncd.service
└─12362 /lib/systemd/systemd-timesyncd
sep 09 14:17:01 DietPi systemd[1]: Starting Network Time Synchronization...
sep 09 14:17:01 DietPi systemd[1]: Started Network Time Synchronization.
sep 09 14:17:12 DietPi systemd-timesyncd[12362]: Timed out waiting for reply from 216.239.35.8:123 (time.google.com).
sep 09 14:17:22 DietPi systemd-timesyncd[12362]: Timed out waiting for reply from 216.239.35.0:123 (time.google.com).
sep 09 14:17:32 DietPi systemd-timesyncd[12362]: Timed out waiting for reply from 216.239.35.12:123 (time.google.com).
It doesn’t matter what server I use, the result is always the same.
Oh, I did not yet ask our IT guys if company’s firewall or router is blocking ntp packets.
Oh, I did not yet ask our IT guys if company’s firewall or router is blocking ntp packets.
Or you have a time server in your local network. But I guess your IT guys will know.
I hope there is a local time server, e.g. the router itself? Not uncommon and recommended especially for larger local networks so that not each and every client needs to sync with public time servers, which unnecessarily increases their load and sync time for all clients.
If otherwise network connection works fine, e.g. you can ping the time server you tested ping 216.239.35.4 then closed UDP port 123 would be my next guess as well.
It turned out our company’s network is the reason for time not syncing. Thanks for all your help.