| Re: Re: [chrony-dev] Issue about chronyd synchronize to local clock |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
'NTP synchronization status yes'
tells the kernel to copy the system time to the RTC every 11 minutes. It does
not simply report that it thinks that the system time is synchronized to NTP.
Your author of the database software did not really know what he/she was
doing.
'server 127.0.0.1 iburst'
makes no sense since it tells system to synchronize to itself.
But you say that it does have the advantage for you of making the database
think that the system is synced to UTC, even though the system may be off by
17 years. Is that really what you want your database to do-- work even though
the system clock is completely haywire?
Chrony always worked to switch off the ntp sync status, because it made it
really hard for chrony to discipline the rtc clock, especially since it is
difficult to set the rtc clock with any accuracy, so every time you write to
it, you introduce random errors. chrony's philsophy was that it is better to
figure out how far off the rtc clock is and how far off its rate is, and use
tht to correct the rtc reading, than to not know and simply keep bashing the
rtc back to the right time. While chrony is running, it (or supposedly
anything else) never reads the RTC. When the rtc is needed ( after the machine
has been switched off or you have booted to another, non time-disciplined OS
and then back again), the rtc has not been corrected and you have no idea how
far off it is (imagine switching the machine off for a week while the rtc
clock freewheels). Miroslav introduced the rtcsync flag to allow the rtc to be
bashed back every 11 min. (ie allows the ntp sync flag to be set by the
kernel), with the advantages and disadvantages that that has (for short
off-times or booting into other OSs, the rtc should be reasonably close to the correct time
and the system time should be reasonably close to the correct time on reboots)
So, running with the rtcsync directive, you should get the 11 min behaviour of
the kernel and the switch on the sync flag by the kernel.
Read
5.2. I want to use chronyd's RTC support. Must I disable hwclock?
in the FAQ to read about this.
o, for your situation, it would seem that you should use the rtcsync directive
and wait until chrony HAS synchronized the system clock to UTC. It will not do
so immediately. It has to wait until it has drifted the system clock to the
right time.
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 ______|_ www.theory.physics.ubc.ca/
On Thu, 25 Jun 2020, xqmeng80@xxxxxxxxxxx wrote:
My database application runs on this machine and the application can't work with 'NTP synchronization status no'。
If I remove the line 'server 127.0.0.1 iburst', the NTP synchronization status is always no.
By the way I check the ntp synchronization status with adjtimex mode 0.
_____________________________________________________________________________________________________________________
From: Miroslav Lichvar
Date: 2020-06-25 22:04
To: chrony-dev
Subject: Re: [chrony-dev] Issue about chronyd synchronize to local clock
On Thu, Jun 25, 2020 at 09:54:56PM +0800, xqmeng80@xxxxxxxxxxx wrote:
> Hi All,
>
> I started chronyd as a client and server, then I try to synchronize to local clock with the following
configuration:
>
> server 127.0.0.1 iburst
Try removing the line above. You don't want the server to be
synchronizing to itself.
--
Miroslav Lichvar
--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.