|
I want to read the RTC to compare it to the system clock as with
timedatectl. Use cases for this are checking if syncing to the RTC
actually worked or identifying a bug in case the RTC malfunctions.
I don't see how this is so hard to understand. It is just one
string to print. The first thing I would implement when creating
the RTC sections reading and printing the current RTC value.
Am 09.08.24 um 20:25 schrieb Bill
Unruh:
William G. Unruh __| Canadian Institute for|____ Tel:
+1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax:
+1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____
unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 ____|____ and Gravity ______|_
theory.physics.ubc.ca/
On Fri, 9 Aug 2024, Jan Claußen wrote:
[CAUTION: Non-UBC Email]While chronyd is
running with the rtcfile directive, timedatectl shows
$ timedatectl
Local time: Fri 2024-08-09 14:12:01 UTC
Universal time: Fri 2024-08-09 14:12:01 UTC
RTC time: n/a
Time zone: Universal (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
When using chronyc's rtcdata command, you get
RTC ref time (GMT) : Sat May 30 07:25:56 2015
Number of samples : 10
Number of runs : 5
Sample span period : 549
RTC is fast by : -1.632736 seconds
RTC gains time at : -107.623 ppm
where
RTC ref time (GMT)
This is the RTC reading the last time its error was measured.
so this is not the current RTC value either. How to read it out
then without having to stop chronyd?
I am not sure what you mean. You have all the data you need to
figure out what
the time is. You know what its time read, you know how slow/fast
it is, You
even know how fast it gains or loses time
Why are you reading the rtc anyway. It is not terribly accurate.
And when
chrony is running, it keeps the time of rtc open not allowing
anything else to
read it. You run the system clock to get accurate time. rtc is
ONLY useful for
giving the clock a starting time when chrony is started. It is not
useful as a
clock unless you are happy with times to nearest second.
|