1#@!#!123s

��JFIF�� 1#@!#!123s
: / usr / share / doc / chrony /
Filename : FAQ
back
Frequently Asked Questions

Table of Contents

  o 1. chrony compared to other programs
      ? 1.1. How does chrony compare to ntpd?
      ? 1.2. Should I prefer chrony over timesyncd if I do not need to run a
        server?
  o 2. Configuration issues
      ? 2.1. What is the minimum recommended configuration for an NTP client?
      ? 2.2. How do I make an NTP server?
      ? 2.3. Should all computers on a LAN be clients of an external server?
      ? 2.4. Must I specify servers by IP address if DNS is not available on
        chronyd start?
      ? 2.5. How can I make chronyd more secure?
      ? 2.6. How can I make the system clock more secure?
      ? 2.7. How can I improve the accuracy of the system clock with NTP
        sources?
      ? 2.8. Does chronyd have an ntpdate mode?
      ? 2.9. Can chronyd be configured to control the clock like ntpd?
      ? 2.10. Can NTP server be separated from NTP client?
      ? 2.11. How can chronyd be configured to minimise downtime during
        restarts?
      ? 2.12. Should be a leap smear enabled on NTP server?
      ? 2.13. How should chronyd be configured with gpsd?
      ? 2.14. Does chrony support PTP?
      ? 2.15. How can I avoid using wrong PHC refclock?
      ? 2.16. Why are client log records dropped before reaching
        clientloglimit?
      ? 2.17. What happened to the commandkey and generatecommandkey
        directives?
  o 3. Computer is not synchronising
      ? 3.1. Behind a firewall?
      ? 3.2. Are NTP servers specified with the offline option?
      ? 3.3. Is name resolution working correctly?
      ? 3.4. Is chronyd allowed to step the system clock?
      ? 3.5. Using NTS?
      ? 3.6. Using a Windows NTP server?
      ? 3.7. An unreachable source is selected?
      ? 3.8. Does selected source drop new measurements?
      ? 3.9. Using a PPS reference clock?
  o 4. Issues with chronyc
      ? 4.1. I keep getting the error 506 Cannot talk to daemon
      ? 4.2. I keep getting the error 501 Not authorised
      ? 4.3. What is the reference ID reported by the tracking command?
      ? 4.4. Is the chronyc / chronyd protocol documented anywhere?
  o 5. Real-time clock issues
      ? 5.1. What is the real-time clock (RTC)?
      ? 5.2. Does hwclock have to be disabled?
      ? 5.3. I just keep getting the 513 RTC driver not running message
      ? 5.4. I get Could not open /dev/rtc, Device or resource busy in my
        syslog file
      ? 5.5. When I start chronyd, the log says Could not enable RTC interrupt
        : Invalid argument (or it may say disable)
      ? 5.6. What if my computer does not have an RTC or backup battery?
  o 6. NTP-specific issues
      ? 6.1. Can chronyd be driven from broadcast/multicast NTP servers?
      ? 6.2. Can chronyd transmit broadcast NTP packets?
      ? 6.3. Can chronyd keep the system clock a fixed offset away from real
        time?
      ? 6.4. What happens if the network connection is dropped without using
        chronyc's offline command first?
      ? 6.5. Why is an offset measured between two computers synchronised to
        each another?
  o 7. Operation
      ? 7.1. What clocks does chronyd use?
  o 8. Operating systems
      ? 8.1. Does chrony support Windows?
      ? 8.2. Are there any plans to support Windows?

1. chrony compared to other programs

1.1. How does chrony compare to ntpd?

chrony and ntpd are two different implementations of the Network Time Protocol
(NTP).

chrony is a newer implementation, which was designed to work well in a wider
range of conditions. It can usually synchronise the system clock faster and
with better time accuracy. It has many features, but it does not implement some
of the less useful NTP modes like broadcast client or multicast server/client.

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 is a virtual machine), or you want to use NTP
on an isolated network with no hardware reference clocks in sight, chrony will
probably work better for you.

For a more detailed comparison of features and performance, see the comparison
page on the chrony website.

1.2. Should I prefer chrony over timesyncd if I do not need to run a server?

Generally, yes.

systemd-timesyncd is a very simple NTP client included in the systemd suite. It
lacks almost all features of chrony and other advanced client implementations
listed on the comparison page. One of its main limitations is that it cannot
poll multiple servers at the same time and detect servers having incorrect time
(falsetickers in the NTP terminology). It should be used only with trusted
reliable servers, ideally in local network.

Using timesyncd with pool.ntp.org is problematic. The pool is very robust as a
whole, but the individual servers run by volunteers cannot be relied on.
Occasionally, servers drift away or make a step to distant past or future due
to misconfiguration, problematic implementation, and other bugs (e.g. in
firmware of a GPS receiver). The pool monitoring system detects such servers
and quickly removes them from the pool DNS, but clients like timesyncd cannot
recover from that. They follow the server as long as it claims to be
synchronised. They need to be restarted in order to get a new address from the
pool DNS.

Note that the complexity of NTP and clock synchronisation is on the client
side. The amount of code in chrony specific to NTP server is very small and it
is disabled by default. If it was removed, it would not significantly reduce
the amount of memory or storage needed.

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 server or pool directive. The pool directive is
used with names that resolve to multiple addresses of different servers. For
reliable operation, the client should have at least three servers.

