Does date -s command ignore NTP service?

Question

I am synchronizing time using GPSD and Chrony. However, if the time is manually changed with date -s while the NTP service is active, synchronization is not possible again.

If time is changed with date -s, is time synchronization using ntp service ignored? Below is my chrony.conf / timedatectl / chronyc tracking screen.

chrony.conf

# information about usuable directives.

# This will use (up to):
# - 4 sources from ntp.ubuntu.com which some are ipv6 enabled
# - 2 sources from 2.ubuntu.pool.ntp.org which is ipv6 enabled as well
# - 1 source from [01].ubuntu.pool.ntp.org each (ipv4 only atm)
# This means by default, up to 6 dual-stack and up to 2 additional IPv4-only
# sources will be used.
# At the same time it retains some protection against one of the entries being
# down (compare to just using one of the lines). See (LP: #1754358) for the
# discussion.
#
# About using servers from the NTP Pool Project in general see (LP: #104525).
# Approved by Ubuntu Technical Board on 2011-02-08.
# See http://www.pool.ntp.org/join.html for more information.
pool ntp.ubuntu.com        iburst maxsources 4
pool 0.ubuntu.pool.ntp.org iburst maxsources 1
pool 1.ubuntu.pool.ntp.org iburst maxsources 1
pool 2.ubuntu.pool.ntp.org iburst maxsources 2

# This directive specify the location of the file containing ID/key pairs for
# NTP authentication.
keyfile /etc/chrony/chrony.keys

# This directive specify the file into which chronyd will store the rate
# information.
driftfile /var/lib/chrony/chrony.drift

# Uncomment the following line to turn logging on.
#log tracking measurements statistics
allow
# Log files location.
logdir /var/log/chrony

# Stop bad estimates upsetting machine clock.
maxupdateskew 100.0

# This directive enables kernel synchronisation (every 11 minutes) of the
# real-time clock. Note that it can’t be used along with the 'rtcfile' directive.
#rtcsync

# Step the system clock instead of slewing it if the adjustment is larger than
# one second, but only in the first three clock updates.
rtcsync
refclock SHM 0 refid GPS offset 0.2 precision 1e-1 noselect
refclock PPS /dev/pps0 refid PPS lock GPS precision 1e-9 offset 0.002 prefer

log tracking measurements statistics
makestep 1 3

timedatectl

timedatectl
               Local time: Wed 2020-01-01 00:13:47 KST
           Universal time: Tue 2019-12-31 15:13:47 UTC
                 RTC time: n/a
                Time zone: Asia/Seoul (KST, +0900)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

chronyc tracking

chronyc tracking
Reference ID    : 50505300 (PPS)
Stratum         : 1
Ref time (UTC)  : Sun May 01 01:38:14 2022
System time     : 73563848.000000000 seconds slow of NTP time
Last offset     : -0.000000430 seconds
RMS offset      : 1670042.625000000 seconds
Frequency       : 13.020 ppm fast
Residual freq   : -0.018 ppm
Skew            : 0.032 ppm
Root delay      : 0.000000001 seconds
Root dispersion : 0.000025015 seconds
Update interval : 14.9 seconds
Leap status     : Normal

If you look at the screen above, the timedatectl and chronyc tracking times are different.

If the ntp service is turned off and on or chronyd is restarted, it will be synchronized again.

If you have any information, I'd appreciate it if you could tell me.

Answer 1

Yes.

date -s doesn't know anything about NTP. And if you change the date/time to something too large away from the real time, then NTP will fail (continue to run, but not try to adjust time anymore).

The way NTP works (at least on Linux, but I suspect quite a few OSes) is to adjust the date on startup. That means if you are missing a clock battery, after a cold reboot, your date and time could be reset back to Jan 1, 1970... but NTP will properly adjust the date and time to "now".

Adjusting the date further is done automatically with the NTP system, so there is really no need to do anything else.

Also, once in a while, NTP could be stuck for too long (i.e. your Internet connection goes down for several hours) and the clock could drift so much that it's completely off. In that case, you can simple restart the NTP server.

If you instead want to use Chrony, it works in a similar way, it is limited to just a client, though, and it does not support all the features that the default Linux NTP service offers. But for more Desktop system, that's more than enough.

I don't know much about Chrony and other NTP like services, so I do not know how they behave if you change the date dramatically.

Answer 2

The makestep 1 3 directive in your chrony.conf allows the system clock to be corrected by step only in the first three updates of the clock. That is the default in most distributions and it's generally a good thing.

If you make a large change with date -s, chronyd will measure the new offset (as shown by the chronyc tracking command), but it will not be allowed to correct it quickly by step. It can only speed up or slow down the clock. It would take many years to correct such a large offset.

You need to either change the makestep directive to makestep 1 -1 to allow steps at any update, or better make a much smaller adjustment of the clock (e.g. date -s '+2 sec') to verify the recovery of synchronization.