Systemd-timesyncd NTP sync does not work after disabling/enabling

Technical Support
, , ,
1

There seems to be a problem with the included systemd-timesyncd in the default Toradex images.

Starting point: NTP sync is active and synchronised:

root@colibri:~# timedatectl status
               Local time: Sat 2026-03-21 14:41:21 UTC
           Universal time: Sat 2026-03-21 14:41:21 UTC
                 RTC time: Sat 2026-03-21 14:41:22
                Time zone: UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
root@colibri:~# timedatectl timesync-status
       Server: 152.53.102.196 (0.at.pool.ntp.org)
Poll interval: 34min 8s (min: 32s; max 34min 8s)
         Leap: normal
      Version: 4
      Stratum: 2
    Reference: A18F188D
    Precision: 1us (-24)
Root distance: 42.876ms (max: 5s)
       Offset: -40.444ms
        Delay: 4.490ms
       Jitter: 14.405ms
 Packet count: 8
    Frequency: -78.197ppm
root@colibri:~# timedatectl show-timesync
SystemNTPServers=0.at.pool.ntp.org
FallbackNTPServers=time1.google.com time2.google.com time3.google.com time4.google.com
ServerName=0.at.pool.ntp.org
ServerAddress=152.53.102.196
RootDistanceMaxUSec=5s
PollIntervalMinUSec=32s
PollIntervalMaxUSec=34min 8s
PollIntervalUSec=34min 8s
NTPMessage={ Leap=0, Version=4, Mode=4, Stratum=2, Precision=-24, RootDelay=640us, RootDispersion=42.556ms, Reference=A18F188D, OriginateTimestamp=Sat 2026-03-21 14:32:31 UTC, ReceiveTimestamp=Sat 2026-03-21 14:32:31 UTC, TransmitTimestamp=Sat 2026-03-21 14:32:31 UTC, DestinationTimestamp=Sat 2026-03-21 14:32:31 UTC, Ignored=no, PacketCount=8, Jitter=14.405ms }
Frequency=-5124706

Then disable/enable NTP:

root@colibri:~# timedatectl set-ntp 0
root@colibri:~# timedatectl set-ntp 1

Now, the status command still says active and synchronised, but the timesync-status subcommand actually shows, it isn’t doing anything:

root@colibri:~# timedatectl status
               Local time: Sat 2026-03-21 14:43:11 UTC
           Universal time: Sat 2026-03-21 14:43:11 UTC
                 RTC time: Sat 2026-03-21 14:43:11
                Time zone: UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
root@colibri:~# timedatectl timesync-status
       Server: n/a (n/a)
Poll interval: 0 (min: 32s; max 34min 8s)
 Packet count: 0
root@colibri:~# timedatectl show-timesync
SystemNTPServers=0.at.pool.ntp.org
FallbackNTPServers=time1.google.com time2.google.com time3.google.com time4.google.com
RootDistanceMaxUSec=5s
PollIntervalMinUSec=32s
PollIntervalMaxUSec=34min 8s
PollIntervalUSec=0
Frequency=0

I’m pretty sure, that the sync is dead, because if you set a custom date/time between disabling/enabling, it never goes back to synchronised.

Restarting systemd-timesyncd does not help. Only a full reboot of the device brings everything back to normal.

tdx-info:

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           6.6.119-7.5.0 #1 SMP PREEMPT Sat Dec  6 21:18:54 UTC 2025
Kernel command line:      root=PARTUUID=a1df1f49-02 ro rootwait console=tty1 console=ttymxc0,115200
Distro name:              NAME="TDX Wayland with XWayland Upstream"
Distro version:           VERSION_ID=7.5.0-build.11
Distro variant:           -
Hostname:                 colibri-imx6-11509212
------------------------------------------------------------
 
Hardware info
------------------------------------------------------------
HW model:                 Toradex Colibri iMX6DL/S on Colibri Evaluation Board V3
Toradex version:          0077 V1.1A
Serial number:            11509212
Processor arch:           armv7l
------------------------------------------------------------
2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

Based on your tdx-info output, you’re running TDX Wayland with XWayland Upstream version 7.5.0-build.11 on a Colibri iMX6DL/S. The issue you’re experiencing with systemd-timesyncd not properly resuming synchronization after disable/enable is a known behavior.

Understanding the Time Synchronization System

Your system uses systemd-timedated and the timedatectl command along with systemd-timesyncd to synchronize time with remote NTP servers(1). When using the timedatectl utility, time changes get stored into the hardware clock immediately(1).

Available RTCs on Your Module

On i.MX6 based modules like yours, there are 2 RTC drivers active(1):

[    1.798495] rtc-ds1307 2-0068: rtc core: registered m41t00 as rtc0  
[    1.818131] snvs_rtc 20cc034.snvs-rtc-lp: rtc core: registered 20cc034.snvs-rtc-lp as rtc1

(1)

The first one is the ultra-low-power RTC available on the carrier board, and the second one is i.MX6 SoC internal(1).

Troubleshooting Steps

1. Check systemd-timesyncd Service Status

First, check the actual service status:

systemctl status systemd-timesyncd

2. Manual Service Restart

Try restarting the service explicitly:

systemctl restart systemd-timesyncd

3. Check Service Logs

Examine the service logs for any error messages:

journalctl -u systemd-timesyncd -f

4. Alternative: Use hwclock Commands

If the systemd approach continues to have issues, you can use the traditional hwclock commands(1):

  • hwclock -r (Show hardware clock time)
  • hwclock -w (Set hardware clock from system time)
  • hwclock -s (Set system time from hardware clock)

5. Manual Time Setting

You can manually set the time and synchronize with the RTC(1):

timedatectl set-ntp false  
timedatectl set-time "2026-03-21 14:45:00"

When using timedatectl to set time, the systemd-timedated service ensures the new system clock is synchronized with the hardware clock (RTC) immediately(1).

Workaround

Given that a full reboot resolves the issue, this appears to be a service state management problem with systemd-timesyncd. As a workaround, you might need to implement a more thorough service restart sequence or consider using the traditional hwclock approach for your specific use case.

The behavior you’re observing where the service shows as “active” but isn’t actually synchronizing suggests the service may be in an inconsistent internal state after the disable/enable cycle.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.