The iburst option enables a burst of requests to speed up the initial
synchronisation.

To stabilise the initial synchronisation on the next start, the estimated drift
of the system clock is saved to a file specified by the driftfile directive.

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 that.

In order to keep the real-time clock (RTC) close to the true time, so the
system time is reasonably close to the true time when it is initialised on the
next boot from the RTC, the rtcsync directive enables a mode in which the
system time is periodically copied to the RTC. It is supported on Linux and
macOS.

If you wanted 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?

By default, chronyd does not operate as an NTP server. You need to add an allow
directive to the chrony.conf file in order for chronyd to open the server NTP
port and respond to client requests.

allow 192.168.1.0/24

An allow directive with no specified subnet allows access from all IPv4 and
IPv6 addresses.

2.3. Should all computers on a LAN be clients of an external server?

It depends on the requirements. Usually, the best configuration is to make one
computer the server, with the others as clients of it. Add a local directive to
the server's chrony.conf file. This configuration will be better because

  o the load on the external connection is less

  o the load on the external NTP server(s) is less

  o 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, chronyd will keep trying to resolve the names specified by the server,
pool, and peer directives in an increasing interval until it succeeds. The
online command can be issued from chronyc to force chronyd to try to resolve
the names immediately.

2.5. How can I make chronyd more secure?

If you do not need to use chronyc, or you want to run chronyc only under the
root or chrony user (which can access chronyd through a Unix domain socket),
you can disable the IPv4 and IPv6 command sockets (by default listening on
localhost) by adding cmdport 0 to the configuration file.

You can specify an unprivileged user with the -u option, or the user directive
in the chrony.conf file, to which chronyd will switch after start in order to
drop root privileges. The configure script has a --with-user 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.

Also, if chronyd is compiled with support for the Linux secure computing
(seccomp) facility, you can enable a system call filter with the -F option. It
will significantly reduce the kernel attack surface and possibly prevent kernel
exploits from the chronyd process if it is compromised. It is recommended to
enable the filter only when it is 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 might make different system calls. If the
filter is missing some system call, chronyd could be killed even in normal
operation.

2.6. How can I make the system clock more secure?

An NTP client synchronising the system clock to an NTP server is susceptible to
various attacks, which can break applications and network protocols relying on
accuracy of the clock (e.g. DNSSEC, Kerberos, TLS, WireGuard).

Generally, a man-in-the-middle (MITM) attacker between the client and server
can

  o make fake responses, or modify real responses from the server, to create an
    arbitrarily large time and frequency offset, make the server appear more
    accurate, insert a leap second, etc.

  o delay the requests and/or responses to create a limited time offset and
    temporarily also a limited frequency offset

  o drop the requests or responses to prevent updates of the clock with new
    measurements

  o redirect the requests to a different server

The attacks can be combined for a greater effect. The attacker can delay
packets to create a significant frequency offset first and then drop all
subsequent packets to let the clock quickly drift away from the true time. The
attacker might also be able to control the server's clock.

Some attacks cannot be prevented. Monitoring is needed for detection, e.g. the
reachability register in the sources report shows missing packets. The extent
to which the attacker can control the client's clock depends on its
configuration.

Enable authentication to prevent chronyd from accepting modified, fake, or
redirected packets. It can be enabled with a symmetric key specified by the key
option, or Network Time Security (NTS) by the nts option (supported since
chrony version 4.0). The server needs to support the selected authentication
mechanism. Symmetric keys have to be configured on both client and server, and
each client must have its own key (one per server).

The maximum offset that the attacker can insert in an NTP measurement by
delaying packets can be limited by the maxdelay option. The default value is 3
seconds. The measured delay is reported as the peer delay in the ntpdata report
and measurements log. Set the maxdelay option to a value larger than the
maximum value that is normally observed. Note that the delay can increase
significantly even when not under an attack, e.g. when the network is congested
or the routing has changed.

The maximum accepted change in time offset between clock updates can be limited
by the maxchange directive. Larger changes in the offset will be ignored or
cause chronyd to exit. Note that the attacker can get around this limit by
splitting the offset into multiple smaller offsets and/or creating a large
frequency offset. When this directive is used, chronyd will have to be
restarted after a successful attack. It will not be able to recover on its own.
It must not be restarted automatically (e.g. by the service manager).

The impact of a large accepted time offset can be reduced by disabling clock
steps, i.e. by not using the makestep and initstepslew directives. The offset
will be slowly corrected by speeding up or slowing down the clock at a rate
which can be limited by the maxslewrate directive. Disabling clock steps
completely is practical only if the clock cannot gain a larger error on its
own, e.g. when the computer is shut down or suspended, and the maxslewrate
limit is large enough to correct an expected error in an acceptable time. The
rtcfile directive with the -s option can be used to compensate for the RTC
drift.

A more practical approach is to enable makestep for a limited number of clock
updates (the 2nd argument of the directive) and limit the offset change in all
updates by the maxchange directive. The attacker will be able to make only a
limited step and only if the attack starts in a short window after booting the
computer, or when chronyd is restarted without the -R option.

The frequency offset can be limited by the maxdrift directive. The measured
frequency offset is reported in the drift file, tracking report, and tracking
log. Set maxdrift to a value larger than the maximum absolute value that is
normally observed. Note that the frequency of the clock can change due to aging
of the crystal, differences in calibration of the clock source between reboots,
migrated virtual machine, etc. A typical computer clock has a drift smaller
than 100 parts per million (ppm), but much larger drifts are possible (e.g. in
some virtual machines).

Use only trusted servers, which you expect to be well configured and managed,
using authentication for their own servers, etc. Use multiple servers, ideally
in different locations. The attacker will have to deal with a majority of the
servers in order to pass the source selection and update the clock with a large
offset. Use the minsources directive to increase the required number of
selectable sources to make the selection more robust.

Do not specify servers as peers. The symmetric mode is less secure than the
client/server mode. If not authenticated, it is vulnerable to off-path
denial-of-service attacks, and even when it is authenticated, it is still
susceptible to replay attacks.

Mixing of authenticated and unauthenticated servers should generally be
avoided. If mixing is necessary (e.g. for a more accurate and stable
synchronisation to a closer server which does not support authentication), the
authenticated servers should be configured as trusted and required to not allow
the unauthenticated servers to override the authenticated servers in the source
selection. Since chrony version 4.0, the selection options are enabled in such
a case automatically. This behaviour can be disabled or modified by the
authselectmode directive.

An example of a client configuration limiting the impact of the attacks could
be

server ntp1.example.net iburst nts maxdelay 0.1
server ntp2.example.net iburst nts maxdelay 0.2
server ntp3.example.net iburst nts maxdelay 0.05
server ntp4.example.net iburst nts maxdelay 0.1
server ntp5.example.net iburst nts maxdelay 0.1
minsources 3
maxchange 100 0 0
makestep 0.001 1
maxdrift 100
maxslewrate 100
driftfile /var/lib/chrony/drift
ntsdumpdir /var/lib/chrony
rtcsync

2.7. 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 is better to use more than one server. Three or four is usually
recommended as the minimum, so chronyd can detect servers that serve false time
and combine measurements from multiple sources.

If you have a network card with hardware timestamping supported on Linux, it
can be enabled by the hwtimestamp directive. It should make local receive and
transmit timestamps of NTP packets much more stable and accurate.

The server directive has some useful options: minpoll, maxpoll, polltarget,
maxdelay, maxdelayratio, maxdelaydevratio, xleave, filter.

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 8 (samples) for polltarget. The default values should be used for general
servers on the Internet. With your own NTP servers, or if you have permission
to poll some servers more frequently, setting these options for shorter polling
intervals might significantly improve the accuracy of the system clock.

The optimal polling interval depends mainly on two factors, stability of the
network latency and stability of the system clock (which mainly depends on the
temperature sensitivity of the crystal oscillator and the maximum rate of the
temperature change).

Generally, if the sourcestats command usually reports a small number of samples
retained for a source (e.g. fewer than 16), a shorter polling interval should
be considered. If the number of samples is usually at the maximum of 64, a
longer polling interval might work better.

An example of the directive for an NTP server on the Internet that you are
allowed to poll frequently could be

server ntp.example.net minpoll 4 maxpoll 6 polltarget 16

An example using shorter polling intervals with 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 an unusually large
delay (e.g. due to congestion in the network) and improve the stability of the
synchronisation. The maxdelaydevratio option could be added to the example with
local NTP server

server ntp.local minpoll 2 maxpoll 4 polltarget 30 maxdelaydevratio 2

If your server supports the interleaved mode (e.g. it is running chronyd), the
xleave option should be added to the server directive to enable the server to
provide the client with more accurate transmit timestamps (kernel or preferably
hardware). For example:

server ntp.local minpoll 2 maxpoll 4 xleave

When combined with local hardware timestamping, good network switches, and even
shorter polling intervals, a sub-microsecond accuracy and stability of a few
tens of nanoseconds might be possible. For example:

server ntp.local minpoll 0 maxpoll 0 xleave
hwtimestamp eth0

For best stability, the CPU should be running at a constant frequency (i.e.
disabled power saving and performance boosting). Energy-Efficient Ethernet
(EEE) should be disabled in the network. The switches should be configured to
prioritize NTP packets, especially if the network is expected to be heavily
loaded. The dscp directive can be used to set the Differentiated Services Code
Point in transmitted NTP packets if needed.

If it is acceptable for NTP clients in the network to send requests at a high
rate, a sub-second polling interval can be specified. A median filter can be
enabled in order to update the clock at a reduced rate with more stable
measurements. For example:

server ntp.local minpoll -6 maxpoll -6 filter 15 xleave
hwtimestamp eth0 minpoll -6

Since chrony version 4.3, the minimum minpoll is -7 and a filter using a
long-term estimate of a delay quantile can be enabled by the maxdelayquant
option to replace the default maxdelaydevratio filter, which is sensitive to
outliers corrupting the minimum delay. For example:

server ntp.local minpoll -7 maxpoll -7 filter 31 maxdelayquant 0.3 xleave

Since version 4.2, chronyd supports an NTPv4 extension field containing an
additional timestamp to enable frequency transfer and significantly improve
stability of synchronisation. It can be enabled by the extfield F323 option.
For example:

server ntp.local minpoll 0 maxpoll 0 xleave extfield F323

