chrony compared to other programs
1.1. How does
chrony compare to
chronyd was designed to work well in a wide range of conditions and it can
usually synchronise the system clock faster and with better time accuracy. It
doesn’t implement some of the less useful NTP modes like broadcast client or
If your computer is connected to the internet only for few minutes at a time,
the network connection is often congested, you turn your computer off or
suspend it frequently, the clock is not very stable (e.g. there are rapid
changes in the temperature or it’s a virtual machine), or you want to use NTP
on an isolated network with no hardware reference clocks in sight,
will probably work much better for you.
The original reason
chrony was written was that
xntpd at the
time) could not to do anything sensible on a PC which was connected to the 'net
only for about 5 minutes once or twice a day, mainly to upload/download email
and news. The requirements were
slew the time to correct it when going online and NTP servers become visible
determine the rate at which the computer gains or loses time and use this information to keep it reasonably correct between connects to the 'net. This has to be done using a method that does not care about the intermittent availability of the references or the fact the computer is turned off between groups of measurements.
maintain the time across reboots, by working out the error and drift rate of the computer’s real-time clock and using this information to set the system clock correctly at boot up.
Also, when working with isolated networks with no true time references at all
ntpd was found to give no help with managing the local clock’s gain/loss rate
on the NTP master node (which was set from watch). Some automated support was
chrony to deal with this.
2. Configuration issues
2.1. What is the minimum recommended configuration for an NTP client?
First, the client needs to know which NTP servers it should ask for the current
time. They are specified by the
pool directive. The
directive can be used for names that resolve to multiple addresses. For good
reliability the client should have at least three servers. The
speeds up the initial synchronisation.
To stabilize the initial synchronisation on the next start, the estimated drift
of the system clock is saved by adding the
If the system clock can be far from the true time after boot for any reason,
chronyd should be allowed to correct it quickly by stepping instead of
slewing, which would take a very long time. The
makestep directive does
In order to keep the real-time clock (RTC) close to the true time on Linux, so
the system time is reasonably close to the true time when it’s initialized on
the next boot from the RTC, the
rtcsync directive enables a kernel mode in
which the system time is copied to the RTC every 11 minutes.
If you want to use public NTP servers from the pool.ntp.org project, the minimal chrony.conf file could be:
pool pool.ntp.org iburst driftfile /var/lib/chrony/drift makestep 1 3 rtcsync
2.2. How do I make an NTP server from an NTP client?
You need to add an
allow directive to the chrony.conf file in order to open
the NTP port and allow
chronyd to reply to client requests.
allow with no
specified subnet allows all IPv4 and IPv6 addresses.
2.3. I have several computers on a LAN. Should be all clients of an external server?
The best configuration is usually to make one computer the master, with
the others as clients of it. Add a
local directive to the master’s
chrony.conf file. This configuration will be better because
the load on the external connection is less
the load on the external NTP server(s) is less
if your external connection goes down, the computers on the LAN will maintain a common time with each other.
2.4. Must I specify servers by IP address if DNS is not available on chronyd start?
No. Starting from version 1.25,
chronyd will keep trying to resolve
the hostnames specified in the
peer directives in
increasing intervals until it succeeds. The
online command can be
chronyc to try to resolve them immediately.
2.5. How can I make
chronyd more secure?
If you don’t need to serve time to NTP clients or peers, you can add
to the chrony.conf file to completely disable the NTP server functionality
and prevent NTP requests from reaching
chronyd. Starting from version 2.0,
the NTP server port is open only when client access is allowed by the
directive or command, an NTP peer is configured, or the
If you don’t need to use
chronyc remotely, you can add the following
directives to the configuration file to bind the command sockets to the
loopback interface. This is done by default since version 2.0.
bindcmdaddress 127.0.0.1 bindcmdaddress ::1
If you don’t need to use
chronyc at all or you need to run
under the root or chrony user (which can access
chronyd through a Unix domain
socket since version 2.2), you can disable the internet command sockets
completely by adding
cmdport 0 to the configuration file.
You can specify an unprivileged user with the
-u option, or the
directive in the chrony.conf file, to which
chronyd will switch after start
in order to drop root privileges. The configure script has a
option, which sets the default user. On Linux,
chronyd needs to be compiled
with support for the
libcap library. On other systems,
chronyd forks into
two processes. The child process retains root privileges, but can only perform
a very limited range of privileged system calls on behalf of the parent.
chronyd is compiled with support for the Linux secure computing
(seccomp) facility, you can enable a system call filter with the
It will significantly reduce the kernel attack surface and possibly prevent
kernel exploits from the
chronyd process if it’s compromised. It’s
recommended to enable the filter only when it’s known to work on the version of
the system where
chrony is installed as the filter needs to allow also system
calls made from libraries that
chronyd is using (e.g. libc) and different
versions or implementations of the libraries may make different system calls.
If the filter is missing some system call,
chronyd could be killed even in
2.6. How can I improve the accuracy of the system clock with NTP sources?
Select NTP servers that are well synchronised, stable and close to your
network. It’s better to use more than one server, three or four is usually
recommended as the minimum, so
chronyd can detect falsetickers and combine
measurements from multiple sources.
There are also useful options which can be set in the
server directive, they
The first three options set the minimum and maximum allowed polling interval,
and how should be the actual interval adjusted in the specified range. Their
default values are 6 (64 seconds) for
minpoll, 10 (1024 seconds) for
maxpoll and 6 (samples) for
polltarget. The default values should be used
for general servers on the internet. With your own NTP servers or if have
permission to poll some servers more frequently, setting these options for
shorter polling intervals may significantly improve the accuracy of the system
The optimal polling interval depends on many factors, including the ratio between the wander of the clock and the network jitter (sometimes expressed in NTP documents as the Allan intercept), the temperature sensitivity of the crystal oscillator and the maximum rate of change of the temperature.
An example of the directive for an NTP server on the internet that you are allowed to poll frequently could be
server foo.example.net minpoll 4 maxpoll 6 polltarget 16
An example using very short polling intervals for a server located in the same LAN could be
server ntp.local minpoll 2 maxpoll 4 polltarget 30
The maxdelay options are useful to ignore measurements with larger delay (e.g.
due to congestion in the network) and improve the stability of the
maxdelaydevratio option could be added to the example
with local NTP server
server ntp.local minpoll 2 maxpoll 4 polltarget 30 maxdelaydevratio 2
2.7. What happened to the
They were removed in version 2.2. Authentication is no longer supported in the
command protocol. Commands that required authentication are now allowed only
through a Unix domain socket, which is accessible only by the root and chrony
users. If you need to configure
chronyd remotely or locally without the root
password, please consider using ssh and/or sudo to run
chronyc under the root
or chrony user on the same host as
chronyd is running.
3. Computer is not synchronising
This is the most common problem. There are a number of reasons, see the following questions.
3.1. Behind a firewall?
If there is a firewall between you and the NTP server you’re trying to use, the
packets may be blocked. Try using a tool like
tcpdump to see if
you’re getting responses from the server. If you have an external modem, see
if the receive light blinks straight after the transmit light (when the link is
quiet apart from the NTP traffic.) Try adding
log measurements to the
chrony.conf file and look in the measurements.log file after
been running for a short period. See if any measurements appear.
3.2. Are NTP servers specified with the
Check that you’re using
appropriately. Again, check in 'measurements.log' to see if you’re getting any
data back from the server.
chronyd allowed to step the system clock?
chronyd adjusts the clock gradually by slowing it down or
speeding it up. If the clock is too far from the correct time, it will take
a long time to correct the error. The
System time value printed by the
tracking command is the remaining correction that needs to be
applied to the system clock.
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 RTC or virtual machine which can be suspended and resumed with incorrect time) it may be necessary to allow the step at any clock update. The example above would change to
makestep 1 -1
4. Issues with
4.1. I keep getting the error
506 Cannot talk to daemon
chronyd remotely, make sure that the chrony.conf file (on
the computer where
chronyd is running) has a cmdallow entry for the
computer you are running
chronyc on and an appropriate bindcmdaddress
directive. This isn’t necessary for localhost.
chronyd is not running. Try using the
ps command (e.g. on Linux,
ps -auxw) to see if it’s running. Or try
netstat -a and see if the ports
123/udp and 323/udp are listening. If
chronyd is not running, you may have a
problem with the way you are trying to start it (e.g. at boot time).
Perhaps you have a firewall set up in a way that blocks packets on port 323/udp. You need to amend the firewall configuration in this case.
4.2. I keep getting the error
501 Not authorised
Since version 2.2, the
password command doesn’t do anything and
needs to run locally under the root or chrony user, which are allowed to
chronyd's Unix domain command socket.
With older versions, you need to authenticate with the
password command or
-a option to authenticate automatically. The configuration file
needs to specify a file which contains keys (
keyfile directive) and which key
in the key file should be used for
chronyc authentication (
4.3. Is the
chronyd protocol documented anywhere?
Only by the source code :-) See cmdmon.c (
chronyd side) and client.c
5. Real-time clock issues
5.1. What is the real-time clock (RTC)?
This is the clock which keeps the time even when your computer is turned off. It is used to initialize the system clock on boot. It normally doesn’t drift more than few seconds per day.
There are two approaches how
chronyd can work with it. One is to use the
rtcsync directive, which tells
chronyd to enable a kernel mode which sets
the RTC from the system clock every 11 minutes.
chronyd itself won’t touch
the RTC. If the computer is not turned off for a long time, the RTC should
still be close to the true time when the system clock will be initialized from
it on the next boot.
The other option is to use the
rtcfile directive, which will tell
to monitor the rate at which the RTC gains or loses time. When
started with the
-s option on the next boot, it will set the system time from
the RTC and also compensate for the drift it has measured previously. The
rtcautotrim directive can be used to keep the RTC close to the true time, but
it’s not strictly necessary if its only purpose is to set the system clock when
chronyd is started on boot. See the documentation for details.
5.2. I want to use
chronyd's RTC support. Must I disable
hwclock program is often set-up by default in the boot and shutdown
scripts with many Linux installations. With the kernel RTC synchronisation
rtcsync directive), the RTC will be set also every 11 minutes as long as the
system clock is synchronised. If you want to use
chronyd's RTC monitoring
rtcfile directive), it’s important to disable
hwclock in the shutdown
procedure. If you don’t, it will over-write the RTC with a new value, unknown
chronyd. At the next reboot,
chronyd started with the
-s option will
compensate this (wrong) time with its estimate of how far the RTC has drifted
whilst the power was off, giving a meaningless initial system time.
There is no need to remove
hwclock from the boot process, as long as
is started after it has run.
5.3. I just keep getting the
513 RTC driver not running message
For the real time clock support to work, you need the following three things
a kernel that is supported (e.g. 2.2 onwards)
enhanced RTC support compiled into the kernel
rtcfiledirective in your chrony.conf file
6. NTP-specific issues
chronyd be driven from broadcast NTP servers?
No, the broadcast client mode is not supported and there is currently no plan to implement it. The broadcast and multicast modes are inherently less accurate and less secure (even with authentication) than the ordinary server/client mode and they are not as useful as they used to be. Even with very modest hardware a single NTP server can serve time to hundreds of thousands of clients using the ordinary mode.
chronyd transmit broadcast NTP packets?
broadcast directive can be used to enable the broadcast server mode
to serve time to clients in the network which support the broadcast client mode
(it’s not supported in
chronyd, see the previous question).
chronyd keep the system clock a fixed offset away from real time?
This is not possible as the program currently stands.
6.4. What happens if the network connection is dropped without using
offline command first?
chronyd will keep trying to access the server(s) that it thinks are online.
When the network is connected again, it will take some time (on average half of
the current polling interval) before new measurements are made and the clock is
corrected. If the servers were set to offline and the
online command was
issued when the network was connected,
chronyd would make new measurements
auto_offline option to the
server entry in the chrony.conf file may
be useful to switch the servers to the offline state automatically.
7. Linux-specific issues
7.1. I get
Could not open /dev/rtc, Device or resource busy in my syslog file
Some other program running on the system may be using the device.
8. Microsoft Windows
chrony support Windows?
chronyc program (the command-line client used for configuring
chronyd while it is running) has been successfully built and run under
Cygwin in the past.
chronyd is not portable, because part of it is
very system-dependent. It needs adapting to work with Windows'
equivalent of the adjtimex() call, and it needs to be made to work as a
8.2. Are there any plans to support Windows?
We have no plans to do this. Anyone is welcome to pick this work up and contribute it back to the project.