Time off by a few minutes

My system clock is off by a few minutes.

Here’s some info about my system:

timedatectl
               Local time: Tue 2023-10-17 21:48:08 CEST
           Universal time: Tue 2023-10-17 19:48:08 UTC
                 RTC time: Tue 2023-10-17 19:48:07
                Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no code here

System clock synchronized: no sounds like what I would want to get to yes

Most relevant, maybe, the output of this:

systemctl status chronyd
● chronyd.service - NTP client/server
     Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Tue 2023-10-17 21:52:38 CEST; 22s ago
       Docs: man:chronyd(8)
             man:chrony.conf(5)
    Process: 3968 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)
   Main PID: 3970 (chronyd)
      Tasks: 1 (limit: 19068)
     Memory: 15.3M
        CPU: 218ms
     CGroup: /system.slice/chronyd.service
             └─3970 /usr/sbin/chronyd -F 2

Oct 17 21:52:38 ffed chronyd[3970]: chronyd version 4.4 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6>
Oct 17 21:52:38 ffed chronyd[3970]: Frequency 0.000 +/- 1000000.000 ppm read from /var/lib/chrony/drift
Oct 17 21:52:38 ffed chronyd[3970]: Using right/UTC timezone to obtain leap second data
Oct 17 21:52:38 ffed chronyd[3970]: Loaded seccomp filter (level 2)
Oct 17 21:52:38 ffed systemd[1]: Started chronyd.service - NTP client/server.
Oct 17 21:52:38 ffed chronyd[3970]: Could not connect to 88.198.197.205:4460 (2.fedora.pool.ntp.org) : Connection refused
Oct 17 21:52:54 ffed chronyd[3970]: NTS-KE session with 88.198.200.96:4460 (2.fedora.pool.ntp.org) timed out
Oct 17 21:52:54 ffed chronyd[3970]: NTS-KE session with 167.235.228.35:4460 (2.fedora.pool.ntp.org) timed out
Oct 17 21:52:54 ffed chronyd[3970]: NTS-KE session with 85.214.38.116:4460 (2.fedora.pool.ntp.org) timed out
Oct 17 21:52:57 ffed chronyd[3970]: Could not connect to 88.198.197.205:4460 (2.fedora.pool.ntp.org) : Connection refused

Some answers I found here in the forum tell that I should first set the clock properly in the BIOS.
Next unusual thing: My Bios is coreboot, I don’t think that thing has a clock.

I’d be happy if I had second precision time via some time servers from the internet - as long as I’m connected to the internet.

Anyone knows how to do this? (Or why this is not working automatically?)
Thanks :slight_smile:

What is your hardware? Are you saying it does not have a RTC?
Could be interest to solve…

Your time is not sync’ed because your network is not working.
Once you have a working network then chronyd will be able to sync the time.

I am in middle of setting up a raspberry pi 4 as a router and hit a nice set of catch-22 issues.

On boot clock is not sync’ed, its about a month out.
DHCP gets a lease and the network comes up.
bind9 cannot do DNSSEC so hostname lookup is broken.
I work around that by putting an ip addr in chrony.conf
Now chronyd syncs the time and that makes the DHCP lease invalid and network dies as systemd-networkd does not renew the lease…

1 Like

RTC support has been in coreboot for years, but I don’t think coreboot provides a way to set the RTC at boot time, so (assuming the device has a RTC) you need to set the RTC from Fedora using `# timedatectl set-time [TIME]'. Chrony will handle large offsets if you get internet working.

1 Like

This part may be the issue. It seems your system is not able to connect to the time servers thus NTP cannot update your clock and sync the time.

Since it cannot get time from the internet it does not know if the rtc is local or utc which is why the last line of timedatectl does not show either yes or no – and why the clock is not synchronized.

Is the system connected to the internet when it boots?
Does DNS work?
It seems that chronyd was able to get at least some ip addresses but is not able to connect to the ntp servers.

Timedatectl shows an RTC time so that should not be a worry, but the failure to connect to the ntp servers is a worry.

1 Like

Secure connections use time to ensure there isn’t a man-in-middle delay, so the RTC needs to be “close enough”. Port 4460 is the NTS default. A firewall may block port 4460. Some sites provide internal time servers and deny access to internet servers.

1 Like

pool.ntp.org doesn’t support NTS. If you want to use NTS, you need to specify servers that support it. Here is a list of public servers with NTS support:
GitHub - jauderho/nts-servers: Time servers with NTS support

4 Likes

Hardware is a lenovo x230t - i guess it’s a safe bet the hardware has RTC capability.

Your time is not sync’ed because your network is not working.

Have written all these posts from said hardware. Network seems fine.
Not sure why chronyd shows time outs, etc.

so (assuming the device has a RTC) you need to set the RTC from Fedora using `# timedatectl set-time [TIME]'. Chrony will handle large offsets if you get internet working.

