When set-system-time runs alongside chrony, it steps the system clock backwards from GPS time even though chrony is already synchronised. This is the same root cause as the (closed) #12 "set-system-time ignores chrony", but with a different and previously undocumented impact: the backward clock steps make Signal K silently discard incoming NMEA 2000 / CAN-bus data. Wind, position and AIS targets disappear from the data model until the Signal K server is restarted.
On a vessel this is a functional failure of the primary data feed, not just a wrong-clock nuisance.
Environment
Raspberry Pi OS Bookworm (Debian 12), Pi 4
@signalk/set-system-time v1.5.0
chrony 4.3, synchronised to a stratum-1 LAN NTP source (router with GPS) plus internet pool servers
The Set system time only if no other source is available (only chrony detected) option is enabled
Symptom
Each night, wind and position would be missing from the display in the morning; restarting the Signal K server (not the Pi) restored them.
Diagnosis
chrony is healthy and selected:
^* RUTX50.lan 1 6 377 17 -1356ns[-6199ns] +/- 2930us
Despite that, the plugin keeps setting the clock. Traced the date call to the plugin's own process:
sh -c date -u -s "2026-09-04 10:59:37"
parent: node .../signalk-server
with recurring backward steps in the journal through the night:
Time jumped backwards, rotating. (repeatedly, irregular intervals)
So useNetworkTime() is not detecting chrony reliably (as in #12), and the option to defer to another time source has no effect.
The impact (the new part)
The backward clock steps cause Signal K to reject fresh N2K data because the incoming timestamps become inconsistent with the rewound system clock. The data is still on the bus — confirmed with candump can0 showing the relevant PGNs arriving — but Signal K stops incorporating it. Only a server restart recovers it.
Net effect: with a perfectly good time source (chrony) already running, this plugin intermittently takes down the vessel's live navigation data.
Workaround
Disable the plugin and let chrony handle time, including GPS-derived time offshore via the router's NTP server. This fully resolves both the clock steps and the data loss.
Suggestion
Given the plugin has had no releases in over a year and useNetworkTime() chrony detection is still broken (#12), it would help to either fix the detection or document that the plugin must not be used alongside chrony.
Related to #12.
When set-system-time runs alongside chrony, it steps the system clock backwards from GPS time even though chrony is already synchronised. This is the same root cause as the (closed) #12 "set-system-time ignores chrony", but with a different and previously undocumented impact: the backward clock steps make Signal K silently discard incoming NMEA 2000 / CAN-bus data. Wind, position and AIS targets disappear from the data model until the Signal K server is restarted.
On a vessel this is a functional failure of the primary data feed, not just a wrong-clock nuisance.
Environment
Raspberry Pi OS Bookworm (Debian 12), Pi 4
@signalk/set-system-time v1.5.0
chrony 4.3, synchronised to a stratum-1 LAN NTP source (router with GPS) plus internet pool servers
The Set system time only if no other source is available (only chrony detected) option is enabled
Symptom
Each night, wind and position would be missing from the display in the morning; restarting the Signal K server (not the Pi) restored them.
Diagnosis
chrony is healthy and selected:
^* RUTX50.lan 1 6 377 17 -1356ns[-6199ns] +/- 2930us
Despite that, the plugin keeps setting the clock. Traced the date call to the plugin's own process:
sh -c date -u -s "2026-09-04 10:59:37"
parent: node .../signalk-server
with recurring backward steps in the journal through the night:
Time jumped backwards, rotating. (repeatedly, irregular intervals)
So useNetworkTime() is not detecting chrony reliably (as in #12), and the option to defer to another time source has no effect.
The impact (the new part)
The backward clock steps cause Signal K to reject fresh N2K data because the incoming timestamps become inconsistent with the rewound system clock. The data is still on the bus — confirmed with candump can0 showing the relevant PGNs arriving — but Signal K stops incorporating it. Only a server restart recovers it.
Net effect: with a perfectly good time source (chrony) already running, this plugin intermittently takes down the vessel's live navigation data.
Workaround
Disable the plugin and let chrony handle time, including GPS-derived time offshore via the router's NTP server. This fully resolves both the clock steps and the data loss.
Suggestion
Given the plugin has had no releases in over a year and useNetworkTime() chrony detection is still broken (#12), it would help to either fix the detection or document that the plugin must not be used alongside chrony.
Related to #12.