The chrony documentation warns
BE WARNED: Certain software will be seriously affected by such jumps in the system time. (That is the reason why chronyd uses slewing normally.) Documentation
But the documentation gives no examples. What are examples of software that will be seriously affected? Is the OS or any background processes at risk?
I have two networked voxls which I am trying to synchronize using chrony. The voxls boot up with vastly different system times, like years apart. I would expect chrony to synchronize the times when the service starts using makestep, but after starting chrony, I still observe a large difference in system time.
The configurations are as follows:
#server 10.0.0.102
makestep 1.0 3
driftfile /var/lib/chrony/drift
rtcsync
allow 10.0.0
local stratum 8
manual
logdir /var/log/chrony
#client 10.0.0.101
server 10.0.0.102 iburst maxpoll 5 prefer
makestep 1.0 3
driftfile /var/lib/chrony/drift
rtcsync
logdir /var/log/chrony
When chrony starts up, I would expect it to use makestep to synchronize the client in one fell swoop, and I see a time adjustment in the systemclt status
root@voxl1:~# systemctl status chronyd
● chronyd.service - NTP client/server
Loaded: loaded (/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2023-02-01 21:34:52 UTC; 83 years 0 months ago
Process: 3086 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 3088 (chronyd)
CGroup: /system.slice/chronyd.service
└─3088 /usr/sbin/chronyd
Feb 01 21:34:52 voxl1 systemd[1]: Starting NTP client/server...
Feb 01 21:34:52 voxl1 chronyd[3088]: chronyd version 2.4 starting (+CMDMON +NTP +REFCLOCK +RTC -PRIVDROP -...EBUG)
Feb 01 21:34:52 voxl1 chronyd[3088]: Frequency -0.681 +/- 0.232 ppm read from /var/lib/chrony/drift
Feb 01 21:34:52 voxl1 systemd[1]: Started NTP client/server.
Feb 01 21:34:56 voxl1 chronyd[3088]: Selected source 10.0.0.102
Feb 01 21:34:56 voxl1 chronyd[3088]: System clock wrong by 2619696428.415401 seconds, adjustment started
Feb 07 11:02:04 voxl1 chronyd[3088]: System clock was stepped by 2619696428.415401 seconds
If I use chronyc tracking or chronyc sources to observe the time offsets, the report indicates that the times are synchronized within 100 microseconds.
root@voxl1:~# chronyc tracking
Reference ID : 10.0.0.102 (10.0.0.102)
Stratum : 9
Ref time (UTC) : Sun Feb 07 11:08:34 2106
System time : 0.000066503 seconds slow of NTP time
Last offset : -0.000076736 seconds
RMS offset : 0.000044063 seconds
Frequency : 0.785 ppm slow
Residual freq : -0.216 ppm
Skew : 0.987 ppm
Root delay : 0.004293 seconds
Root dispersion : 0.000069 seconds
Update interval : 129.8 seconds
Leap status : Normal
root@voxl1:~# chronyc sources -v
210 Number of sources = 1
.-- Source mode '^' = server, '=' = peer, '#' = local clock.
/ .- Source state '*' = current synced, '+' = combined , '-' = not combined,
| / '?' = unreachable, 'x' = time may be in error, '~' = time too variable.
|| .- xxxx [ yyyy ] +/- zzzz
|| Reachability register (octal) -. | xxxx = adjusted offset,
|| Log2(Polling interval) --. | | yyyy = measured offset,
|| \ | | zzzz = estimated error.
|| | | \
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* 10.0.0.102 8 6 377 46 -77us[ -109us] +/- 1953us
However, if I then print the date, it doesn't match the time server at all.
client 10.0.0.101
root@voxl1:~# date
Sun Feb 7 11:12:00 UTC 2106
server 10.0.0.102
root@voxl2:~# date
Thu Jan 1 04:43:02 UTC 1970
I then tried to trigger a manual chronyc makestep, but that also didn't seem to have an effect.
Why is my date not the same? Did makestep work as intended? Is there a limit to how far chronyc makestep can step the clock?
Edit: I have a hypothesis, but I don't know how to test it. I think I might be seeing an underflow error. January 1, 1970 is the Unix Epoch. My hypothesis is that when chrony first tries to synchronize the client on startup, it makes an underflow error, and I see the systemctl message
Feb 01 21:34:56 voxl1 chronyd[3088]: System clock wrong by 2619696428.415401 seconds, adjustment started
Feb 07 11:02:04 voxl1 chronyd[3088]: System clock was stepped by 2619696428.415401 seconds
That incorrect step pushes the client to 2106, and chrony now thinks it's synchronized with the server which is why further makesteps have no effect and the offset appears small.
Any ideas how to test this hypothesis?
According to ntpdate and chronyd man pages
In ntpdate -q : Query only - don't set the clock.
chronyd -q : When run in this mode, chronyd will set the system clock once and exit. It will not detach from the terminal.
Is there any alternative command in chronyc to the following command, "query only without setting the clock"?
ntpdate -q pool.ntpserver.org
# timedatectl outputs
Local time: Tue 2020-10-06 13:35:31 PDT
Universal time: Tue 2020-10-06 20:35:31 UTC
RTC time: Tue 2020-10-06 20:35:30
Time zone: America/Los_Angeles (PDT, -0700)
System clock synchronized: no
NTP service: active
RTC in local TZ: no
/etc/chrony.conf is the default in RHEL 8 (with a preconfigured pool).
# chronyc sources outputs
210 Number of sources = 8
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^? excalibur.prolixium.com 0 9 0 - +0ns[ +0ns] +/- 0ns
^? paladin.latt.net 0 9 0 - +0ns[ +0ns] +/- 0ns
^? ronin.ruselabs.com 0 9 0 - +0ns[ +0ns] +/- 0ns
^? 2a00:7600::41 0 9 0 - +0ns[ +0ns] +/- 0ns
^? 50-205-244-112-static.hf> 0 9 0 - +0ns[ +0ns] +/- 0ns
^? time.cloudflare.com 0 9 0 - +0ns[ +0ns] +/- 0ns
^? 69.10.161.7 0 9 0 - +0ns[ +0ns] +/- 0ns
^? ntp3.your.org 0 9 0 - +0ns[ +0ns] +/- 0ns
# systemctl status chronyd shows active (running), and no errors in the logs.
The displayed system time is correct.
So, given all these facts, why is it that I see System clock synchronized: no? How do I turn it to yes?
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