• Centos 7
  • chronyd (chrony) version 3.1


I am encountering an issue with chonyd and server date.

First, change current date to old date

I changed the hardware clock date from the current real date mar. nov. 27 15:57:12 CET 2018 to mer. déc. 12 12:12:12 CET 2012 using the following commands :

hwclock --set --date="12/12/2012 12:12:12"
hwclock -s

Then, start chronyd service to fetch the real good date

I start the chronyd service using systemctl start chronyd, and check the status using systemctl status chronyd, here is the output to show you that the chronyd service is running correctly :

● chronyd.service - NTP client/server
   Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
Active: active (running) since mer. 2012-12-12 12:20:14 CET; 27min ago


déc. 12 12:20:17 pad chronyd[1808]: Selected source
déc. 12 12:20:17 pad chronyd[1808]: System clock wrong by 188017778.899985 seconds, adjustment started
déc. 12 12:25:37 pad chronyd[1808]: Selected source

Here is the /etc/chrony.conf configuration file :

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

# Enable kernel synchronization of the real-time clock (RTC).

# Enable hardware timestamping on all interfaces that support it.
hwtimestamp *

# Specify directory for log files.
logdir /var/log/chrony

server 0.fr.pool.ntp.org minpoll 0 maxpoll 0
server 1.fr.pool.ntp.org minpoll 0 maxpoll 0
server 2.fr.pool.ntp.org minpoll 0 maxpoll 0
server 3.fr.pool.ntp.org minpoll 0 maxpoll 0

Here is the chronyc sources output after chronyd start :

^+ obelix.fraho.eu               2   0   377     0   -876us[ -876us] +/-   12ms
^- bb8.dousse.eu                 2   7   377    40  -1547us[-1547us] +/-   52ms
^- cdg1.m-d.net                  2   6   377    39   -806us[ -806us] +/-   33ms
^* cluster004.linocomm.net       2   7   377   100   +330us[ +384us] +/- 7957us

The output tells that the server is connected, showing the ^+ characters at that of obelix.fraho.eu ntp host server.

Finally, i wait that the chronyd daemon update the date and show the date

After more than 60 minutes, i run the command date in my terminal and get the following output :

mer. déc. 12 13:15:04 CET 2012

The date has not been updated by chronyd ...

The folder /var/log/chronyd/ is empty

Any idea ?

  • "System clock wrong by 188017778.899985 seconds, adjustment started" Nov 27, 2018 at 15:09
  • @IporSircer the adjustment started means that it could take many hours / days to adjust ?
    – Alrick
    Nov 27, 2018 at 15:15

1 Answer 1


Quoting the official FAQ, chronyd will only adjust the clock gradually:

By default, chronyd adjusts the clock gradually by slowing it down or speeding it up. If the clock is too far from the true time, it will take a long time to correct the error. The System time value printed by the chronyc's tracking command is the remaining correction that needs to be applied to the system clock.

As stated here, you would probably be able to verify that your clock is actually adjusting by observing the System time line of the output of chronyc tracking (see the tracking section in man chronyc for details).

To let chronyd be able to step the clock, you have to add the makestep directive in chrony.conf:

# Step the clock on the first three updates
# if its offset is larger than one second
makestep 1 3

Sometimes - e.g. on virtual machines, that can be suspended and resumed - you may want to let chronyd step the clock on any update, not just the first ones after it starts:

# Step the clock on any update 
# if its offset is larger than one second
makestep 1 -1

But bear in mind the warnings in the official documentation (again from man chronyc):

[...] any jump in the time can have adverse consequences for certain application programs.

  • This solves my issue thank you. I found this post on Serverfault that is a duplicate of here : serverfault.com/questions/819467/…
    – Alrick
    Nov 27, 2018 at 16:15
  • Ah, so for a laptop where the time is frequently suspended, the time is so often wrong! Mar 23, 2023 at 19:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .