5

I have bought three raspberry pi's with the intention of using them as temperature sensors throughout the building. I have bought the following models:

  • 1 raspberry pi 4 model b 2gb
  • 2 raspberry pi 4 model b 4gb (due to chip shortage 2gb were no longer available)

All of these are running the default Pi OS. however I noticed that the clocks on all of them cannot be synchronized with an NTP server. Which is kind of crucial or this to work.

I have tried the following:

  • turning on the ntp within timedatectl with sudo timedatectl set-ntp true after which I have restarted the systemd-timedated and systemd-timesyncd services.

  • specifying the same time server that all other machines sync to within our network as the NTP server

  • installed and enabled chrony and tried it that way (when this didn't work I purged it from the system)

  • installed ntp and ntpdate and tried forcing the sync.

  • reinstalled the Pi OS

When I ping 0.nl.pool.ntp.org it responds just fine.

None of these things can get the synchronization to work. Is there an alley which I have not yet tried. Or maybe some overaching reasons they can't sync?

EDIT: running timedatectl timesync-status gives me the following result:


Server: 84.31.172.97 (3.debian.pool.ntp.org)  
Poll interval: 1min 4s (min: 32s; max 34min 8s)  
Packet count: 0

result of ip a && ip r:


1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether e4:5f:01:4a:33:cf brd ff:ff:ff:ff:ff:ff
    inet 192.168.42.35/22 brd 192.168.43.255 scope global dynamic noprefixroute eth0
       valid_lft 687607sec preferred_lft 601207sec
    inet6 fe80::f2d5:f228:3c7b:86aa/64 scope link
       valid_lft forever preferred_lft forever
3: wlan0:  mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether e4:5f:01:4a:33:d1 brd ff:ff:ff:ff:ff:ff

default via 192.168.42.254 dev eth0 proto dhcp src 192.168.42.35 metric 202
192.168.40.0/22 dev eth0 proto dhcp scope link src 192.168.42.35 metric 202

The output of systemctl status systemd-timesyncd.service


 systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
  Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d
           └─disable-with-time-daemon.conf
   Active: active (running) since Thu 2021-09-23 13:58:24 CEST; 1h 22min ago
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 1154 (systemd-timesyn)
   Status: "Idle."
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/systemd-timesyncd.service
           └─1154 /lib/systemd/systemd-timesyncd

Sep 23 13:58:24 raspberrypi systemd[1]: Starting Network Time Synchronization...
Sep 23 13:58:24 raspberrypi systemd[1]: Started Network Time Synchronization.

Running nc -z -v -u 3.debian.pool.ntp.org gave the following result:

Connection to 3.debian.pool.ntp.org 123 port [udp/ntp] succeeded!

However when I connected it via WiFi to a mobile hotspot it took only 2 seconds and was instantly synchronized. So it seems like it is indeed an issue with the network.

Solution: After digging a little more into the network, I was able to find out that the problem lies in the packets being dropped because the time server didn't respond in time. By increasing the RootDistanceMaxSec to 15 seconds I was able to get it to synchronize

treskilion
  • 81
  • 1
  • 1
  • 7

8 Answers8

3

After digging a little more into the network, I was able to find out that the problem lies in the packets being dropped because the time server didn't respond in time. By increasing the RootDistanceMaxSec to 15 seconds I was able to get it to synchronize

treskilion
  • 81
  • 1
  • 1
  • 7
1

I think this is a locale problem. I had the same and I set the language back to English and it started to work again. When I have the language set to Swedish it does not sync. I checked the staus and it said it was in sync but "Recommended software" tried to sync and failed, despite the fact it actually did not.

Kent Grundström
  • 11
  • 1
1

As @treskilion mention, it is because of "root distance". solved here

/etc/systemd/timesyncd.conf:

[Time]
NTP=10.10.1.30
#FallbackNTP=
RootDistanceMaxSec=30
MatsK
  • 2,882
  • 3
  • 17
  • 22
Zbyšek Zapadlík
  • 111
  • 2
1

I had the same problem. I have a CAN interface that is configured via systemd-networkd.

systemd-networkd thinks the system is offline and therefore does not perform a sync the time with NTP. You can query the “Online state” with “networkctl status”. It should look like this:

| networkctl status

| ● State: routable

| Online state: online ^^^^^^

The old Systemd would like to have a better operational state for CAN Interface operational state for the CAN interface in order to recognize the interface as online and thus marking the entire system as online.

As of systemd-256 the problem is fixed. You can solve this in the old version manually by adding the following to the /etc/systemd/network/80-can.network file by adding the following:

/etc/systemd/network/80-can.network

...
[Link]
RequiredForOnline=carrier
...
mwroh
  • 11
  • 1
0

This almost certainly has nothing to do with the Pi.

Your /22 network is unusual (at least for a home network).

While everything appears to be working on the Pi you could try the netcat command suggested, but it may be more productive to contact your network administrator (some limit access to services).

You could try to connect to another network (e.g. a hotspot on your phone) which should work.

Milliways
  • 62,573
  • 32
  • 113
  • 225
0

Perhaps getting a RTC HAT and then MQTT the time to all otherboards? Only an alternative if no Network is available.

Nigel Trewartha
  • 1
0

I have the same problem related with sycronization. I'm new in Rasp Pie as well Please informe how can i type the following commands:

As @treskilion mention, it is because of "root distance". solved here

/etc/systemd/timesyncd.conf:

[Time] NTP=10.10.1.30 #FallbackNTP= RootDistanceMaxSec=30

Douglas Calzzetta
  • 1
0

This doesn't answer op question but I was face with a similar situation and setting RootDistanceMaxSec didn't work for me.

I'm using my device as a Pi-Hole server and I had taken it down for a short maintenance period. Once it rebooted, it tried to do a network time sync, but the DNS request was being blocked because it was unable to do a DNSSEC request as the time was out so Pi-Hole/Unbound responded with BOGUS flag on the DNS request.

So I got stuck in a catch-22 situation, can't sync time because it couldn't lookup the ntp server and pi-hole blocking dns requests with a BOGUS flag because the time was out...

Quick workaround; set the time manually eg:timedatectl set-time 14:44:44 then pi-hole will respond to DNS requests including future NTP requests.

Or, temporarily switch the DNS server on the pi to an external server, eg: 9.9.9.9 wait for the time to synchronise (check with timedatectl status, system clock sync will say "yes") then switch it back to the pi's ip address.

Hope this helps someone!

Faizal
  • 1