Chrony is not sync with date command

Question

I paused the virtual machine on the VM and disconnected its internet connection without rebooting the system. When I started the system from sleep mode without rebooting, the system clock continued where it left off and could not show the correct time? What will I do in such a situation?

• my time data for the hour before I paused my virtual machine (it is also real time for my host)

 % chronyc sourcestats --------------------- Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev ============================================================================== 131.153.171.22 6 4 139 -46792.738 67288.219 -326ms 890ms 108.175.15.67 6 3 140 -44764.793 61909.766 -188ms 961ms gopher.fart.website 6 3 140 -49022.652 84747.266 -217ms 1224ms edge-iad.txryan.com 6 3 139 -45642.164 67798.562 -230ms 1032ms % chronyc tracking ------------------ Reference ID : 8399AB16 (131.153.171.22) Stratum : 3 Ref time (UTC) : Mon Dec 25 09:55:11 2023 System time : 0.000000000 seconds slow of NTP time Last offset : -5.681410313 seconds RMS offset : 1.796643019 seconds Frequency : 5.307 ppm fast Residual freq : -46792.738 ppm Skew : 8.997 ppm Root delay : 0.147369087 seconds Root dispersion : 0.769112766 seconds Update interval : 7.0 seconds Leap status : Normal % date ----------------- Mon Dec 25 12:55:18 PM +03 2023 % hwclock ----------------- 2023-12-25 12:55:13.078474+03:00 

• After disconnecting from the internet, I waited for a while and then when I opened the VM, the clock did not show the correct time. Also, when I get this output; my real host date (Monday, December 25, 2023 1:28:58 PM)

(in short, when I disconnected the internet connection and started the system again, it could not be started synchronously with the time of my main host.)

% chronyc sourcestats --------------------- Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev ============================================================================== 131.153.171.22 6 4 139 -46792.738 67288.219 -5592ms 890ms 108.175.15.67 6 3 140 -44764.793 61909.766 -5226ms 961ms gopher.fart.website 6 3 140 -49022.652 84747.266 -5734ms 1224ms edge-iad.txryan.com 6 3 139 -45642.164 67798.562 -5367ms 1032ms % chronyc tracking ------------------ Reference ID : 8399AB16 (131.153.171.22) Stratum : 3 Ref time (UTC) : Mon Dec 25 09:55:11 2023 System time : 0.000000000 seconds fast of NTP time Last offset : -5.681410313 seconds RMS offset : 1.796643019 seconds Frequency : 5.307 ppm fast Residual freq : -46792.738 ppm Skew : 8.997 ppm Root delay : 0.147369087 seconds Root dispersion : 6.036798477 seconds Update interval : 7.0 seconds Leap status : Normal % date ----------------- Mon Dec 25 12:57:11 PM +03 2023 % hwclock ----------------- 2023-12-25 12:57:05.629692+03:00 

• After Internet Connection

---

Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev ============================================================================== 131.153.171.22 6 4 343 -5616574 341926 -1958s 15.7s 108.175.15.67 6 4 343 -5631052 251508 -1960s 12.1s gopher.fart.website 6 4 343 -5618134 301975 -1963s 14.2s edge-iad.txryan.com 6 4 343 -5635317 275298 -1964s 13.2s Reference ID : 8399AB16 (131.153.171.22) Stratum : 3 Ref time (UTC) : Mon Dec 25 09:55:11 2023 System time : 0.000000001 seconds fast of NTP time Last offset : -5.681410313 seconds RMS offset : 1.796643019 seconds Frequency : 5.307 ppm fast Residual freq : -46792.738 ppm Skew : 8.997 ppm Root delay : 0.147369087 seconds Root dispersion : 16.738962173 seconds Update interval : 7.0 seconds Leap status : Normal Mon Dec 25 01:01:00 PM +03 2023 2023-12-25 13:01:00.293480+03:00 

---

Also, How often does my system time refresh via Chrony? When the system is turned on or as long as it is connected to the internet? How can I set this?

Answer 1

tl;dr: Your VM guest's clock is unsuitable for chrony, which caused you grief. Stop using it.

There are two approaches for guest OS to keep time:

• internet
• host OS

bad way: internet client

Your VM guest could be an NTP client of server1b.meinberg.de and other internet servers. Don't do this.

The VM suffers from long pauses which make external servers appear to rapidly timewarp into the future, every time the guest resumes. You have to do a "step" correction upon resumption, rather than a "run 10% fast" skew correction. Typically a startup script would accomplish this with a command like hwclock -s --utc, or perhaps by asking ntpdate to step the clock from some NTP server.

Chrony documentation section 3.4 points out that makestep 1 -1 is needed for a client in the unusual situation of being frequently suspended for minutes or hours at a time.

good way: host OS clock

When guest wants to know the time, it should ask that of the host it's running on.

Host OS presumably has a decent clock and can on occasion make {offset, frequency} estimates from internet NTP servers, when net is available.

VMware advises that it's

important to not use the local clock as a time source, often referred to as the Undisciplined Local Clock.

You didn't tell us about your hypervisor, so it's not clear what knobs we would have to frob. You may be able to benefit from Benjamin Bryan's experiences.

---

EDIT

Chrony (or other NTP daemon) is trying to measure {offset, frequency}. So for example, we might be four seconds slow and running 1% fast. Having made a few observations we can estimate both of those and correct for them.

Now suppose the guest suspends for half an hour. We might be able to report "we're 1804 seconds slow and still running 1% fast". But the gross offset is going to disturb any measurement of frequency error. What the daemon really needs to know is that from t_0 to t_1 we heard several NTP responses consistent with the "4 sec behind, 1% fast", then until t_2 we were dead to the world (suspended), and then observations after t_3 are consistent with "1804 sec behind, 1% fast". At which point we would certainly need to step by 1804 seconds.

OP made it pretty clear that chronyd is not syslogging that it knows about "suspend" and "resume" events. So the local undisciplined clock is unsuitable for use as a time base.

As a separate matter, if we listen to an hour's worth of internet NTP responses in order to sync up, then we suspend for half an hour, disconnect from internet, and expect a resumed guest to know what time it is, that information fundamentally has to come the host's clock. OP offers no evidence that the guest can distinguish between a 29-minute or 31-minute suspension interval, since the host's clock is not being accessed, not via hwclock and not via UDP port 123.

That's a config detail which the hypervisor + guest configs will need to fix, if we want to know the time after resuming.

ATM, it sounds like the only way for guest to reliably know the time upon resuming is to insist on being internet attached, and for a resume script to restart chronyd, encouraging a step update. (BTW, iburst initial burst in the config is a good match for that.)