Since version 4.5, chronyd can apply corrections from PTP one-step end-to-end
transparent clocks (e.g. network switches) to significantly improve accuracy of
synchronisation in local networks. It requires the PTP transport to be enabled
by the ptpport directive, HW timestamping, and the extfield F324 option. For
example:

server ntp.local minpoll -4 maxpoll -4 xleave extfield F323 extfield F324 port 319
ptpport 319
hwtimestamp eth0 minpoll -4

2.8. Does chronyd have an ntpdate mode?

Yes. With the -q option chronyd will set the system clock once and exit. With
the -Q option it will print the measured offset without setting the clock. If
you do not want to use a configuration file, NTP servers can be specified on
the command line. For example:

# chronyd -q 'pool pool.ntp.org iburst'

The command above would normally take about 5 seconds if the servers were well
synchronised and responding to all requests. If not synchronised or responding,
it would take about 10 seconds for chronyd to give up and exit with a non-zero
status. A faster configuration is possible. A single server can be used instead
of four servers, the number of measurements can be reduced with the maxsamples
option to one (supported since chrony version 4.0), and a timeout can be
specified with the -t option. The following command would take only up to about
one second.

# chronyd -q -t 1 'server pool.ntp.org iburst maxsamples 1'

It is not recommended to run chronyd with the -q option periodically (e.g. from
a cron job) as a replacement for the daemon mode, because it performs
significantly worse (e.g. the clock is stepped and its frequency is not
corrected). If you must run it this way and you are using a public NTP server,
make sure chronyd does not always start around the first second of a minute,
e.g. by adding a random sleep before the chronyd command. Public servers
typically receive large bursts of requests around the first second as there is
a large number of NTP clients started from cron with no delay.

2.9. Can chronyd be configured to control the clock like ntpd?

It is not possible to perfectly emulate ntpd, but there are some options that
can configure chronyd to behave more like ntpd if there is a reason to prefer
that.

In the following example the minsamples directive slows down the response to
changes in the frequency and offset of the clock. The maxslewrate and
corrtimeratio directives reduce the maximum frequency error due to an offset
correction and the maxdrift directive reduces the maximum assumed frequency
error of the clock. The makestep directive enables a step threshold and the
maxchange directive enables a panic threshold. The maxclockerror directive
increases the minimum dispersion rate.

minsamples 32
maxslewrate 500
corrtimeratio 100
maxdrift 500
makestep 0.128 -1
maxchange 1000 1 1
maxclockerror 15

Note that increasing minsamples might cause the offsets in the tracking and
sourcestats reports/logs to be significantly smaller than the actual offsets
and be unsuitable for monitoring.

2.10. Can NTP server be separated from NTP client?

Yes, it is possible to run multiple instances of chronyd on a computer at the
same time. One can operate primarily as an NTP client to synchronise the system
clock and another as a server for other computers. If they use the same
filesystem, they need to be configured with different pidfiles, Unix domain
command sockets, and any other file or directory specified in the configuration
file. If they run in the same network namespace, they need to use different NTP
and command ports, or bind the ports to different addresses or interfaces.

The server instance should be started with the -x option to prevent it from
adjusting the system clock and interfering with the client instance. It can be
configured as a client to synchronise its NTP clock to other servers, or the
client instance running on the same computer. In the latter case, the copy
option (added in chrony version 4.1) can be used to assume the reference ID and
stratum of the client instance, which enables detection of synchronisation
loops with its own clients.

On Linux, starting with chrony version 4.0, it is possible to run multiple
server instances sharing a port to better utilise multiple cores of the CPU.
Note that for rate limiting and client/server interleaved mode to work well it
is necessary that all packets received from the same address are handled by the
same server instance.

An example configuration of the client instance could be

pool pool.ntp.org iburst
allow 127.0.0.1
port 11123
driftfile /var/lib/chrony/drift
makestep 1 3
rtcsync

and configuration of the first server instance could be

server 127.0.0.1 port 11123 minpoll 0 maxpoll 0 copy
allow
cmdport 11323
bindcmdaddress /var/run/chrony/chronyd-server1.sock
pidfile /var/run/chronyd-server1.pid
driftfile /var/lib/chrony/drift-server1

2.11. How can chronyd be configured to minimise downtime during restarts?

The dumpdir directive in chrony.conf provides chronyd a location to save a
measurement history of the sources it uses when the service exits. The -r
option then enables chronyd to load state from the dump files, reducing the
synchronisation time after a restart.

Similarly, the ntsdumpdir directive provides a location for chronyd to save NTS
cookies received from the server to avoid making a NTS-KE request when chronyd
is started. When operating as an NTS server, chronyd also saves cookies keys to
this directory to allow clients to continue to use the old keys after a server
restart for a more seamless experience.

On Linux systems, systemd socket activation provides a mechanism to reuse
server sockets across chronyd restarts, so that client requests will be
buffered until the service is again able to handle the requests. This allows
for zero-downtime service restarts, simplified dependency logic at boot, and
on-demand service spawning (for instance, for separated server chronyd
instances run with the -x flag).

Socket activation is supported since chrony version 4.5. The service manager
(systemd) creates sockets and passes file descriptors to them to the process
via the LISTEN_FDS environment variable. Before opening new sockets, chronyd
first checks for and attempts to reuse matching sockets passed from the service
manager. For instance, if an IPv4 datagram socket bound on bindaddress and port
is available, it will be used by the NTP server to accept incoming IPv4
requests.

An example systemd socket unit is below, where chronyd is configured with
bindaddress 0.0.0.0, bindaddress ::, port 123, and ntsport 4460.

[Unit]
Description=chronyd server sockets

[Socket]
Service=chronyd.service
# IPv4 NTP server
ListenDatagram=0.0.0.0:123
# IPv6 NTP server
ListenDatagram=[::]:123
# IPv4 NTS-KE server
ListenStream=0.0.0.0:4460
# IPv6 NTS-KE server
ListenStream=[::]:4460
BindIPv6Only=ipv6-only

[Install]
WantedBy=sockets.target

2.12. Should be a leap smear enabled on NTP server?

With the smoothtime and leapsecmode directives it is possible to enable a
server leap smear in order to hide leap seconds from clients and force them to
follow a slow server's adjustment instead.

This feature should be used only in local networks and only when necessary,
e.g. when the clients cannot be configured to handle the leap seconds as
needed, or their number is so large that configuring them all would be
impractical. The clients should use only one leap-smearing server, or multiple
identically configured leap-smearing servers. Note that some clients can get
leap seconds from other sources (e.g. with the leapsectz directive in chrony)
and they will not work correctly with a leap smearing server.

2.13. How should chronyd be configured with gpsd?

A GPS or other GNSS receiver can be used as a reference clock with gpsd. It can
work as one or two separate time sources for each connected receiver. The first
time source is based on timestamping of messages sent by the receiver.
Typically, it is accurate to milliseconds. The other source is much more
accurate. It is timestamping a pulse-per-second (PPS) signal, usually connected
to a serial port (e.g. DCD pin) or GPIO pin.

If the PPS signal is connected to the serial port which is receiving messages
from the GPS/GNSS receiver, gpsd should detect and use it automatically. If it
is connected to a GPIO pin, or another serial port, the PPS device needs to be
specified on the command line as an additional data source. On Linux, the
ldattach utility can be used to create a PPS device for a serial device.

The PPS-based time source provided by gpsd is available as a SHM 1 refclock, or
other odd number if gpsd is configured with multiple receivers, and also as
SOCK /var/run/chrony.DEV.sock where DEV is the name of the serial device (e.g.
ttyS0).

The message-based time source is available as a SHM 0 refclock (or other even
number) and since gpsd version 3.25 also as SOCK /var/run/chrony.clk.DEV.sock
where DEV is the name of the serial device.

The SOCK refclocks should be preferred over SHM for better security (the shared
memory segment needs to be created by chronyd or gpsd with an expected owner
and permissions before an untrusted application or user has a chance to create
its own in order to feed chronyd with false measurements). gpsd needs to be
started after chronyd in order to connect to the socket.

With chronyd and gpsd both supporting PPS, there are two different recommended
configurations:

# First option
refclock SOCK /var/run/chrony.ttyS0.sock refid GPS

# Second option
refclock PPS /dev/pps0 lock NMEA refid GPS
refclock SOCK /var/run/chrony.clk.ttyS0.sock offset 0.5 delay 0.1 refid NMEA noselect

They both have some advantages:

  o SOCK can be more accurate than PPS if gpsd corrects for the sawtooth error
    provided by the receiver in serial data

  o PPS can be used with higher PPS rates (specified by the rate option), but
    it requires a second refclock or another time source to pair pulses with
    seconds, and the SOCK offset needs to be specified correctly to compensate
    for the message delay, while gpsd can apply HW-specific information

If the PPS signal is not available, or cannot be used for some reason, the only
option is the message-based timing

refclock SOCK /var/run/chrony.clk.ttyS0.sock offset 0.5 delay 0.1 refid GPS

or the SHM equivalent if using gpsd version before 3.25

refclock SHM 0 offset 0.5 delay 0.1 refid GPS

2.14. Does chrony support PTP?

No, the Precision Time Protocol (PTP) is not supported as a protocol for
synchronisation of clocks and there are no plans to support it. It is a complex
protocol, which shares some issues with the NTP broadcast mode. One of the main
differences between NTP and PTP is that PTP was designed to be easily supported
in hardware (e.g. network switches and routers) in order to make more stable
and accurate measurements. PTP relies on the hardware support. NTP does not
rely on any support in the hardware, but if it had the same support as PTP, it
could perform equally well.

On Linux, chrony supports hardware clocks that some NICs have for PTP. They are
called PTP hardware clocks (PHC). They can be used as reference clocks
(specified by the refclock directive) and for hardware timestamping of NTP
packets (enabled by the hwtimestamp directive) if the NIC can timestamp other
packets than PTP, which is usually the case at least for transmitted packets.
The ethtool -T command can be used to verify the timestamping support.

As an experimental feature added in version 4.2, chrony can use PTP as a
transport for NTP messages (NTP over PTP) to enable hardware timestamping on
hardware which can timestamp PTP packets only. It can be enabled by the ptpport
directive. Since version 4.5, chrony can also apply corrections provided by PTP
one-step end-to-end transparent clocks to reach the accuracy of ordinary PTP
clocks. The application of PTP corrections can be enabled by the extfield F324
option.

2.15. How can I avoid using wrong PHC refclock?

If your system has multiple PHC devices, normally named by udev as /dev/ptp0, /
dev/ptp1, and so on, their order can change randomly across reboots depending
on the order of initialisation of their drivers. If a PHC refclock is specified
by this name, chronyd could be using a wrong refclock after reboot. To prevent
that, you can configure udev to create a stable symlink for chronyd with a rule
like this (e.g. written to /etc/udev/rules.d/80-phc.rules):

KERNEL=="ptp[0-9]*", DEVPATH=="/devices/pci0000:00/0000:00:01.2/0000:02:00.0/ptp/*", SYMLINK+="ptp-i350-1"

You can get the full DEVPATH of an existing PHC device with the udevadm info
command. You will need to execute the udevadm trigger command, or reboot the
system, for these changes to take effect.

2.16. Why are client log records dropped before reaching clientloglimit?

The number of dropped client log records reported by the serverstats command
can be increasing before the number of clients reported by the clients command
reaches the maximum value corresponding to the memory limit set by the
clientloglimit directive.

This is due to the design of the data structure keeping the client records. It
is a hash table which can store only up to 16 colliding addresses per slot. If
a slot has more collisions and the table already has the maximum size, the
oldest record will be dropped and replaced by the new client.

Note that the size of the table is always a power of two and it can only grow.
The limit set by the clientloglimit directive takes into account that two
copies of the table exist when it is being resized. This means the actual
memory usage reported by top and other utilities can be significantly smaller
than the limit even when the maximum number of records is used.

The absolute maximum number of client records kept at the same time is
16777216.

2.17. What happened to the commandkey and generatecommandkey directives?

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 host where 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?

Check the Reach value printed by the chronyc's sources command. If it is zero,
it means chronyd did not get any valid responses from the NTP server you are
trying to use. If there is a firewall between you and the server, the requests
sent to the UDP port 123 of the server or responses sent back from the port
might be blocked. Try using a tool like wireshark or tcpdump to see if you are
getting any responses from the server.

When chronyd is receiving responses from the servers, the output of the sources
command issued few minutes after chronyd start might look like this:

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* ntp1.example.net              2   6   377    34   +484us[ -157us] +/-   30ms
^- ntp2.example.net              2   6   377    34    +33ms[  +32ms] +/-   47ms
^+ ntp3.example.net              3   6   377    35  -1397us[-2033us] +/-   60ms

3.2. Are NTP servers specified with the offline option?

Check that the chronyc's online and offline commands are used appropriately
(e.g. in the system networking scripts). The activity command prints the number
of sources that are currently online and offline. For example:

200 OK
3 sources online
0 sources offline
0 sources doing burst (return to online)
0 sources doing burst (return to offline)
0 sources with unknown address

3.3. Is name resolution working correctly?

NTP servers specified by their hostname (instead of an IP address) have to have
their names resolved before chronyd can send any requests to them. If the
activity command prints a non-zero number of sources with unknown address,
there is an issue with the resolution. Typically, a DNS server is specified in
/etc/resolv.conf. Make sure it is working correctly.

Since chrony version 4.0, you can run chronyc -N sources -a command to print
all sources, even those that do not have a known address yet, with their names
as they were specified in the configuration. This can be useful to verify that
the names specified in the configuration are used as expected.

3.4. Is chronyd allowed to step the system clock?

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.

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 is 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 might be
necessary to allow the step on any clock update. The example above would change
to

makestep 1 -1

3.5. Using NTS?

The Network Time Security (NTS) mechanism uses Transport Layer Security (TLS)
to establish the keys needed for authentication of NTP packets.

Run the authdata command to check whether the key establishment was successful:

# chronyc -N authdata
Name/IP address             Mode KeyID Type KLen Last Atmp  NAK Cook CLen
=========================================================================
ntp1.example.net             NTS     1   15  256  33m    0    0    8  100
ntp2.example.net             NTS     1   15  256  33m    0    0    8  100
ntp3.example.net             NTS     1   15  256  33m    0    0    8  100

The KeyID, Type, and KLen columns should have non-zero values. If they are
zero, check the system log for error messages from chronyd. One possible cause
of failure is a firewall blocking the client's connection to the server's TCP
port 4460.

Another possible cause of failure is a certificate that is failing to verify
because the client's clock is wrong. This is a chicken-and-egg problem with
NTS. You might need to manually correct the date, or temporarily disable NTS,
in order to get NTS working. If your computer has an RTC and it is backed up by
a good battery, this operation should be needed only once, assuming the RTC
will be set periodically with the rtcsync directive, or compensated with the
rtcfile directive and the -s option.

If the computer does not have an RTC or battery, you can use the -s option
without rtcfile directive to restore time of the last shutdown or reboot from
the drift file. The clock will start behind the true time, but if the computer
was not shut down for too long and the server's certificate was not renewed too
close to its expiration, it should be sufficient for the time checks to
succeed.

If you run your own server, you can use a self-signed certificate covering all
dates where the client can start (e.g. years 1970-2100). The certificate needs
to be installed on the client and specified with the ntstrustedcerts directive.
The server can have multiple names and certificates. To avoid trusting a
certificate for too long, a new certificate can be added to the server
periodically (e.g. once per year) and the client can have the server name and
trusted certificate updated automatically (e.g. using a package repository, or
a cron script downloading the files directly from the server over HTTPS). A
client that was shut down for years will still be able to synchronise its clock
and perform the update as long as the server keeps the old certificate.

As a last resort, you can disable the time checks by the nocerttimecheck
directive. This has some important security implications. To reduce the
security risk, you can use the nosystemcert and ntstrustedcerts directives to
disable the system's default trusted certificate authorities and trust only a
minimal set of selected authorities needed to validate the certificates of used
NTP servers.

3.6. Using a Windows NTP server?

A common issue with Windows NTP servers is that they report a very large root
dispersion (e.g. three seconds or more), which causes chronyd to ignore the
server for being too inaccurate. The sources command might show a valid
measurement, but the server is not selected for synchronisation. You can check
the root dispersion of the server with the chronyc's ntpdata command.

The maxdistance value needs to be increased in chrony.conf to enable
synchronisation to such a server. For example:

maxdistance 16.0

3.7. An unreachable source is selected?

When chronyd is configured with multiple time sources, it tries to select the
most accurate and stable sources for synchronisation of the system clock. They
are marked with the * or + symbol in the report printed by the sources command.

When the best source (marked with the * symbol) becomes unreachable (e.g. NTP
server stops responding), chronyd will not immediately switch to the second
best source in an attempt to minimise the error of the clock. It will let the
clock run free for as long as its estimated error (in terms of root distance)
based on previous measurements is smaller than the estimated error of the
second source, and there is still an interval which contains some measurements
from both sources.

If the first source was significantly better than the second source, it can
take many hours before the second source is selected, depending on its polling
interval. You can force a faster reselection by increasing the clock error rate
(maxclockerror directive), shortening the polling interval (maxpoll option), or
reducing the number of samples (maxsamples option).

3.8. Does selected source drop new measurements?

chronyd can drop a large number of successive NTP measurements if they are not
passing some of the NTP tests. The sources command can report for a selected
source the fully-reachable value of 377 in the Reach column and at the same
time a LastRx value that is much larger than the current polling interval. If
the source is online, this indicates that a number of measurements was dropped.
You can use the ntpdata command to check the NTP tests for the last
measurement. Usually, it is the test C which fails.

This can be an issue when there is a long-lasting increase in the measured
delay, e.g. due to a routing change in the network. Unfortunately, chronyd does
not know for how long it should wait for the delay to come back to the original
values, or whether it is a permanent increase and it should start from scratch.

The test C is an adaptive filter. It can take many hours before it accepts a
measurement with the larger delay, and even much longer before it drops all
measurements with smaller delay, which determine an expected delay used by the
test. You can use the reset sources command to drop all measurements
immediately (available in chrony 4.0 and later). If this issue happens
frequently, you can effectively disable the test by setting the
maxdelaydevratio option to a very large value (e.g. 1000000), or speed up the
recovery by increasing the clock error rate with the maxclockerror directive.

3.9. Using a PPS reference clock?

A pulse-per-second (PPS) reference clock requires a non-PPS time source to
determine which second of UTC corresponds to each pulse. If it is another
reference clock specified with the lock option in the refclock directive, the
offset between the two reference clocks must be smaller than 0.4 seconds (0.2
seconds with chrony versions before 4.1) in order for the PPS reference clock
to work. With NMEA reference clocks it is common to have a larger offset. It
needs to be corrected with the offset option.

One approach to find out a good value of the offset option is to configure the
reference clocks with the noselect option and compare them to an NTP server.
For example, if the sourcestats command showed

Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
PPS0                        0   0     0     +0.000   2000.000     +0ns  4000ms
NMEA                       58  30   231    -96.494     38.406   +504ms  6080us
ntp1.example.net            7   3   200     -2.991     16.141   -107us   492us

the offset of the NMEA source would need to be increased by about 0.504
seconds. It does not have to be very accurate. As long as the offset of the
NMEA reference clock stays below the limit, the PPS reference clock should be
able to determine the seconds corresponding to the pulses and allow the samples
to be used for synchronisation.

4. Issues with chronyc

4.1. I keep getting the error 506 Cannot talk to daemon

When accessing 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 is not
necessary for localhost.

Perhaps chronyd is not running. Try using the ps command (e.g. on Linux, ps
-auxw) to see if it is running. Or try netstat -a and see if the UDP port 323
is listening. If chronyd is not running, you might 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 the UDP port
323. You need to amend the firewall configuration in this case.

4.2. I keep getting the error 501 Not authorised

This error indicates that chronyc sent the command to chronyd using a UDP
socket instead of the Unix domain socket (e.g. /var/run/chrony/chronyd.sock),
which is required for some commands. For security reasons, only the root and
chrony users are allowed to access the socket.

It is also possible that the socket does not exist. chronyd will not create the
socket if the directory has a wrong owner or permissions. In this case there
should be an error message from chronyd in the system log.

4.3. What is the reference ID reported by the tracking command?

The reference ID is a 32-bit value used in NTP to prevent synchronisation
loops.

In chrony versions before 3.0 it was printed in the quad-dotted notation, even
if the reference source did not actually have an IPv4 address. For IPv4
addresses, the reference ID is equal to the address, but for IPv6 addresses it
is the first 32 bits of the MD5 sum of the address. For reference clocks, the
reference ID is the value specified with the refid option in the refclock
directive.

Since version 3.0, the reference ID is printed as a hexadecimal number to avoid
confusion with IPv4 addresses.

