Chrony time synchronization on huge time diff

Question

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

Solution 1

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.

Solution 2

If your time is way off (days or even months), time synchronization will not work ("it will take a long time") because NTP clients like Chrony adjust the clock gradually by slowing it down or speeding it up.

Append this line to your Chrony config (for example, /etc/chrony.conf or /etc/chrony/chrony.conf):

makestep 1 -1

Then restart Chrony.

# systemctl restart chronyd
# or
# /etc/init.d/chrony restart

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_the_system_clock

Solution 3

If the time difference is huge chrony might not accept your source. My clock was a few years back and chronyc tracking was reporting:

> chronyc tracking
Ref time (UTC) : Thu Jan 01 00:00:00 1970

What worked for me was to add maxdistance 1000000000 in /etc/chrony.conf and then (after chronyd restart) do chrnoyc -a makestep 1000 -1.

Comments

[lemoncodes]

ohh i see spot on mate, maybe i went to the extreme in testing my setup. what is the usual skews and time diff between an NTP server and NTP client? so maybe im gonna revolve around that time when im testing my setup

[MadHatter]

@codehelix In my experience, under ten seconds. If you want any kind of significant time difference, client restart will be advisable. Better still is not to do this via NTP, but that's just a personal thing. By the way, feel free to accept my answer by clicking the tick outline if it's dealt with your question to your satisfaction; my apologies if you're already familiar with the local etiquette.

[MadHatter]

@codehelix As I said, I don't know chrony. From what you say, I'd guess that makestep is the chrony equivalent of using ntpdate, ie, it simply changes the clock, instead of slewing it. Changing it any amount you like is easy, though arguably best not done under a running OS (ie, best done at boot time).

[Bruce Becker]

can you point to where maxdifference is described in the manpage? chrony.tuxfamily.org/doc/4.2/chrony.conf.html makes no reference to it.

[rvernica]

@BruceBecker it was a typo, I meant maxdistance. I fixed the post now.