Thanks Miroslav.
Comments below.
Il 08/08/2016 10:34, Miroslav Lichvar ha scritto:
On Sun, Aug 07, 2016 at 05:06:46AM +0200, Mauro Condarelli wrote:
Thanks Steve.
I know about "chronyc tracking", but that is human-readable info.
I need to parse it (in a shell script) to delay starting of my app until time
has settled down.
Is it enough to wait for "Leap status" to go to "Normal"?
... or should I take into consideration other values?.
Depending on how chronyd is configured and what exactly you mean by
My current /etc/chrony .conf is:
-----------------
server 0.it.pool.ntp.org
server 1.it.pool.ntp.org
server 2.pool.ntp.org
server 3.pool.ntp.org
logdir /var/log/chrony
log rtc statistics measurements tracking
logchange 1
driftfile /var/lib/chrony/drift
keyfile /etc/chrony.keys
generatecommandkey
makestep 1.0 3
maxupdateskew 100.0
dumponexit
dumpdir /var/lib/chrony
rtconutc
rtcfile /var/lib/chrony/rtc
bindcmdaddress /var/run/chrony/chronyd.sock
rtcdevice /dev/rtc0
-----------------
"time has settled down", you might need to check also the "System
Problem is on target I have unreliable Internet connection.
This means i might not have connection at all at boot-time.
In this condition it's ok to rely on RTC alone.
What I need is to be sure chronyc did require initializations (e.g.: it did set
system clock from RTC) even if not fully synchronized.
time" and "Skew" values.
The chronyc waitsync command can do all this for you.
http://chrony.tuxfamily.org/doc/2.4/chronyc.html#waitsync
How does that behave in case of disconnected target?
I also have a very strange and annoying behavior I need to debug, somehow:
It happens (rarely, about once in a few days) system time, as seen using either "date" or
"time(null)", "jumps around" for a short while and then resets to normal.
I mean I have record of time going in the past (two days), then in the future (> one month)
then in the past again (>one week) and finally going back to "right" time.
I spotted this because my target (embedded ARM) has a display that, when idle, just displays system
time&date (fetched using "time(null)"), I casually spotted the bogus time and confirmed
this was not a problem with my application by connecting to console and issuing several
"date" commands.
Real question is:
How do I debug such situation?
Should I see something on log? (I didn't spot anything suspicious)
How can I tell chrony to log any correction done to sysclock?
TiA
--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email listmas...@chrony.tuxfamily.org.