System date not updating on startup

I’m running into an issue where the timestamp is incorrect when the system starts up. I am running on a setup where the machine could be off for days at a time. Its internet connection is via a USB hotspot that is powered by the device. The hotspot therefore takes a few seconds to startup.

I’m able to see my device through the Balena dashboard but all my https calls are failing. They are failing because the system clock is incorrect. When I ssh to the device and run date the result is from many months ago.

I’m able to resolve this issue by restarting chronyd via
systemctl restart chronyd

My theory is that because the hotspot takes time to warmup that the system has already made all of it’s attempts to update its clock. As the docs say this happens in the first 8 seconds

For the device’s initial sync, the first four requests are sent at an interval of two seconds or less, before transitioning to the approximate four and half hour polling interval.

After that it won’t try again for 4.5 hours.

I tried to update /etc/chrony.conf to change the interval to be 2^8 seconds instead of 2^14 seconds. However, I get the following error when I try to save the changes.

‘/etc/chrony.conf’ Read-only file system

I don’t see any settings that I can change in config.json. It looks like you can only set the NTP servers but not the time.

Any ideas on how I can change this interval to be more frequent for to fire after an internet connection is detected?


Hi there, we had a discussion about this internally and I asked the team on what we concluded about handling cases like yours. Currently you cannot modify the config in a persistent manner. You could mount the FS to be read-write, change the value, and revert it, but that won’t be persisted across hostos updates. I will get back to you once the team responded on what is the best way to handle your situation for now.

Thanks for the very quick response. The application will be pretty static once it is stable so a solution that has to be redone after a hostOS update could work in the short term. Do you have any docs for how to mount the FS to be read-write?

You can read about it here: I would still advise caution, as the change can easily be forgotten and things can brake without realizing. I will get back to you about what is the proper way forward once my colleagues reply.

I just checked with my colleagues, we are working on making a more robust way to set the time that doesn’t require fiddling with poll intervals, but for now the best you can do is manually update the polling interval. Of course, if you can have an on-board RTC, then that’s even better.

Oh man, I hadn’t even thought about an RTC. That seems like the very easy solution. They are only $5 and I’ve spent hours upon hours trying to fix it. I can do that! Thanks again.