I am trying to determine the best way to set Chrony time manually when our devices aren’t connected to the internet. Our devices have a GNSS and RTC but those peripherals are not directly connected to the processor running Balena. I would like to check for NTP sync from Chrony via dbus and if sync hasn’t occurred then set the time manually with the RTC state which is being updated via the GNSS.
I have read several posts here that talk about setting time manually but they don’t seem to use Chrony to do that and my understanding is it’s better to use Chrony since it helps address large shifts in time via speeding up or slowing down the system clock.
Hi Darren, if I understand correctly, your system has separate processors. One of them is running balenaOS and keeping the time in sync with chrony. Another processor has access to an RTC and GNSS. And you want the second processor to query for time synchronisation in balenaOS via dbus , and to set the time from RTC/GNSS if it loses sync.
Is that right?
You can check the time synchronisation status from an application container using d-bus as explained in the balenaOS masterclass (BalenaOS Masterclass - Balena Documentation).
I am not aware of any mechanism that will force chrony to step to a manually given time - usually timedatctl set-time or similar are used for this, specially as it takes time for the system time to divert from the moment it loses sync.
Yes, we have 1 processor running BalenaOS and 1 microcontroller. The micro has the GNSS and RTC connected to it and the micro is connected to the processor via a UART. The processor running BalenaOS gets sensor and GNSS data from the micro periodically.
I want to have our server container check if chrony isn’t not sync’d and then manually set the time using the GNSS clock as a reference. The server container is running in privileged mode. I see timedatctl command is in the HostOS but it’s not in the server container. What’s the best way to set the time from the server container?
The most used parttern to have timesync with chrony and a GPS is to use gpsd deamon.
You will need to feed gpsd with your GNSS NMEA data and it will be able to connect to chrony (they provide a configuration to do so).
But considering you wont connect directly to the GNSS, your timesync will be really weak as you will have numerous device/software playing with the GNSS time data, so don’t expect something more precise that a 1s for timesync.
Another solution is to write a simple script that check if /run/systemd/timesync/synchronized is settled. if not , get the time for the gps and date -s “29 Nov 2022 19:07:01Z” to set the date manually (there are some other syntax, check man date).
Hey Darren, it’s very likely that your container is not running systemd so timedatectl is not available. You can simply use the date command that will also set the system time in the same way as `timedatectl.
Using chrony and gpsd would be possible if the GPS would be accessible from the same processor that is running gpsd and chrony, which I don’t think is the case.
And /run/systemd/timesync/synchronized in the container root filesystem will not reflect the hostOS synchronization state. This has to be done via d-bus to the hostOS.