Systemd-timesyncd "time out waiting for reply"

Troubleshooting
1

Hi there,

I’m using DietPi (5.4.72+ #1356) on a Raspberry PI Zero W.

I 'm getting this error when booting or restarting the time sync daemon:

DietPi Systemd-timesynched[1747]: Timed out waiting for reply from 108.161.151.187:123 (1.north-america.pool.ntp.org)

Multiple lines like this with different IP/DNS

From my windows machine, I can see those NTP server respond OK:

w32tm /stripchart /computer:1.north-america.pool.ntp.org /dataonly /samples:5

Suivi de 1.north-america.pool.ntp.org [199.101.100.221:123].
Collecte de 5 échantillons.
L’heure actuelle est 2020-11-22 11:22:28.
11:22:28, +00.0307804s
11:22:30, +00.0312482s
11:22:32, +00.0310455s
11:22:34, +00.0311427s
11:22:36, +00.0312408s

From the DietPi console, I can adequately ping those NTP servers, so not a connecting issue.

My time is a few seconds off from my windows 10 machine.

I also have the issue, maybe related to the time sync of never getting a prompt when connecting SSH from my Windows to DietPi

login as: root
root@192.168.10.3’s password:
Linux DietPi 5.4.72+ #1356 Thu Oct 22 13:56:00 BST 2020 armv6l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Any pointer would be appreciated.

Thanks! Simon

2

Hi

did you tried to change NTP server to the Global one pool.ntp.org? do you know if your internet router is providing NTP functionality as well? If yes, you could set NTP server to your Gateway.

3

Hi,

It was pointing to Global before with the same issue.

Then I re-installed everything with a recent image, disabling everything I did not need. This PiZ is only used for Node-Red + MQTT

I just tried to change the mode from 2 (boot+daily) to 3 (boot+daily), did to change anything.

Then tried mode 4, daemon + drift… Seems the time is closer to my PC now.
Yes my local router answers to NTP w32tm

Did a reboot, I still see timeouts but also errors “the unit file, source configuration file or drop-ins of systemd-timesyncd changed on disk, run 'systemctrl daemon-reload”…

So logged in and did “systemctl daemon-reload”… no feedback
Did another reboot…
Same error: “the unit file, source configuration file or drop-ins of systemd-timesyncd changed on disk, run 'sustemctrl daemon-reload”…

The boot process recommended: Systemctl -l status systemd-timesyncd for more info
Showing active but timeout on all NTP destinations

So I manually changed the /etc/systemd/timesyncd.conf to point only to my router IPv4
Reloaded with systemctl daemon-reload
The restarted the daemon : systemctl restart systemd-timesyncd
Then status… same issue, timeout reading my local router… even tough from my win10 PC, w32tm worked fine.

Seems the timesyncd process is broken?

I did a new install yesterday with fresh image from the web.

Any thoughts?

4

I went back to dietpi-config and changed the mode to 0 (custom).

Did a reload systemctl daemon-reload
and a restart : systemctl restart systemd-timesyncd
Then a status, I did get a synced after 2 timeouts !

Did a reboot, and status… timesync is loaded, but inactive.

Then did a start of the service and status…
Go a sync after 4 timeouts!

then enabled the service and reboot… seems to skip the sync at boot time.
Then did a status, only getting timeouts!

5

usually time sync is working well. There seems to be something special on your system.

To set NTP to point to your router, do following

dietpi-config > 8 : Network Options: Misc > NTP Mirror > Gateway

This will perform a check already to see if time sync is working

A manual time sync can be started as follow: /boot/dietpi/func/run_ntpd

6

ok Thanks, did those 2:

dietpi-config > 8 : Network Options: Misc > NTP Mirror > Gateway
/boot/dietpi/func/run_ntpd
no error

Then went back in dietpi-config and put time sync mode to boot+daily
Then re-ran /boot/dietpi/func/run_ntpd

I got the timeouts again. Weird

Here are 2 photos to capture the output, since I don’t have ssh working!

t2.jpg
t2.jpg927×697 227 KB

Time1.jpg
Time1.jpg741×651 338 KB

7

but you have a valid network connection from your DietPi device? Are you sure your WiFi is stable?

8

Thanks for the help!

I’m running from my Win10 PC a ping -t, with 0 drops and an average of 7ms to the Pi IP

From the Pi IP, a ping to google.ca give me an 8ms avg over 100 packets

My wifi is super solid on a gig connection to a fibre router running at 150Mbps

We have 4 working from home with no issues.

From what I understand, it’s not related to bad wifi.

I checked the power of the Pi, running fine at 5.1v Temp is also 31°C

Maybe I have bad hardware but I only have one Pi Zero and 1 SD card, so hard to test.

I have many ESP8266 on the same network talking to an MQTT server with no issues

9

strange that /boot/dietpi/func/run_ntpd is working one time but not a 2nd time, even if you target your internet router as NTP server. Usually staying inside local network should be quite fast.

can you scan journalctl to see if there is anything special

10

I would also investigate with tcpdump on dietpi and wireshark on windows whether the ntp packets are indeed sent received properly.

11

trendy Thanks for the tips for tcpdump… been a decade since I used that!

It showed

  1. that my local router does not respond to NTP, like I thought it would
  2. Going by to north-america.pool.ntp.org it worked! Never did before?

07:38:23.343061 IP 192.168.10.3.42408 > paladin.latt.net.123: NTPv4, Client, length 48
07:38:23.429515 IP paladin.latt.net.123 > 192.168.10.3.42408: NTPv4, Server, length 48

So unsure why it did not work before.

Then I did a restart of network time sync:

root@DietPi:~# /boot/dietpi/func/run_ntpd
[ OK ] Network time sync | Completed

But tcpdump did not show any traffic after this

Then tried systemctl restart systemd-timesyncd.service
tcpdump showed traffic and good connection:

07:44:34.299059 IP 192.168.10.3.60448 > titan.crash-override.org.123: NTPv4, Client, length 48
07:44:34.352816 IP titan.crash-override.org.123 > 192.168.10.3.60448: NTPv4, Server, length 48

12

Maybe the ntp is down or listening to another port? There are different time servers available listening to different ports.

13

On some router NTP server functionality needs to be activated explicitly.

But as I understood, NTP time sync is working with global NTP server now.

14

I always change my NTP servers to pool.ntp.org, it automatically finds servers…good call on this!

15

Personally I’m using my internet router. Much faster :wink: