| // This file is part of chrony |
| // |
| // Copyright (C) Richard P. Curnow 1997-2003 |
| // Copyright (C) Miroslav Lichvar 2014-2016, 2020-2021 |
| // |
| // This program is free software; you can redistribute it and/or modify |
| // it under the terms of version 2 of the GNU General Public License as |
| // published by the Free Software Foundation. |
| // |
| // This program is distributed in the hope that it will be useful, but |
| // WITHOUT ANY WARRANTY; without even the implied warranty of |
| // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU |
| // General Public License for more details. |
| // |
| // You should have received a copy of the GNU General Public License along |
| // with this program; if not, write to the Free Software Foundation, Inc., |
| // 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. |
| |
| = Frequently Asked Questions |
| :toc: |
| :numbered: |
| |
| == `chrony` compared to other programs |
| |
| === 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 |
| https://chrony.tuxfamily.org/comparison.html[comparison page] on the `chrony` |
| website. |
| |
| == Configuration issues |
| |
| === 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 |
| https://www.pool.ntp.org/[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 |
| ---- |
| |
| === 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. |
| |
| === 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 |
| |
| * 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. |
| |
| === 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. |
| |
| === 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. |
| |
| === 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 |
| |
| * 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. |
| * delay the requests and/or responses to create a limited time offset and |
| temporarily also a limited frequency offset |
| * drop the requests or responses to prevent updates of the clock with new |
| measurements |
| * 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 |
| `authselmode` directive. |
| |
| An example of a client configuration limiting the impact of the attacks could |
| be |
| |
| ---- |
| server foo.example.net iburst nts maxdelay 0.1 |
| server bar.example.net iburst nts maxdelay 0.2 |
| server baz.example.net iburst nts maxdelay 0.05 |
| server qux.example.net iburst nts maxdelay 0.1 |
| server quux.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 |
| ---- |
| |
| === 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 foo.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 |
| ---- |
| |
| As an experimental feature added in 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 |
| ---- |
| |
| === 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. |
| |
| === 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. |
| |
| === 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 |
| ---- |
| |
| === 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. |
| |
| === 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. |
| |
| === 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. |
| |
| == Computer is not synchronising |
| |
| This is the most common problem. There are a number of reasons, see the |
| following questions. |
| |
| === 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 |
| packets 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 |
| =============================================================================== |
| ^* foo.example.net 2 6 377 34 +484us[ -157us] +/- 30ms |
| ^- bar.example.net 2 6 377 34 +33ms[ +32ms] +/- 47ms |
| ^+ baz.example.net 3 6 377 35 -1397us[-2033us] +/- 60ms |
| ---- |
| |
| === 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 |
| ---- |
| |
| === 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. |
| |
| === 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 |
| ---- |
| |
| === 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 |
| ========================================================================= |
| foo.example.net NTS 1 15 256 33m 0 0 8 100 |
| bar.example.net NTS 1 15 256 33m 0 0 8 100 |
| baz.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. |
| |
| 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. |
| |
| === 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 |
| ---- |
| |
| === 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). |
| |
| === 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. |
| |
| === 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.2 seconds 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 |
| foo.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 0.2 seconds, the PPS reference clock should be |
| able to determine the seconds corresponding to the pulses and allow the samples |
| to be used for synchronisation. |
| |
| == Issues with `chronyc` |
| |
| === 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. |
| |
| === 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. |
| |
| === 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. |
| |
| === Is the `chronyc` / `chronyd` protocol documented anywhere? |
| |
| Only by the source code. See _cmdmon.c_ (`chronyd` side) and _client.c_ |
| (`chronyc` side). |
| |
| == Real-time clock issues |
| |
| === 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. |
| |
| === 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. |
| |
| === 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 |
| |
| * an RTC in your computer |
| * a Linux kernel with enabled RTC support |
| * an `rtcfile` directive in your _chrony.conf_ file |
| |
| === 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. |
| |
| === 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: |
| |
| * `RTC_UIE_ON` |
| * `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: |
| |
| * `CONFIG_RTC_INTF_DEV_UIE_EMUL` |
| |
| === 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. |
| |
| == NTP-specific issues |
| |
| === 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. |
| |
| === 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. |
| |
| === 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. |
| |
| === 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. |
| |
| === 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. |
| |
| == Operating systems |
| |
| === 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. |
| |
| === 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. |