Thanks for the idea @gnwiii . Sounds plausible. Tried it, but did not work. :confused:

Thanks for the input @computersavvy

Can answer both with: yes. (internet connection via WIFI, not Rj45).

Thanks for the input.

What’s weird is: This is a failry fresh installation of fedora 38 (sway spin). Network time was not working after the installation. Same hardware, pluggin in a debian default installation and network time is working just fine. (not using chronyd but ntpd I guess.)

Anyway. I’d be happy to get to the bottom of this.

Last thing I tried: setting the time via

# timedatectl set-ntp no
# timedatectl set-time 08:47:33
# timedatectl set-ntp yes

to 1 or 2 seconds behin the real time. From the comments above (suspicion of man in the middle delay cautios behavior) did not help either… :confused:

You need to show us which servers are being used on the two distributions. Here, the first few lines of chrony.conf are:

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (https://www.pool.ntp.org/join.html).
pool 2.fedora.pool.ntp.org iburst

# Use NTP servers from DHCP.
sourcedir /run/chrony-dhcp

and the system is using 2.fedora.pool.org.ntp:

% journalctl -b -g ntp.org
Oct 18 07:42:25 X chronyd[911]: Selected source 67.215.197.149 (2.fedora.pool.ntp.org)
Oct 18 07:45:40 X chronyd[911]: Selected source 162.159.200.123 (2.fedora.pool.ntp.org)
Oct 23 02:15:02 X chronyd[911]: Selected source 67.215.197.149 (2.fedora.pool.ntp.org)
Oct 23 08:34:20 X chronyd[911]: Selected source 162.159.200.123 (2.fedora.pool.ntp.org)
Oct 23 13:27:04 X chronyd[911]: Selected source 67.215.197.149 (2.fedora.pool.ntp.org)
Oct 23 19:36:43 X chronyd[911]: Selected source 162.159.200.123 (2.fedora.pool.ntp.org)
Oct 27 01:45:25 X chronyd[911]: Selected source 67.215.197.149 (2.fedora.pool.ntp.org)
1 Like

Please show us the output of timedatectl

Thanks for your reply, @gnwiii.
On my fedora installation (wher network time is not working):

$ journalctl -b -g ntp.org | tail
Oct 31 16:46:35 fedo chronyd[3121]: Source 178.63.52.31 replaced with 85.220.190.246 (2.fedora.pool.ntp.org)
Oct 31 16:46:37 fedo chronyd[3121]: Could not connect to 85.220.190.246:4460 (2.fedora.pool.ntp.org) : Connection refused
Oct 31 16:46:55 fedo chronyd[3121]: Could not connect to 85.220.190.246:4460 (2.fedora.pool.ntp.org) : Connection refused
Oct 31 16:47:30 fedo chronyd[3121]: Could not connect to 85.220.190.246:4460 (2.fedora.pool.ntp.org) : Connection refused
Oct 31 16:48:36 fedo chronyd[3121]: Could not connect to 85.220.190.246:4460 (2.fedora.pool.ntp.org) : Connection refused
Oct 31 16:50:48 fedo chronyd[3121]: Could not connect to 85.220.190.246:4460 (2.fedora.pool.ntp.org) : Connection refused
Oct 31 16:55:07 fedo chronyd[3121]: Could not connect to 85.220.190.246:4460 (2.fedora.pool.ntp.org) : Connection refused
Oct 31 17:03:42 fedo chronyd[3121]: Could not connect to 85.220.190.246:4460 (2.fedora.pool.ntp.org) : Connection refused
Oct 31 17:18:21 fedo chronyd[3121]: TLS handshake with 185.207.105.38:4460 (2.fedora.pool.ntp.org) failed : Error in the certificate verification. The certificate is NOT trusted. The name in the certificate does not match the expected.
Oct 31 17:20:50 fedo chronyd[3121]: Could not connect to 85.220.190.246:4460 (2.fedora.pool.ntp.org) : Connection refused

Things I havent seen before here is the Source… replace thing and the TLS handshake that fails.

Here’s my chrony.conf:

$ cat /etc/chrony.conf
# These servers were defined in the installation:
pool 2.fedora.pool.ntp.org iburst nts

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (https://www.pool.ntp.org/join.html).

# Use NTP servers from DHCP.
sourcedir /run/chrony-dhcp

# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift

# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 second.
makestep 1.0 3

# Enable kernel synchronization of the real-time clock (RTC).
rtcsync

# Enable hardware timestamping on all interfaces that support it.
#hwtimestamp *

# Increase the minimum number of selectable sources required to adjust
# the system clock.
#minsources 2

# Allow NTP client access from local network.
#allow 192.168.0.0/16

# Serve time even if not synchronized to a time source.
#local stratum 10

# Require authentication (nts or key option) for all NTP sources.
#authselectmode require

# Specify file containing keys for NTP authentication.
#keyfile /etc/chrony.keys

# Save NTS keys and cookies.
ntsdumpdir /var/lib/chrony

# Insert/delete leap seconds by slewing instead of stepping.
#leapsecmode slew

# Get TAI-UTC offset and leap seconds from the system tz database.
leapsectz right/UTC

# Specify directory for log files.
logdir /var/log/chrony

# Select which information is logged.
#log measurements statistics tracking

The debian machine (same network, different hardware) uses 0.debian.pool.ntp.org and seems to connect fine.

When I change to use this server in my fedora machine, I get

Oct 31 17:29:37 fedo chronyd[23641]: Could not connect to 78.47.250.33:4460 (0.debian.pool.ntp.org) : Connection refused
Oct 31 17:29:37 fedo chronyd[23641]: Could not connect to 128.140.122.96:4460 (0.debian.pool.ntp.org) : Connection refused
Oct 31 17:29:37 fedo chronyd[23641]: Could not connect to 141.82.25.203:4460 (0.debian.pool.ntp.org) : Connection refused
Oct 31 17:29:54 fedo chronyd[23641]: NTS-KE session with 185.248.189.10:4460 (0.debian.pool.ntp.org) timed out
Oct 31 17:29:55 fedo chronyd[23641]: Could not connect to 78.47.250.33:4460 (0.debian.pool.ntp.org) : Connection refused
Oct 31 17:29:56 fedo chronyd[23641]: Could not connect to 128.140.122.96:4460 (0.debian.pool.ntp.org) : Connection refused
Oct 31 17:29:56 fedo chronyd[23641]: Could not connect to 141.82.25.203:4460 (0.debian.pool.ntp.org) : Connection refused

Thanks @computersavvy for your reply.

see here:

 timedatectl
               Local time: Tue 2023-10-31 17:30:54 CET
           Universal time: Tue 2023-10-31 16:30:54 UTC
                 RTC time: Tue 2023-10-31 16:30:55
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

Update: I changed the above line into
pool 2.fedora.pool.ntp.org iburst
I removed the nts part to make it similar to the snipped that @gnwiii has posted (thanks!). Network time with chrony is working now:

timedatectl
               Local time: Tue 2023-10-31 17:42:02 CET
           Universal time: Tue 2023-10-31 16:42:02 UTC
                 RTC time: Tue 2023-10-31 16:42:02
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

The nts thing seems to use encrypted communication (see wikipedia here)

Now that I see this, I have a rather faint memory that I checked a box with secure network time during the installation. It seems that this option is not working without issues.

Would it help to report this issue somewhere? In other words: is this a bug?

More like a trap for the unwary – people who configure for NTS are mostly in large organizations that have their own internal servers, and probably firewalls that block access to pool.ntp.org servers. It could be helpful to have the installer ask for servers(s) when users ask for NTS in a GUI,
but installer authors probably have more serious bugs to fix before they get around to this.

1 Like