As the application runs on the NTP server machine, time on the machine is
thinked accurate. I just can't figure out why synchonizing to itself will make
the NTP synchronization status becomes No after several hours.
timedatectl output:
from NTP synchronized: yes to NTP
On Thu, Jun 25, 2020 at 10:59:30PM +0800, xqmen...@hotmail.com wrote:
>Is there a way or some configuration to make chronyd client always
> successfully synchronize to itself.
No, that's an undesired configuration creating a positive feedback
loop. The clock would not be stable.
--
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.
Is there a way or some configuration to make chronyd client always
successfully synchronize to itself.
From: Miroslav Lichvar
Date: 2020-06-25 22:54
To: chrony-dev
Subject: Re: Re: [chrony-dev] Issue about chronyd synchronize to local clock
On Thu, Jun 25, 2020 at 10:44:29PM +0800,
So why chronyd can always sucessfully synchronize to other server but it
can't always synchronize to itself
From: xqmen...@hotmail.com
Date: 2020-06-25 23:19
To: chrony-dev
Subject: Re: Re: [chrony-dev] Issue about chronyd synchronize to local clock
I have a server cluster made of a
Hi folks,
I work on the AWS Time Sync
(https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html) service. We
create a link-local IPv4 address (169.254.169.123) that can be used as a source
server for NTP daemons on EC2 instances. The future is IPv6, so we’re
evaluating all of the
On Thu, Jun 25, 2020 at 10:44:29PM +0800, xqmen...@hotmail.com wrote:
>As the application runs on the NTP server machine, time on the machine is
> thinked accurate. I just can't figure out why synchonizing to itself will
> make
>the NTP synchronization status becomes No after several
I have a server cluster made of a number of machines, and I just choose one
from them to be the NTP server. then all other machines synchronize time to
the server. My application runs on every machine of the cluster, and the app
will not work if it detected 'NTP not synchronized status',
Miroslav explained. Because a client's stratum is one higher than the server
it gets time from. Since it is getting time from itself, each time it does so,
its stratum increases by 1. When it gets to 16 it stops using a server with
that high a stratum. Other servers do not keep increasing their
On Thu, Jun 25, 2020 at 10:22:00PM +0800, xqmen...@hotmail.com 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.
>
The machine I started chronyd is as a NTP server to other machine. If the
machine don't synchronize to itself, is there a way to make 'NTP synchronize
status' always true on the NTP server machine ?
From: xqmen...@hotmail.com
Date: 2020-06-25 22:22
To: chrony-dev
Subject: Re: Re:
'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
On Thu, 25 Jun 2020, xqmen...@hotmail.com wrote:
Is there a way or some configuration to make chronyd client always
successfully synchronize to itself.
Why? Your database program is designed to only work if the system clock is
synchronized to UTC. It seems that you want to break that,
As mentioned, do you have the option rtcsync in your chrony.conf file?
Synchronizing to itself as Miroslav mentioned is not a good idea, as it keeps
ratchting up its stratum.
Is your server linked to the internet? Ie, do you have outside sources for the
time? Of is yours a little isolated
On Mon, Jun 22, 2020 at 11:19 AM Miroslav Lichvar wrote:
>
> On Thu, Jun 18, 2020 at 11:21:29AM -0400, Robert Fairley wrote:
> > On Thu, Jun 18, 2020 at 6:31 AM Miroslav Lichvar
> > wrote:
> > >
> > > I think it could be a fragment now, and probably everything else
> > > except the default
The 'local' directive is a server feature, not client's, so that won't
work. If you have installed adjtimex, you could use it to clear the
unsynchronized status periodically with "adjtimex -S 0 -m 0". No need
to run an NTP server/client.
When will the kernel set the unsychronized status again,
This is an automated email from git. It was generated because a ref
change was pushed to the "chrony/chrony.git" repository.
The branch, master has been updated
via ad69f4f32bf668eb51b1b9c18b7f56125d8c5e3b (commit)
via 81c2b2e886345af6e5b01d008206c205e1641aa8 (commit)
via
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
allow
local stratum 10
driftfile /var/lib/chrony/drift
makestep 1.0 -1
rtcsync
On Thu, Jun 25, 2020 at 01:10:35PM +, Scott, Nathan wrote:
> Hi folks,
>
> I work on the AWS Time Sync
> (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html) service.
> We create a link-local IPv4 address (169.254.169.123) that can be used as a
> source server for NTP
On Thu, Jun 25, 2020 at 09:54:56PM +0800, xqmen...@hotmail.com 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
20 matches
Mail list logo