Raspberry Pi Forums

Has anybody noticed that it takes a long time for the clock to set with Buster? From the time the desktop is up, it takes my 3B+ and 4 between 1:00 and 1:20 to set. I also noticed something else interesting, the Pi remembers when it was shut down and when it comes back it has that time until it updates. Is there something funky between network coming up and the time being requested?

Your RPi doesn't have an on-board clock (unless you add extra RTC hardware). So it uses fake-hwclock. That stores the time during shutdown and restores it during boot.

Once the network is alive systemd-timesyncd gets the time from an internet time server. It then polls, infrequently, to keep the clock close to the local time of day.

You can disable systemd-timesyncd and replace it with ntp if you need a more accurate clock. You can easily add an I2C RTC device for a few dollars.

DougieLawson wrote: ↑

Sat Sep 14, 2019 10:17 pm

Once the network is alive systemd-timesyncd gets the time from an internet time server. It then polls, infrequently, to keep the clock close to the local time of day.

I don't know how it knows the network is alive since systemd-timesyncd apparently normally uses systemd-networkd to determine that and systemd-networkd is not running in Raspbian. I couldn't figure it out but maybe you know?

pi@raspberrypi4B-1:~ $ sudo systemctl status systemd-networkd
● systemd-networkd.service - Network Service
Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled; vendo
Active: inactive (dead)
Docs: man:systemd-networkd.service(8)

It takes quite a while after boot for systemd-timesynd to update the time. One can restart systemd-timesyncd as soon as the desktop is up and get the system time updated within a few seconds.

The other interesting thing I found is that the clock in the toolbar that is part of the LXPanel updates very infrequently. It can take 20 or 30 seconds after systemd-timesyncd has synchronized the system time for the clock on the toolbar to show the correct time.

I think there is a timing issue between when the network is up and systemd-timesynd attempts to synchronize the time. I wrote a desktop entry and a script to restart systemd-timesyncd 10 seconds after the desktop is up. It works fine and the time is synchronized much quicker than otherwise. This also works if you change to ntp, you just restart ntp instead of systemd-timesyncd.

The desktop entry file:

[Desktop Entry]
Name=restart-clock
Type=Application
Exec=/home/pi/bin/restart-clock.sh


/home/pi/bin/restart-clock.sh:

#!/bin/bash
sleep 10
sudo systemctl restart systemd-timesyncd

The only question I have left is how does systemd-timesyncd know when the network is up?

It's highly likely that the first attempt for timesyncd to get the time could fail. I've not looked at the dependencies as I've disabled it in favour of good old NTP on all of my systems.

DougieLawson wrote: ↑

Tue Sep 17, 2019 4:39 pm

It's highly likely that the first attempt for timesyncd to get the time could fail. I've not looked at the dependencies as I've disabled it in favour of good old NTP on all of my systems.

I'm a fan of NTP as well. It has the same problem though with Buster. Something is off in the timing somewhere. I've got other computers running linux that never have the desktop come alive and not have the time synchronized. They are running NTP though.

knute wrote: ↑

Sat Sep 14, 2019 9:10 pm

Has anybody noticed that it takes a long time for the clock to set with Buster?

This issue is affecting several areas: Small piwiz race condition (time sync)

knute wrote: ↑

Tue Sep 17, 2019 2:53 pm

I don't know how it knows the network is alive since systemd-timesyncd apparently normally uses systemd-networkd to determine that and systemd-networkd is not running in Raspbian. I couldn't figure it out but maybe you know?
...
The only question I have left is how does systemd-timesyncd know when the network is up?

I don't think that systemd-timesyncd "uses systemd-networkd" to decide whether the network is up. Most likely, systemd-timesyncd simply tries to connect to the time server it wants to use (see /etc/systemd/timesyncd.conf). If it works, bingo! If not...network isn't up yet. I see it fail and take a while here as well.

I generally don't worry about it.

Besides systemd-networkd, as Dougie mentioned, ntp works quite well. I've been running chrony recently, just to see what it's all about. So far, so good, so for most of us it's probably a matter of personal preference.

bls wrote: ↑

Wed Sep 18, 2019 3:10 am

I generally don't worry about it.

When it breaks things that have been working for 5+ years, you have to worry about it.

NTP on Raspbian suffers from the same problem, that is not being up when the desktop gets up. It can take 20 to 30 seconds for the system clock to be synchronized and this is playing havoc with some folks programs that load with the desktop and need the current time.

I wrote a new script to check the network state and restart the time client. It just uses a ping to a time server pool and when it gets a response it knows that the network is up and restarts the time client. I call it with a Desktop Entry file in ~/.confg/autostart. It has reduced the delay from when the Desktop Entry script is run to when the time is synchronized from 25 seconds to 8 seconds. That is almost enough to not notice that it isn't up when the desktop is up.

RonR wrote: ↑

Wed Sep 18, 2019 3:40 am

bls wrote: ↑

Wed Sep 18, 2019 3:10 am

I generally don't worry about it.

When it breaks things that have been working for 5+ years, you have to worry about it.

Agree. I wasn't trying to make light of the issue, just my position on it for my use case.

Your workaround of checking that the remote time servers are available seems reasonable.

bls wrote: ↑

Wed Sep 18, 2019 5:49 pm

Your workaround of checking that the remote time servers are available seems reasonable.

My concern is that a workaround is necessary. An application (and especially a user sitting at a keyboard ) shouldn't have to first check (or risk getting a failure) that the system time is valid before running something (like 'apt' for example). An O/S should ensure that the user environment is ready before presenting it.

I just took a quick look at my pi4/buster system, and it appears that multi-user.target doesn't "want" systemd-timesyncd (or any other time service for that matter). systemd-timesyncd says it's wanted by sysinit.target. I didn't look further to see how sysinit.target and multi-user.target are related, though. It does seem that the system is getting to multi-user.target before the time service is fully initialized. How are other people dealing with the issue where a service is started, but not fully initialized, before mult-user.target?

RonR wrote: ↑

Wed Sep 18, 2019 6:04 pm

bls wrote: ↑

Wed Sep 18, 2019 5:49 pm

Your workaround of checking that the remote time servers are available seems reasonable.

My concern is that a workaround is necessary. An application (and especially a user sitting at a keyboard ) shouldn't have to first check (or risk getting a failure) that the system time is valid before running something (like 'apt' for example). An O/S should ensure that the user environment is ready before presenting it.

More often than not, I only notice the clock hasn't synced when I try to use a Web browser. Since security certificates rely on time, you can't do anything until the clock properly sets, and sometimes that's quite the nuisance, sitting there waiting.

So I found out some more interesting stuff. I thought that my Xubuntu box was updating the time much sooner than the desktop came alive. That is incorrect. Xubuntu is using systemd-timesyncd to update its system clock just like Raspbian and it takes about the same amount of time, 20 to 30 seconds. The big difference is my Xubuntu box has a RTC and so the time is very close when the computer starts and you don't notice the lack of current time. The Pi on the other hand has no RTC and so has to wait for the clock to be synchronized by systemd-timesyncd before a bunch of stuff will work correctly.

The Desktop Entry and the script I posted above will all shorten up that time to within a few seconds of the desktop being up, my timing found between 7 and 8 seconds. So the original script with the 10 second delay worked pretty good and the one that pings a NTP pool address is slightly faster getting down to the 7 or 8 seconds.

There is a really good couple of posts on this thread:
https://www.raspberrypi.org/forums/view ... 3&t=251611
by: ShiftPlusOne on clock startup and timing.