How is the RTC clock set? Is a Mender service actually setting the RTC clock with the right time?

Hello All,

I am trying to understand how my RTC clock is getting set. And I am unable to find a proper documentation on it.

After I switched to a read only RootFS. I noticed my systemclock was a getting set 1969 when the machine was not connected to a network. But as soon as I connect it to a network system clock would be set properly which was expected.

The issue came arrived when some of the network did not allow NTP communication which made my system stuck to 1969 which inturn made it fail TLS certification so bye bye https

The solution that I have come up with is to synchronize the hwclock with the system clock.

But how am I getting the right hwclock? Which service is setting it? If I know what service is setting it maybe I can know how it is being set and take care of some edge cases.

My initial hunch is that a mender service might be setting it. Since I have to register the device on the mender portal and it uses UTC time to sync the devices?

Am I right?

Most likely it is managed by systemd. See this link for more details.

Drew

1 Like

As @drewmoseley pointed out, systemd is most likely handling it, and when it syncs it usually stores the value on the file system for when you next reboot (assuming you don’t have a battery backed internal clock). You should be able to see this in the system journald boot logs as it usually logs that its restored current time from last stored sync time value.

`/var/lib/systemd/timesync/clock

if you on a read only file system then i guess that wont happen. Maybe you can symlink the file to your /data partition

@drewmoseley yes, you are right. On the very first fresh boot. The hwclock gets setup by the timesyncd.service.

@dellgreen the file /var/lib/systemd/timesync has a timestamp of 1969. Because my network rejects all outgoing and incoming UDP connections(to simulate the client network)

The issue that I am facing now is the edge case where the RTC stop working(The battery has run out). In those cases I need to set the date by using date command because timedatectl stop working if the RTC stops working and NTP stop working? Is that right?
Which makes sense since timedatectl is nothing but ntpclient.

In this scenario when the RTC has run out and there is no NTP. How do I put my system on a right time?

I am thinking of maintaining a localtime stamp once the system is online and then using that to reset my date and get the system working. Do you have any better suggestions?

In hindsight, I should have been more careful while transitioning.
I don’t think I have managed all the dependencies while moving time related services from rootFS to /data partition

I’m not sure NTP should stop working if your RTC battery runs out, as i dont have any batteries or real time clocks in my embedded projects, and they solely rely on SNTP at some point during boot to adjust the clock to the cached timestamp. if your are blocking all outgoing UDP packets then NTP will not work unless you provide an alternative network time server on your LAN.

You mention “once system is online” and keeping a localtime timestamp, but i believe that’s replicating what SNTP/NTP already does, if online it should update the local timestamp which gets used . Is UDP blocked but TCP is not?

If TCP is your only option, and accuracy is not of high importance (it doesn’t sound like it is), then you could write something that periodically pulls the “current” date and time from a free world clock rest api and use that to set the local time with timedatectl

Yeah, I think the RTC is only consulted on first boot. Once the system is up it restores the date from the RTC and then keeps it in sync with NTP. If you do not have an accurate time in the RTC then and no ability to use NTP then you will need another mechanism. I have used rdate in the past to do some setup but I don’t know if it requires UDP or not. Nor do I know if it integrates properly with systemd-timesyncd.

Drew

@dellgreen Sorry, I did not explain my situation better. So the client network don’t want NTP. So I have blocked all NTP request. And then I am removing the battery to sort of simulate a situation where battery runs out. If SNTP is actually doing this, Then I will read up about SNTP is there a documentation for it.
Can you please provide me a link.

@drewmoseley @dellgreen Thank you for your suggestions. I am looking into SNTP and rdate.

Where can I get list of hostnames that I can use for rdate?

I honestly don’t know. I’d start with just a google search.

1 Like

Forget SNTP, as it’s just a subset of NTP and uses the same UDP packets

1 Like

If you havent found them already

https://tf.nist.gov/tf-cgi/servers.cgi

and you can test rdate with the following to just print it to sdtout for testing

rdate -p time-a-g.nist.gov

1 Like

Thanks you so much. I will keep this ticket updated