Chrony Time Synchronization – Handling Huge Time Differences

centos7chronyntp

hello currently i have a localy ntp server (chrony) and a ntp client (chrony), all are working but when i try to change ntp server time to say minus 6 years from current time. ntp client cannot sync with it, it will just say on syslog:

Jan 9 17:29:11 localhost chronyd[9192]: System clock wrong by 6780812.328260 seconds, adjustment started

ntp client (chrony) /etc/chrony.conf is on default configuration except that server is pointed to my local NTP server (chrony). Here is my config

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
#server 0.centos.pool.ntp.org iburst
#server 1.centos.pool.ntp.org iburst
#server 2.centos.pool.ntp.org iburst
#server 3.centos.pool.ntp.org iburst
server local.ntp.server iburst

# Ignore stratum in source selection.
stratumweight 0

# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift

# Enable kernel RTC synchronization.
rtcsync

# In first three updates step the system clock instead of slew
# if the adjustment is larger than 10 seconds.
makestep 10 3

# Allow NTP client access from local network.
#allow 192.168/16

# Listen for commands only on localhost.
bindcmdaddress 127.0.0.1
bindcmdaddress ::1

# Serve time even if not synchronized to any NTP server.
#local stratum 10

keyfile /etc/chrony.keys

# Specify the key used as password for chronyc.
commandkey 1

# Generate command key if missing.
generatecommandkey

# Disable logging of client accesses.
noclientlog

# Send a message to syslog if a clock adjustment is larger than 0.5 seconds.
logchange 0.5

logdir /var/log/chrony
#log measurements statistics tracking

I do not know it wont sync, i've read that it will take longer time, but i've let my machine sit for 1 day and still ntp client didn't not have the same time as the ntp server (not synchronized). Any ideas? am tryin not to restart the chronyd service and just let it auto-sync the time

Note that "local.ntp.server" is define on my /etc/hosts. Also, NTP server and NTP client are not using ntpd service but it is using chronyd. And this kind of setup is an isolated one

Best Answer

Your problem seems to be that you're trying to accomplish a six year time change by skewing the clock, and giving up after one day.

If the skew algorithm drifts the clock by as much as one percent - which is quite a lot - it will take six hundred years to skew the clock that much. Even if the clock stands completely still, six years will need to elapse to step it back by six years. The only way to achieve a six-year backwards time drift in less than six years elapsed is to run the clock backwards, and I don't think anything will react well to that. To do it in one day would mean running the clock backwards at slightly more than two thousand times the real-time rate!

My feeling is that running NTP servers that lie is a very bad idea, but if you insist on doing this, and you suddenly skew the server by any significant amount, you will need to forcibly alter the client clocks before they have any chance of syncing. This is most easily done by ensuring that the clients forcibly reset their clocks from the server at boot time (with ntpd, this is done with ntpdate at boot time; I don't know about chrony) and rebooting the clients.

Related Topic