Ryfujk

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

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.

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

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 maxdiference 1000000000 in /etc/chrony.conf and then (after chronyd restart) do chrnoyc -a makestep 1000 -1.