I already asked but didn't get feedback so far. Why chronyc looses the syncing with external NTP during system st/by and it is necessary to manually re-sync? ^? time.cloudflare.com 0 6 0 - +0ns[ +0ns] +/- 0ns ^? par.cyberbits.eu 0 6 0 - +0ns[ +0ns] +/- 0ns ^? static.102.162.46.78.cli> 0 6 0 - +0ns[ +0ns] +/- 0ns ^? pob01.mulx.net 0 6 0 - +0ns[ +0ns] +/- 0ns ^? ntp.rol.net.mv 0 6 0 - +0ns[ +0ns] +/- 0ns ^? mail.masters-of-cloud.de 0 6 0 - +0ns[ +0ns] +/- 0ns sudo chronyc burst 4/4; sudo chronyc makestep [sudo] password di root: 200 OK 200 OK *^* time.cloudflare.com* 3 6 0 20m -85us[+1906us] +/- 71ms ^- par.cyberbits.eu 2 6 0 20m -4421us[-2430us] +/- 150ms ^- static.102.162.46.78.cli> 2 6 0 20m -15ms[ -15ms] +/- 162ms ^- pob01.mulx.net 2 6 0 20m +261us[ +261us] +/- 130ms ^- ntp.rol.net.mv 3 6 0 20m +1112ns[+1992us] +/- 426ms ^- mail.masters-of-cloud.de 2 6 0 20m +2603us[+2603us] +/- 108ms Thanks. Regards, -- Marco Calistri Build: openSUSE Tumbleweed 20210730 Kernel:5.13.4-1-default Desktop: XFCE (4.16.0)
On 01/08/2021 15.40, Marco Calistri wrote:
I already asked but didn't get feedback so far.
Why chronyc looses the syncing with external NTP during system st/by and it is necessary to manually re-sync?
On your previous post you said it happened after suspend/hibernate. Long ago, I had a script to restart ntpd on resume precisely for that reason. I don't remember how I have it setup currently, but on this laptop I see a script (of mine) firing up periodically to force sync. I can investigate later. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))
Il 01/08/21 11:21, Carlos E. R. ha scritto:
On 01/08/2021 15.40, Marco Calistri wrote:
I already asked but didn't get feedback so far.
Why chronyc looses the syncing with external NTP during system st/by and it is necessary to manually re-sync? On your previous post you said it happened after suspend/hibernate. Long ago, I had a script to restart ntpd on resume precisely for that reason.
I don't remember how I have it setup currently, but on this laptop I see a script (of mine) firing up periodically to force sync. I can investigate later.
Thanks Carlos, In reality I would like to avoid using scripts I wonder why the process is not syncing automatically after some time. Regards, Marco -- Marco Calistri Build: openSUSE Tumbleweed 20210730 Kernel:5.13.4-1-default Desktop: XFCE (4.16.0)
On 01/08/2021 16.29, Marco Calistri wrote:
Il 01/08/21 11:21, Carlos E. R. ha scritto:
On 01/08/2021 15.40, Marco Calistri wrote:
I already asked but didn't get feedback so far.
Why chronyc looses the syncing with external NTP during system st/by and it is necessary to manually re-sync? On your previous post you said it happened after suspend/hibernate. Long ago, I had a script to restart ntpd on resume precisely for that reason.
I don't remember how I have it setup currently, but on this laptop I see a script (of mine) firing up periodically to force sync. I can investigate later.
Thanks Carlos,
In reality I would like to avoid using scripts I wonder why the process is not syncing automatically after some time.
I gave up on that. Simply put, not all programmers contemplate that the computer can be suspended and code some reaction to the event. Mind, I don't know if this is the case currently with ntpd or chronyc, only at the time I evaluated this, ntpd was at least not reacting correctly or not at all, so it was up to me to do something. I am interested in learning the current status of things, thus I marked your previous message in red to watch it, then forgot. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2021-08-01 a las 16:35 +0200, Carlos E. R. escribió:
On 01/08/2021 16.29, Marco Calistri wrote:
Il 01/08/21 11:21, Carlos E. R. ha scritto:
On 01/08/2021 15.40, Marco Calistri wrote:
In reality I would like to avoid using scripts I wonder why the process is not syncing automatically after some time.
I gave up on that.
It could be as simple, using systemd, adding on the service file something like "restartonresume=true" or "onresumerun=..."- but mind, I don't know if such an option exists on systemd, I made up the setting name. - -- Cheers Carlos E. R. (from openSUSE Leap 15.2 x86_64 (Minas Tirith)) -----BEGIN PGP SIGNATURE----- iJIEAREIADoWIQQt/vKEw5659AgM/X2NrxRtxRYzXAUCYQazgBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJEI2vFG3FFjNcjRAA/2dUVpUoDpsqG+FbWh4b SynxcLTL42gbHN2YBt+YuRJcAP4w7W2i001mIdMtXT3TjAackoG1RPJdpZ0aA1eJ VjnfHg== =KqVy -----END PGP SIGNATURE-----
On 01.08.2021 16:40, Marco Calistri wrote:
I already asked but didn't get feedback so far.
Why chronyc looses the syncing with external NTP during system st/by and it is necessary to manually re-sync?
^? time.cloudflare.com 0 6 0 - +0ns[ +0ns] +/- 0ns
^? par.cyberbits.eu 0 6 0 - +0ns[ +0ns] +/- 0ns
^? static.102.162.46.78.cli> 0 6 0 - +0ns[ +0ns] +/- 0ns
^? pob01.mulx.net 0 6 0 - +0ns[ +0ns] +/- 0ns
^? ntp.rol.net.mv 0 6 0 - +0ns[ +0ns] +/- 0ns
^? mail.masters-of-cloud.de 0 6 0 - +0ns[ +0ns] +/- 0ns
How long did you wait after resume before getting this output? Otherwise logs may give some more hints.
sudo chronyc burst 4/4; sudo chronyc makestep
[sudo] password di root:
200 OK
200 OK
*^* time.cloudflare.com* 3 6 0 20m -85us[+1906us] +/- 71ms
^- par.cyberbits.eu 2 6 0 20m -4421us[-2430us] +/- 150ms
^- static.102.162.46.78.cli> 2 6 0 20m -15ms[ -15ms] +/- 162ms
^- pob01.mulx.net 2 6 0 20m +261us[ +261us] +/- 130ms
^- ntp.rol.net.mv 3 6 0 20m +1112ns[+1992us] +/- 426ms
^- mail.masters-of-cloud.de 2 6 0 20m +2603us[+2603us] +/- 108ms
Thanks.
Regards,
On 01.08.2021 17:47, Andrei Borzenkov wrote:
On 01.08.2021 16:40, Marco Calistri wrote:
I already asked but didn't get feedback so far.
Why chronyc looses the syncing with external NTP during system st/by and it is necessary to manually re-sync?
^? time.cloudflare.com 0 6 0 - +0ns[ +0ns] +/- 0ns
^? par.cyberbits.eu 0 6 0 - +0ns[ +0ns] +/- 0ns
^? static.102.162.46.78.cli> 0 6 0 - +0ns[ +0ns] +/- 0ns
^? pob01.mulx.net 0 6 0 - +0ns[ +0ns] +/- 0ns
^? ntp.rol.net.mv 0 6 0 - +0ns[ +0ns] +/- 0ns
^? mail.masters-of-cloud.de 0 6 0 - +0ns[ +0ns] +/- 0ns
How long did you wait after resume before getting this output?
After suspend/resume chronyd most likely sees time jump and resets all sources state. Which is why
Otherwise logs may give some more hints.
You should have checked and provided chronyd logs. Most likely you see something like "Forward time jump detected!". That would explain output you get. The chronyc activity would show overview of current sources status (online/offline). Further steps depend on whether sources are online or offline from chronyd point of view.
sudo chronyc burst 4/4; sudo chronyc makestep
[sudo] password di root:
200 OK
200 OK
*^* time.cloudflare.com* 3 6 0 20m -85us[+1906us] +/- 71ms
^- par.cyberbits.eu 2 6 0 20m -4421us[-2430us] +/- 150ms
^- static.102.162.46.78.cli> 2 6 0 20m -15ms[ -15ms] +/- 162ms
^- pob01.mulx.net 2 6 0 20m +261us[ +261us] +/- 130ms
^- ntp.rol.net.mv 3 6 0 20m +1112ns[+1992us] +/- 426ms
^- mail.masters-of-cloud.de 2 6 0 20m +2603us[+2603us] +/- 108ms
Well, it looks like sources remained offline actually. burst tells chronyd to (try to) contact sources but does not change their status (so if sources are offline no periodic polling starts). And BTW what "chronyc sources" says *before* suspend?
Il 01/08/21 13:30, Andrei Borzenkov ha scritto:
On 01.08.2021 17:47, Andrei Borzenkov wrote:
On 01.08.2021 16:40, Marco Calistri wrote:
I already asked but didn't get feedback so far.
Why chronyc looses the syncing with external NTP during system st/by and it is necessary to manually re-sync?
^? time.cloudflare.com 0 6 0 - +0ns[ +0ns] +/- 0ns
^? par.cyberbits.eu 0 6 0 - +0ns[ +0ns] +/- 0ns
^? static.102.162.46.78.cli> 0 6 0 - +0ns[ +0ns] +/- 0ns
^? pob01.mulx.net 0 6 0 - +0ns[ +0ns] +/- 0ns
^? ntp.rol.net.mv 0 6 0 - +0ns[ +0ns] +/- 0ns
^? mail.masters-of-cloud.de 0 6 0 - +0ns[ +0ns] +/- 0ns
How long did you wait after resume before getting this output?
Let's say 12 or 24 hours, cannot be totally sure. BTW IMHO the daemon chronyd must do a sort of autosync to external sources. After suspend/resume chronyd most likely sees time jump and resets all sources state. Which is why
Otherwise logs may give some more hints.
You should have checked and provided chronyd logs. Most likely you see something like "Forward time jump detected!".
That would explain output you get. The
chronyc activity marco@localhost:~> chronyc activity 200 OK 0 sources online 6 sources offline 0 sources doing burst (return to online) 0 sources doing burst (return to offline) 0 sources with unknown address
would show overview of current sources status (online/offline). Further steps depend on whether sources are online or offline from chronyd point of view.
sudo chronyc burst 4/4; sudo chronyc makestep
[sudo] password di root:
200 OK
200 OK
*^* time.cloudflare.com* 3 6 0 20m -85us[+1906us] +/- 71ms
^- par.cyberbits.eu 2 6 0 20m -4421us[-2430us] +/- 150ms
^- static.102.162.46.78.cli> 2 6 0 20m -15ms[ -15ms] +/- 162ms
^- pob01.mulx.net 2 6 0 20m +261us[ +261us] +/- 130ms
^- ntp.rol.net.mv 3 6 0 20m +1112ns[+1992us] +/- 426ms
^- mail.masters-of-cloud.de 2 6 0 20m +2603us[+2603us] +/- 108ms
Well, it looks like sources remained offline actually. burst tells chronyd to (try to) contact sources but does not change their status (so if sources are offline no periodic polling starts).
And BTW what "chronyc sources" says *before* suspend? Before suspend the client is synced (see the asterisk on the NTP source).
marco@localhost:~> chronyc sources MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^* time.cloudflare.com 3 6 0 302m -85us[+1906us] +/- 71ms ^- par.cyberbits.eu 2 6 0 302m -4421us[-2430us] +/- 150ms ^- static.102.162.46.78.cli> 2 6 0 302m -15ms[ -15ms] +/- 162ms ^- pob01.mulx.net 2 6 0 302m +261us[ +261us] +/- 130ms ^- ntp.rol.net.mv 3 6 0 302m +1112ns[+1992us] +/- 426ms ^- mail.masters-of-cloud.de 2 6 0 302m +2603us[+2603us] +/- 108ms -- Marco Calistri Build: openSUSE Tumbleweed 20210730 Kernel:5.13.4-1-default Desktop: XFCE (4.16.0)
On 01.08.2021 21:22, Marco Calistri wrote: ...
chronyc activity
marco@localhost:~> chronyc activity 200 OK 0 sources online 6 sources offline 0 sources doing burst (return to online) 0 sources doing burst (return to offline) 0 sources with unknown address
... Before suspend the client is synced (see the asterisk on the NTP source).
Last time your time servers have been contacted 5 hours ago. It helps to look beyond the first column. Before suspend all of your servers were just as well offline. This was one time sync, likely during chronyd service startup. So you do not really lose any functionality after resume, just cosmetic display change.
marco@localhost:~> chronyc sources MS Name/IP address Stratum Poll Reach LastRx Last sample ===============================================================================
^* time.cloudflare.com 3 6 0 302m -85us[+1906us] +/- 71ms ^- par.cyberbits.eu 2 6 0 302m -4421us[-2430us] +/- 150ms ^- static.102.162.46.78.cli> 2 6 0 302m -15ms[ -15ms] +/- 162ms ^- pob01.mulx.net 2 6 0 302m +261us[ +261us] +/- 130ms ^- ntp.rol.net.mv 3 6 0 302m +1112ns[+1992us] +/- 426ms ^- mail.masters-of-cloud.de 2 6 0 302m +2603us[+2603us] +/- 108ms
Il 01/08/21 15:30, Andrei Borzenkov ha scritto:
On 01.08.2021 21:22, Marco Calistri wrote: ...
chronyc activity marco@localhost:~> chronyc activity 200 OK 0 sources online 6 sources offline 0 sources doing burst (return to online) 0 sources doing burst (return to offline) 0 sources with unknown address ... Before suspend the client is synced (see the asterisk on the NTP source).
Last time your time servers have been contacted 5 hours ago. It helps to look beyond the first column.
Before suspend all of your servers were just as well offline. This was one time sync, likely during chronyd service startup. So you do not really lose any functionality after resume, just cosmetic display change.
Not really cosmetic because if I verify my clock on https://time.is/it/ it results inaccurate and I need to manually sync chronyc. I don't need any particular feature at the end, just would like to keep chronyc synced as it was doing ntp client that I used in the past. Regards, -- Marco Calistri Build: openSUSE Tumbleweed 20210730 Kernel:5.13.4-1-default Desktop: XFCE (4.16.0)
On 01.08.2021 21:46, Marco Calistri wrote:
Il 01/08/21 15:30, Andrei Borzenkov ha scritto:
On 01.08.2021 21:22, Marco Calistri wrote: ...
chronyc activity marco@localhost:~> chronyc activity 200 OK 0 sources online 6 sources offline 0 sources doing burst (return to online) 0 sources doing burst (return to offline) 0 sources with unknown address ... Before suspend the client is synced (see the asterisk on the NTP source).
Last time your time servers have been contacted 5 hours ago. It helps to look beyond the first column.
Before suspend all of your servers were just as well offline. This was one time sync, likely during chronyd service startup. So you do not really lose any functionality after resume, just cosmetic display change.
Not really cosmetic because if I verify my clock on https://time.is/it/ it results inaccurate and I need to manually sync chronyc.
It is cosmetic because situation after resume does not differ from situation before resume. Have you checked your clock *before* suspend? Was it synchronized? Show output of chronyc sources chronyc activity immediately after boot.
I don't need any particular feature at the end, just would like to keep chronyc synced as it was doing ntp client that I used in the past.
chronyc does not sync anything.
On 01/08/2021 20.52, Andrei Borzenkov wrote:
On 01.08.2021 21:46, Marco Calistri wrote:
Il 01/08/21 15:30, Andrei Borzenkov ha scritto:
On 01.08.2021 21:22, Marco Calistri wrote: ...
chronyc activity marco@localhost:~> chronyc activity 200 OK 0 sources online 6 sources offline 0 sources doing burst (return to online) 0 sources doing burst (return to offline) 0 sources with unknown address ... Before suspend the client is synced (see the asterisk on the NTP source).
Last time your time servers have been contacted 5 hours ago. It helps to look beyond the first column.
Before suspend all of your servers were just as well offline. This was one time sync, likely during chronyd service startup. So you do not really lose any functionality after resume, just cosmetic display change.
Not really cosmetic because if I verify my clock on https://time.is/it/ it results inaccurate and I need to manually sync chronyc.
It is cosmetic because situation after resume does not differ from situation before resume. Have you checked your clock *before* suspend? Was it synchronized?
It is possible that clock is "visibly off" after resume, as the time was set from the battery powered CMOS clock in the motherboard. The situation is the same, but before the resume the time was set from internet at least once, hours before.
Show output of
chronyc sources chronyc activity
immediately after boot.
I don't need any particular feature at the end, just would like to keep chronyc synced as it was doing ntp client that I used in the past.
chronyc does not sync anything.
chronyc does not keep time in sync as ntpd does? It is only one shot? -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))
Il 01/08/21 15:57, Carlos E. R. ha scritto:
On 01/08/2021 20.52, Andrei Borzenkov wrote:
On 01.08.2021 21:46, Marco Calistri wrote:
Il 01/08/21 15:30, Andrei Borzenkov ha scritto:
On 01.08.2021 21:22, Marco Calistri wrote: ...
chronyc activity marco@localhost:~> chronyc activity 200 OK 0 sources online 6 sources offline 0 sources doing burst (return to online) 0 sources doing burst (return to offline) 0 sources with unknown address ... Before suspend the client is synced (see the asterisk on the NTP source).
Last time your time servers have been contacted 5 hours ago. It helps to look beyond the first column.
Before suspend all of your servers were just as well offline. This was one time sync, likely during chronyd service startup. So you do not really lose any functionality after resume, just cosmetic display change.
Not really cosmetic because if I verify my clock on https://time.is/it/ it results inaccurate and I need to manually sync chronyc.
It is cosmetic because situation after resume does not differ from situation before resume. Have you checked your clock *before* suspend? Was it synchronized? Yes it is sinced and the system clock is almost accurate on time.is It is possible that clock is "visibly off" after resume, as the time was set from the battery powered CMOS clock in the motherboard. The situation is the same, but before the resume the time was set from internet at least once, hours before.
Show output of
chronyc sources chronyc activity
immediately after boot.
I don't need any particular feature at the end, just would like to keep chronyc synced as it was doing ntp client that I used in the past.
chronyc does not sync anything. But I startt chronyd as well:
marco@localhost:~> ps -ef|grep chrony chrony 1397 1 0 lug31 ? 00:00:00 /usr/sbin/chronyd
chronyc does not keep time in sync as ntpd does? It is only one shot?
In my understanding chronyd is a replacement of NTPD but so far is not as good as the latter because I need to re-sync manually after some time. Regards, -- Marco Calistri Build: openSUSE Tumbleweed 20210730 Kernel:5.13.4-1-default Desktop: XFCE (4.16.0)
On 01.08.2021 21:57, Carlos E. R. wrote:
On 01/08/2021 20.52, Andrei Borzenkov wrote:
On 01.08.2021 21:46, Marco Calistri wrote:
Il 01/08/21 15:30, Andrei Borzenkov ha scritto:
On 01.08.2021 21:22, Marco Calistri wrote: ...
chronyc activity marco@localhost:~> chronyc activity 200 OK 0 sources online 6 sources offline 0 sources doing burst (return to online) 0 sources doing burst (return to offline) 0 sources with unknown address ... Before suspend the client is synced (see the asterisk on the NTP source).
Last time your time servers have been contacted 5 hours ago. It helps to look beyond the first column.
Before suspend all of your servers were just as well offline. This was one time sync, likely during chronyd service startup. So you do not really lose any functionality after resume, just cosmetic display change.
Not really cosmetic because if I verify my clock on https://time.is/it/ it results inaccurate and I need to manually sync chronyc.
It is cosmetic because situation after resume does not differ from situation before resume. Have you checked your clock *before* suspend? Was it synchronized?
It is possible that clock is "visibly off" after resume, as the time was set from the battery powered CMOS clock in the motherboard. The situation is the same, but before the resume the time was set from internet at least once, hours before.
Yes, of course, but that is different from "crony loses sync after suspend/resume". From the evidences provided so far crony lost sync hours before suspend/resume. If you want to fix *this* issue you need to investigate why and when it happened. Pointing finger at some random suspect spot not related to root cause is not going to help. It is still possible that something went wrong during one of previous suspend/resume cycles but there is no evidence so no way to investigate. One needs to collect chrony state immediately after boot, immediately before suspend, some time after resume. That will give starting point.
Show output of
chronyc sources chronyc activity
immediately after boot.
I don't need any particular feature at the end, just would like to keep chronyc synced as it was doing ntp client that I used in the past.
chronyc does not sync anything.
chronyc does not keep time in sync as ntpd does? It is only one shot?
Chronyc is tool to control chronyd just like ntpdc is tool to control ntpd. Looking here after resume, interesting is that chronyd onlined some - but not all - servers. Two of them are IPv6 so it is possibly related to delay in IPv6 address configuration. Two of them are IPv4 so I do not really have explanation so far. P.S. and yes, I of course have chronyd[12089]: Forward time jump detected! in logs after resume. Which explains zeroes in output shown originally.
Il 02/08/21 02:08, Andrei Borzenkov ha scritto:
On 01.08.2021 21:57, Carlos E. R. wrote:
On 01/08/2021 20.52, Andrei Borzenkov wrote:
On 01.08.2021 21:46, Marco Calistri wrote:
Il 01/08/21 15:30, Andrei Borzenkov ha scritto:
On 01.08.2021 21:22, Marco Calistri wrote: ...
> chronyc activity marco@localhost:~> chronyc activity 200 OK 0 sources online 6 sources offline 0 sources doing burst (return to online) 0 sources doing burst (return to offline) 0 sources with unknown address ...
Chronyc is tool to control chronyd just like ntpdc is tool to control ntpd.
Looking here after resume, interesting is that chronyd onlined some - but not all - servers. Two of them are IPv6 so it is possibly related to delay in IPv6 address configuration. Two of them are IPv4 so I do not really have explanation so far.
P.S. and yes, I of course have
chronyd[12089]: Forward time jump detected!
in logs after resume. Which explains zeroes in output shown originally. ---<SNIP>---
This below is the solution to avoid loosing the sync of chrony during st/by and resumes: Explanation: The makestep directive can be used to allow chronyd to step the clock. For example, if chrony.conf had makestep 1 3 the clock would be stepped in the first three updates if its offset was larger than one second. Normally, it’s recommended to allow the step only in the first few updates, but in some cases (e.g. a computer without an RTC or virtual machine which can be suspended and resumed with an incorrect time) it may be necessary to allow the step on any clock update. The example above would change to makestep 1 -1 https://chrony.tuxfamily.org/faq.html#_is_code_chronyd_code_allowed_to_step_... Best regards! -- Marco Calistri Build: openSUSE Tumbleweed 20210730 Kernel:5.13.4-1-default Desktop: XFCE (4.16.0)
On 03/08/2021 17.04, Marco Calistri wrote:
Il 02/08/21 02:08, Andrei Borzenkov ha scritto:
...
This below is the solution to avoid loosing the sync of chrony during st/by and resumes:
Explanation:
The makestep directive can be used to allow chronyd to step the clock. For example, if chrony.conf had
makestep 1 3
the clock would be stepped in the first three updates if its offset was larger than one second. Normally, it’s recommended to allow the step only in the first few updates, but in some cases (e.g. a computer without an RTC or virtual machine which can be suspended and resumed with an incorrect time) it may be necessary to allow the step on any clock update. The example above would change to
makestep 1 -1
https://chrony.tuxfamily.org/faq.html#_is_code_chronyd_code_allowed_to_step_...
Notice that some sources (ex. vmware) say that it is not correct to use an ntp daemon inside a virtual machine. Instead, a single daemon should run on the host, and the time be synced from the host to all guests. This should be done by virtual machine deamon that connects the guest to the host, name varies depending on the virtualization method. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))
Il 03/08/21 12:20, Carlos E. R. ha scritto:
On 03/08/2021 17.04, Marco Calistri wrote:
Il 02/08/21 02:08, Andrei Borzenkov ha scritto: ...
This below is the solution to avoid loosing the sync of chrony during st/by and resumes:
Explanation:
The makestep directive can be used to allow chronyd to step the clock. For example, if chrony.conf had
makestep 1 3
the clock would be stepped in the first three updates if its offset was larger than one second. Normally, it’s recommended to allow the step only in the first few updates, but in some cases (e.g. a computer without an RTC or virtual machine which can be suspended and resumed with an incorrect time) it may be necessary to allow the step on any clock update. The example above would change to
makestep 1 -1
https://chrony.tuxfamily.org/faq.html#_is_code_chronyd_code_allowed_to_step_... Notice that some sources (ex. vmware) say that it is not correct to use an ntp daemon inside a virtual machine. Instead, a single daemon should run on the host, and the time be synced from the host to all guests. This should be done by virtual machine deamon that connects the guest to the host, name varies depending on the virtualization method.
In my case I'm using chrony on the host machine not virtual. As I told at the beginning, my system was loosing the ntp sync with external sources during the st/by periods. So far, after I changed the configuration file as inicated before, my host keeps clock synced. Regards, -- Marco Calistri Build: openSUSE Tumbleweed 20210801 Kernel:5.13.4-1-default Desktop: XFCE (4.16.0)
participants (3)
-
Andrei Borzenkov -
Carlos E. R. -
Marco Calistri