If you need to get the IP address of the current reference source, use the -n
option to disable resolving of IP addresses and read the second field (printed
in parentheses) on the Reference ID line.

4.4. Is the chronyc / chronyd protocol documented anywhere?

Only by the source code. See cmdmon.c (chronyd side) and client.c (chronyc
side).

Note that this protocol is not compatible with the mode 6 or mode 7 protocol
supported by ntpd, i.e. the ntpq or ntpdc utility cannot be used to monitor
chronyd, and chronyc cannot be used to monitor ntpd.

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 initialise the system clock on boot. It normally does not 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 will not 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 initialised from it on the
next boot.

The other option is to use the rtcfile directive, which tells chronyd to
monitor the rate at which the RTC gains or loses time. When chronyd is 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 is 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. Does hwclock have to be disabled?

The hwclock program is run by default in the boot and/or shutdown scripts in
some 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 is important to disable hwclock in the shutdown procedure. If
you do not do that, it will overwrite the RTC with a new value, unknown to
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 chronyd 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

  o an RTC in your computer

  o a Linux kernel with enabled RTC support

  o an rtcfile directive in your chrony.conf file

5.4. I get Could not open /dev/rtc, Device or resource busy in my syslog file

Some other program running on the system might be using the device.

5.5. When I start chronyd, the log says Could not enable RTC interrupt :
Invalid argument (or it may say disable)

Your real-time clock hardware might not support the required ioctl requests:

  o RTC_UIE_ON

  o RTC_UIE_OFF

A possible solution could be to build the Linux kernel with support for
software emulation instead; try enabling the following configuration option
when building the Linux kernel:

  o CONFIG_RTC_INTF_DEV_UIE_EMUL

5.6. What if my computer does not have an RTC or backup battery?

In this case you can still use the -s option to set the system clock to the
last modification time of the drift file, which should correspond to the system
time when chronyd was previously stopped. The initial system time will be
increasing across reboots and applications started after chronyd will not
observe backward steps.

6. NTP-specific issues

6.1. Can chronyd be driven from broadcast/multicast NTP servers?

No, the broadcast/multicast client mode is not supported and there is currently
no plan to implement it. While this mode can simplify configuration of clients
in large networks, it is inherently less accurate and less secure (even with
authentication) than the ordinary client/server mode.

When configuring a large number of clients in a network, it is recommended to
use the pool directive with a DNS name which resolves to addresses of multiple
NTP servers. The clients will automatically replace the servers when they
become unreachable, or otherwise unsuitable for synchronisation, with new
servers from the pool.

Even with very modest hardware, an NTP server can serve time to hundreds of
thousands of clients using the ordinary client/server mode.

6.2. Can chronyd transmit broadcast NTP packets?

Yes, the 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 is not supported in chronyd). Note that this mode should generally be
avoided. See the previous question.

6.3. Can chronyd keep the system clock a fixed offset away from real time?

Yes. Starting from version 3.0, an offset can be specified by the offset option
for all time sources in the chrony.conf file.

6.4. What happens if the network connection is dropped without using chronyc's
offline command first?

chronyd will keep trying to access the sources that it thinks are online, and
it will take longer before new measurements are actually made and the clock is
corrected when the network is connected again. If the sources were set to
offline, chronyd would make new measurements immediately after issuing the
online command.

Unless the network connection lasts only few minutes (less than the maximum
polling interval), the delay is usually not a problem, and it might be
acceptable to keep all sources online all the time.

6.5. Why is an offset measured between two computers synchronised to each
another?

When two computers are synchronised to each other using the client/server or
symmetric NTP mode, there is an expectation that NTP measurements between the
two computers made on both ends show an average offset close to zero.

With chronyd that can be expected only when the interleaved mode is enabled by
the xleave option. Otherwise, chronyd will use different transmit timestamps
(e.g. daemon timestamp vs kernel timestamp) for serving time and
synchronisation of its own clock, which will cause the other computer to
measure a significant offset.

7. Operation

7.1. What clocks does chronyd use?

There are several different clocks used by chronyd:

  o System clock: software clock maintained by the kernel. It is the main clock
    used by applications running on the computer. It is synchronised by chronyd
    to its NTP clock, unless started with the -x option.

  o NTP clock: software clock (virtual) based on the system clock and internal
    to chronyd. It keeps the best estimate of the true time according to the
    configured time sources, which is served to NTP clients unless time
    smoothing is enabled by the smoothtime directive. The System time value in
    the tracking report is the current offset between the system and NTP clock.

  o Real-time clock (RTC): hardware clock keeping time even when the computer
    is turned off. It is used by the kernel to initialise the system clock on
    boot and also by chronyd to compensate for its measured drift if configured
    with the rtcfile directive and started with the -s option. The clock can be
    kept accurate only by stepping enabled by the rtcsync or rtcautotrim
    directive.

  o Reference clock: hardware clock used as a time source. It is specified by
    the refclock directive.

  o NIC clock (also known as PTP hardware clock): hardware clock timestamping
    packets received and transmitted by a network device specified by the
    hwtimestamp directive. The clock is expected to be running free. It is not
    synchronised by chronyd. Its offset is tracked relative to the NTP clock in
    order to convert the hardware timestamps.

8. Operating systems

8.1. Does chrony support Windows?

No. The 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 service.

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.

Last updated 2023-12-05 14:22:10 +0100