Provided by: chrony_3.5-6ubuntu6.2_amd64 bug

NAME

       chrony.conf - chronyd configuration file

SYNOPSIS

       chrony.conf

DESCRIPTION

       This file configures the chronyd daemon. The compiled-in location is
       /etc/chrony/chrony.conf, but other locations can be specified on the chronyd command line
       with the -f option.

       Each directive in the configuration file is placed on a separate line. The following
       sections describe each of the directives in turn. The directives can occur in any order in
       the file and they are not case-sensitive.

       The configuration directives can also be specified directly on the chronyd command line.
       In this case each argument is parsed as a new line and the configuration file is ignored.

       While the number of supported directives is large, only a few of them are typically
       needed. See the EXAMPLES section for configuration in typical operating scenarios.

       The configuration file might contain comment lines. A comment line is any line that starts
       with zero or more spaces followed by any one of the following characters: !, ;, #, %. Any
       line with this format will be ignored.

DIRECTIVES

   Time sources
       server hostname [option]...
           The server directive specifies an NTP server which can be used as a time source. The
           client-server relationship is strictly hierarchical: a client might synchronise its
           system time to that of the server, but the server’s system time will never be
           influenced by that of a client.

           The server directive is immediately followed by either the name of the server, or its
           IP address. The server directive supports the following options:

           minpoll poll
               This option specifies the minimum interval between requests sent to the server as
               a power of 2 in seconds. For example, minpoll 5 would mean that the polling
               interval should not drop below 32 seconds. The default is 6 (64 seconds), the
               minimum is -6 (1/64th of a second), and the maximum is 24 (6 months). Note that
               intervals shorter than 6 (64 seconds) should generally not be used with public
               servers on the Internet, because it might be considered abuse. A sub-second
               interval will be enabled only when the server is reachable and the round-trip
               delay is shorter than 10 milliseconds, i.e. the server should be in a local
               network.

           maxpoll poll
               This option specifies the maximum interval between requests sent to the server as
               a power of 2 in seconds. For example, maxpoll 9 indicates that the polling
               interval should stay at or below 9 (512 seconds). The default is 10 (1024
               seconds), the minimum is -6 (1/64th of a second), and the maximum is 24 (6
               months).

           iburst
               With this option, the interval between the first four requests sent to the server
               will be 2 seconds or less instead of the interval specified by the minpoll option,
               which allows chronyd to make the first update of the clock shortly after start.

           burst
               With this option, chronyd will shorten the interval between up to four requests to
               2 seconds or less when it cannot get a good measurement from the server. The
               number of requests in the burst is limited by the current polling interval to keep
               the average interval at or above the minimum interval, i.e. the current interval
               needs to be at least two times longer than the minimum interval in order to allow
               a burst with two requests.

           key ID
               The NTP protocol supports a message authentication code (MAC) to prevent computers
               having their system time upset by rogue packets being sent to them. The MAC is
               generated as a function of a password specified in the key file, which is
               specified by the keyfile directive.

               The key option specifies which key (with an ID in the range 1 through 2^32-1)
               should chronyd use to authenticate requests sent to the server and verify its
               responses. The server must have the same key for this number configured, otherwise
               no relationship between the computers will be possible.

               If the server is running ntpd and the output size of the hash function used by the
               key is longer than 160 bits (e.g. SHA256), the version option needs to be set to 4
               for compatibility.

           maxdelay delay
               chronyd uses the network round-trip delay to the server to determine how accurate
               a particular measurement is likely to be. Long round-trip delays indicate that the
               request, or the response, or both were delayed. If only one of the messages was
               delayed the measurement error is likely to be substantial.

               For small variations in the round-trip delay, chronyd uses a weighting scheme when
               processing the measurements. However, beyond a certain level of delay the
               measurements are likely to be so corrupted as to be useless. (This is particularly
               so on dial-up or other slow links, where a long delay probably indicates a highly
               asymmetric delay caused by the response waiting behind a lot of packets related to
               a download of some sort).

               If the user knows that round trip delays above a certain level should cause the
               measurement to be ignored, this level can be defined with the maxdelay option. For
               example, maxdelay 0.3 would indicate that measurements with a round-trip delay of
               0.3 seconds or more should be ignored. The default value is 3 seconds and the
               maximum value is 1000 seconds.

           maxdelayratio ratio
               This option is similar to the maxdelay option above. chronyd keeps a record of the
               minimum round-trip delay amongst the previous measurements that it has buffered.
               If a measurement has a round trip delay that is greater than the maxdelayratio
               times the minimum delay, it will be rejected.

           maxdelaydevratio ratio
               If a measurement has a ratio of the increase in the round-trip delay from the
               minimum delay amongst the previous measurements to the standard deviation of the
               previous measurements that is greater than the specified ratio, it will be
               rejected. The default is 10.0.

           mindelay delay
               This option specifies a fixed minimum round-trip delay to be used instead of the
               minimum amongst the previous measurements. This can be useful in networks with
               static configuration to improve the stability of corrections for asymmetric
               jitter, weighting of the measurements, and the maxdelayratio and maxdelaydevratio
               tests. The value should be set accurately in order to have a positive effect on
               the synchronisation.

           asymmetry ratio
               This option specifies the asymmetry of the network jitter on the path to the
               source, which is used to correct the measured offset according to the delay. The
               asymmetry can be between -0.5 and +0.5. A negative value means the delay of
               packets sent to the source is more variable than the delay of packets sent from
               the source back. By default, chronyd estimates the asymmetry automatically.

           offset offset
               This option specifies a correction (in seconds) which will be applied to offsets
               measured with this source. It’s particularly useful to compensate for a known
               asymmetry in network delay or timestamping errors. For example, if packets sent to
               the source were on average delayed by 100 microseconds more than packets sent from
               the source back, the correction would be -0.00005 (-50 microseconds). The default
               is 0.0.

           minsamples samples
               Set the minimum number of samples kept for this source. This overrides the
               minsamples directive.

           maxsamples samples
               Set the maximum number of samples kept for this source. This overrides the
               maxsamples directive.

           filter samples
               This option enables a median filter to reduce noise in NTP measurements. The
               filter will reduce the specified number of samples to a single sample. It is
               intended to be used with very short polling intervals in local networks where it
               is acceptable to generate a lot of NTP traffic.

           offline
               If the server will not be reachable when chronyd is started, the offline option
               can be specified. chronyd will not try to poll the server until it is enabled to
               do so (by using the online command in chronyc).

           auto_offline
               With this option, the server will be assumed to have gone offline when sending a
               request fails, e.g. due to a missing route to the network. This option avoids the
               need to run the offline command from chronyc when disconnecting the network link.
               (It will still be necessary to use the online command when the link has been
               established, to enable measurements to start.)

           prefer
               Prefer this source over sources without the prefer option.

           noselect
               Never select this source. This is particularly useful for monitoring.

           trust
               Assume time from this source is always true. It can be rejected as a falseticker
               in the source selection only if another source with this option does not agree
               with it.

           require
               Require that at least one of the sources specified with this option is selectable
               (i.e. recently reachable and not a falseticker) before updating the clock.
               Together with the trust option this might be useful to allow a trusted
               authenticated source to be safely combined with unauthenticated sources in order
               to improve the accuracy of the clock. They can be selected and used for
               synchronisation only if they agree with the trusted and required source.

           xleave
               This option enables an interleaved mode which allows the server or the peer to
               send transmit timestamps captured after the actual transmission (e.g. when the
               server or the peer is running chronyd with software (kernel) or hardware
               timestamping). This can significantly improve the accuracy of the measurements.

               The interleaved mode is compatible with servers that support only the basic mode,
               but peers must both support and have enabled the interleaved mode, otherwise the
               synchronisation will work only in one direction. Note that even servers that
               support the interleaved mode might respond in the basic mode as the interleaved
               mode requires the servers to keep some state for each client and the state might
               be dropped when there are too many clients (e.g. clientloglimit is too small), or
               it might be overwritten by other clients that have the same IP address (e.g.
               computers behind NAT or someone sending requests with a spoofed source address).

               The xleave option can be combined with the presend option in order to shorten the
               interval in which the server has to keep the state to be able to respond in the
               interleaved mode.

           polltarget target
               Target number of measurements to use for the regression algorithm which chronyd
               will try to maintain by adjusting the polling interval between minpoll and
               maxpoll. A higher target makes chronyd prefer shorter polling intervals. The
               default is 8 and a useful range is from 6 to 60.

           port port
               This option allows the UDP port on which the server understands NTP requests to be
               specified. For normal servers this option should not be required (the default is
               123, the standard NTP port).

           presend poll
               If the timing measurements being made by chronyd are the only network data passing
               between two computers, you might find that some measurements are badly skewed due
               to either the client or the server having to do an ARP lookup on the other party
               prior to transmitting a packet. This is more of a problem with long sampling
               intervals, which might be similar in duration to the lifetime of entries in the
               ARP caches of the machines.

               In order to avoid this problem, the presend option can be used. It takes a single
               integer argument, which is the smallest polling interval for which an extra pair
               of NTP packets will be exchanged between the client and the server prior to the
               actual measurement. For example, with the following option included in a server
               directive:

                   presend 9

               when the polling interval is 512 seconds or more, an extra NTP client packet will
               be sent to the server a short time (2 seconds) before making the actual
               measurement.

               The presend option cannot be used in the peer directive. If it is used with the
               xleave option, chronyd will send two extra packets instead of one.

           minstratum stratum
               When the synchronisation source is selected from available sources, sources with
               lower stratum are normally slightly preferred. This option can be used to increase
               stratum of the source to the specified minimum, so chronyd will avoid selecting
               that source. This is useful with low stratum sources that are known to be
               unreliable or inaccurate and which should be used only when other sources are
               unreachable.

           version version
               This option sets the NTP version of packets sent to the server. This can be useful
               when the server runs an old NTP implementation that does not respond to requests
               using a newer version. The default version depends on whether a key is specified
               by the key option and which authentication hash function the key is using. If the
               output size of the hash function is longer than 160 bits, the default version is 3
               for compatibility with older chronyd servers. Otherwise, the default version is 4.

       pool name [option]...
           The syntax of this directive is similar to that for the server directive, except that
           it is used to specify a pool of NTP servers rather than a single NTP server. The pool
           name is expected to resolve to multiple addresses which might change over time.

           All options valid in the server directive can be used in this directive too. There is
           one option specific to the pool directive: maxsources sets the maximum number of
           sources that can be used from the pool, the default value is 4.

           On start, when the pool name is resolved, chronyd will add up to 16 sources, one for
           each resolved address. When the number of sources from which at least one valid reply
           was received reaches the number specified by the maxsources option, the other sources
           will be removed. When a pool source is unreachable, marked as a falseticker, or has a
           distance larger than the limit set by the maxdistance directive, chronyd will try to
           replace the source with a newly resolved address from the pool.

           An example of the pool directive is

               pool pool.ntp.org iburst maxsources 3

       peer hostname [option]...
           The syntax of this directive is identical to that for the server directive, except
           that it specifies a symmetric association with an NTP peer instead of a client/server
           association with an NTP server. A single symmetric association allows the peers to be
           both servers and clients to each other. This is mainly useful when the NTP
           implementation of the peer (e.g. ntpd) supports ephemeral symmetric associations and
           does not need to be configured with an address of this host. chronyd does not support
           ephemeral associations.

           When a key is specified by the key option to enable authentication, both peers must
           use the same key and the same key number.

           Note that the symmetric mode is less secure than the client/server mode. A
           denial-of-service attack is possible on unauthenticated symmetric associations, i.e.
           when the peer was specified without the key option. An attacker who does not see
           network traffic between two hosts, but knows that they are peering with each other,
           can periodically send them unauthenticated packets with spoofed source addresses in
           order to disrupt their NTP state and prevent them from synchronising to each other.
           When the association is authenticated, an attacker who does see the network traffic,
           but cannot prevent the packets from reaching the other host, can still disrupt the
           state by replaying old packets. The attacker has effectively the same power as a
           man-in-the-middle attacker. A partial protection against this attack is implemented in
           chronyd, which can protect the peers if they are using the same polling interval and
           they never sent an authenticated packet with a timestamp from future, but it should
           not be relied on as it is difficult to ensure the conditions are met. If two hosts
           should be able to synchronise to each other in both directions, it is recommended to
           use two separate client/server associations (specified by the server directive on both
           hosts) instead.

       initstepslew step-threshold [hostname]...
           In normal operation, chronyd slews the time when it needs to adjust the system clock.
           For example, to correct a system clock which is 1 second slow, chronyd slightly
           increases the amount by which the system clock is advanced on each clock interrupt,
           until the error is removed. Note that at no time does time run backwards with this
           method.

           On most Unix systems it is not desirable to step the system clock, because many
           programs rely on time advancing monotonically forwards.

           When the chronyd daemon is initially started, it is possible that the system clock is
           considerably in error. Attempting to correct such an error by slewing might not be
           sensible, since it might take several hours to correct the error by this means.

           The purpose of the initstepslew directive is to allow chronyd to make a rapid
           measurement of the system clock error at boot time, and to correct the system clock by
           stepping before normal operation begins. Since this would normally be performed only
           at an appropriate point in the system boot sequence, no other software should be
           adversely affected by the step.

           If the correction required is less than a specified threshold, a slew is used instead.
           This makes it safer to restart chronyd whilst the system is in normal operation.

           The initstepslew directive takes a threshold and a list of NTP servers as arguments.
           Each of the servers is rapidly polled several times, and a majority voting mechanism
           used to find the most likely range of system clock error that is present. A step or
           slew is applied to the system clock to correct this error. chronyd then enters its
           normal operating mode.

           An example of the use of the directive is:

               initstepslew 30 foo.example.net bar.example.net

           where 2 NTP servers are used to make the measurement. The 30 indicates that if the
           system’s error is found to be 30 seconds or less, a slew will be used to correct it;
           if the error is above 30 seconds, a step will be used.

           The initstepslew directive can also be used in an isolated LAN environment, where the
           clocks are set manually. The most stable computer is chosen as the master, and the
           other computers are slaved to it. If each of the slaves is configured with the local
           directive, the master can be set up with an initstepslew directive which references
           some or all of the slaves. Then, if the master machine has to be rebooted, the slaves
           can be relied on to act analogously to a flywheel and preserve the time for a short
           period while the master completes its reboot.

           The initstepslew directive is functionally similar to a combination of the makestep
           and server directives with the iburst option. The main difference is that the
           initstepslew servers are used only before normal operation begins and that the
           foreground chronyd process waits for initstepslew to finish before exiting. This is
           useful to prevent programs started in the boot sequence after chronyd from reading the
           clock before it has been stepped.

       refclock driver parameter[:option]... [option]...
           The refclock directive specifies a hardware reference clock to be used as a time
           source. It has two mandatory parameters, a driver name and a driver-specific
           parameter. The two parameters are followed by zero or more refclock options. Some
           drivers have special options, which can be appended to the driver-specific parameter
           using the : character.

           There are four drivers included in chronyd:

           PPS
               Driver for the kernel PPS (pulse per second) API. The parameter is the path to the
               PPS device (typically /dev/pps?). As PPS refclocks do not supply full time,
               another time source (e.g. NTP server or non-PPS refclock) is needed to complete
               samples from the PPS refclock. An alternative is to enable the local directive to
               allow synchronisation with some unknown but constant offset. The driver supports
               the following option:

               clear
                   By default, the PPS refclock uses assert events (rising edge) for
                   synchronisation. With this option, it will use clear events (falling edge)
                   instead.

               Examples:

                   refclock PPS /dev/pps0 lock NMEA refid GPS
                   refclock SHM 0 offset 0.5 delay 0.2 refid NMEA noselect
                   refclock PPS /dev/pps1:clear refid GPS2

           SHM
               NTP shared memory driver. This driver uses a shared memory segment to receive
               samples from another process (e.g. gpsd). The parameter is the number of the
               shared memory segment, typically a small number like 0, 1, 2, or 3. The driver
               supports the following option:

               perm=mode
                   This option specifies the permissions of the shared memory segment created by
                   chronyd. They are specified as a numeric mode. The default value is 0600
                   (read-write access for owner only).

               Examples:

                   refclock SHM 0 poll 3 refid GPS1
                   refclock SHM 1:perm=0644 refid GPS2

           SOCK
               Unix domain socket driver. It is similar to the SHM driver, but samples are
               received from a Unix domain socket instead of shared memory and the messages have
               a different format. The parameter is the path to the socket, which chronyd creates
               on start. An advantage over the SHM driver is that SOCK does not require polling
               and it can receive PPS samples with incomplete time. The format of the messages is
               described in the refclock_sock.c file in the chrony source code.

               An application which supports the SOCK protocol is the gpsd daemon. The path where
               gpsd expects the socket to be created is described in the gpsd(8) man page. For
               example:

                   refclock SOCK /var/run/chrony.ttyS0.sock

           PHC
               PTP hardware clock (PHC) driver. The parameter is the path to the device of the
               PTP clock which should be used as a time source. If the clock is kept in TAI
               instead of UTC (e.g. it is synchronised by a PTP daemon), the current UTC-TAI
               offset needs to be specified by the offset option. Alternatively, the pps refclock
               option can be enabled to treat the PHC as a PPS refclock, using only the
               sub-second offset for synchronisation. The driver supports the following options:

               nocrossts
                   This option disables use of precise cross timestamping.

               extpps
                   This option enables a PPS mode in which the PTP clock is timestamping pulses
                   of an external PPS signal connected to the clock. The clock does not need to
                   be synchronised, but another time source is needed to complete the PPS
                   samples. Note that some PTP clocks cannot be configured to timestamp only
                   assert or clear events, and it is necessary to use the width option to filter
                   wrong PPS samples.

               pin=index
                   This option specifies the index of the pin to which is connected the PPS
                   signal. The default value is 0.

               channel=index
                   This option specifies the index of the channel for the PPS mode. The default
                   value is 0.

               clear
                   This option enables timestamping of clear events (falling edge) instead of
                   assert events (rising edge) in the PPS mode. This may not work with some
                   clocks.

               Examples:

                   refclock PHC /dev/ptp0 poll 0 dpoll -2 offset -37
                   refclock PHC /dev/ptp1:nocrossts poll 3 pps
                   refclock PHC /dev/ptp2:extpps:pin=1 width 0.2 poll 2

           The refclock directive supports the following options:

           poll poll
               Timestamps produced by refclock drivers are not used immediately, but they are
               stored and processed by a median filter in the polling interval specified by this
               option. This is defined as a power of 2 and can be negative to specify a
               sub-second interval. The default is 4 (16 seconds). A shorter interval allows
               chronyd to react faster to changes in the frequency of the system clock, but it
               might have a negative effect on its accuracy if the samples have a lot of jitter.

           dpoll dpoll
               Some drivers do not listen for external events and try to produce samples in their
               own polling interval. This is defined as a power of 2 and can be negative to
               specify a sub-second interval. The default is 0 (1 second).

           refid refid
               This option is used to specify the reference ID of the refclock, as up to four
               ASCII characters. The default reference ID is composed from the first three
               characters of the driver name and the number of the refclock. Each refclock must
               have a unique reference ID.

           lock refid
               This option can be used to lock a PPS refclock to another refclock, which is
               specified by its reference ID. In this mode received PPS samples are paired
               directly with raw samples from the specified refclock.

           rate rate
               This option sets the rate of the pulses in the PPS signal (in Hz). This option
               controls how the pulses will be completed with real time. To actually receive more
               than one pulse per second, a negative dpoll has to be specified (-3 for a 5Hz
               signal). The default is 1.

           maxlockage pulses
               This option specifies in number of pulses how old can be samples from the refclock
               specified by the lock option to be paired with the pulses. Increasing this value
               is useful when the samples are produced at a lower rate than the pulses. The
               default is 2.

           width width
               This option specifies the width of the pulses (in seconds). It is used to filter
               PPS samples when the driver provides samples for both rising and falling edges.
               Note that it reduces the maximum allowed error of the time source which completes
               the PPS samples. If the duty cycle is configurable, 50% should be preferred in
               order to maximise the allowed error.

           pps
               This options forces chronyd to treat any refclock (e.g. SHM or PHC) as a PPS
               refclock. This can be useful when the refclock provides time with a variable
               offset of a whole number of seconds (e.g. it uses TAI instead of UTC). Another
               time source is needed to complete samples from the refclock.

           offset offset
               This option can be used to compensate for a constant error. The specified offset
               (in seconds) is applied to all samples produced by the reference clock. The
               default is 0.0.

           delay delay
               This option sets the NTP delay of the source (in seconds). Half of this value is
               included in the maximum assumed error which is used in the source selection
               algorithm. Increasing the delay is useful to avoid having no majority in the
               source selection or to make it prefer other sources. The default is 1e-9 (1
               nanosecond).

           stratum stratum
               This option sets the NTP stratum of the refclock. This can be useful when the
               refclock provides time with a stratum other than 0. The default is 0.

           precision precision
               This option sets the precision of the reference clock (in seconds). The default
               value is the estimated precision of the system clock.

           maxdispersion dispersion
               Maximum allowed dispersion for filtered samples (in seconds). Samples with larger
               estimated dispersion are ignored. By default, this limit is disabled.

           filter samples
               This option sets the length of the median filter which is used to reduce the noise
               in the measurements. With each poll about 40 percent of the stored samples are
               discarded and one final sample is calculated as an average of the remaining
               samples. If the length is 4 or more, at least 4 samples have to be collected
               between polls. For lengths below 4, the filter has to be full. The default is 64.

           prefer
               Prefer this source over sources without the prefer option.

           noselect
               Never select this source. This is useful for monitoring or with sources which are
               not very accurate, but are locked with a PPS refclock.

           trust
               Assume time from this source is always true. It can be rejected as a falseticker
               in the source selection only if another source with this option does not agree
               with it.

           require
               Require that at least one of the sources specified with this option is selectable
               (i.e. recently reachable and not a falseticker) before updating the clock.
               Together with the trust option this can be useful to allow a trusted, but not very
               precise, reference clock to be safely combined with unauthenticated NTP sources in
               order to improve the accuracy of the clock. They can be selected and used for
               synchronisation only if they agree with the trusted and required source.

           tai
               This option indicates that the reference clock keeps time in TAI instead of UTC
               and that chronyd should correct its offset by the current TAI-UTC offset. The
               leapsectz directive must be used with this option and the database must be kept up
               to date in order for this correction to work as expected. This option does not
               make sense with PPS refclocks.

           minsamples samples
               Set the minimum number of samples kept for this source. This overrides the
               minsamples directive.

           maxsamples samples
               Set the maximum number of samples kept for this source. This overrides the
               maxsamples directive.

       manual
           The manual directive enables support at run-time for the settime command in chronyc.
           If no manual directive is included, any attempt to use the settime command in chronyc
           will be met with an error message.

           Note that the settime command can be enabled at run-time using the manual command in
           chronyc. (The idea of the two commands is that the manual command controls the manual
           clock driver’s behaviour, whereas the settime command allows samples of manually
           entered time to be provided.)

       acquisitionport port
           By default, chronyd uses a separate client socket for each configured server and their
           source port is chosen arbitrarily by the operating system. However, you can use the
           acquisitionport directive to explicitly specify a port and use only one socket (per
           IPv4 or IPv6 address family) for all configured servers. This can be useful for
           getting through some firewalls. If set to 0, the source port of the socket will be
           chosen arbitrarily.

           It can be set to the same port as is used by the NTP server (which can be configured
           with the port directive) to use only one socket for all NTP packets.

           An example of the acquisitionport directive is:

               acquisitionport 1123

           This would change the source port used for client requests to UDP port 1123. You could
           then persuade the firewall administrator to open that port.

       bindacqaddress address
           The bindacqaddress directive sets the network interface to which chronyd will bind its
           NTP client sockets. The syntax is similar to the bindaddress and bindcmdaddress
           directives.

           For each of the IPv4 and IPv6 protocols, only one bindacqaddress directive can be
           specified.

       dumpdir directory
           To compute the rate of gain or loss of time, chronyd has to store a measurement
           history for each of the time sources it uses.

           All supported systems, with the exception of macOS 10.12 and earlier, have operating
           system support for setting the rate of gain or loss to compensate for known errors.
           (On macOS 10.12 and earlier, chronyd must simulate such a capability by periodically
           slewing the system clock forwards or backwards by a suitable amount to compensate for
           the error built up since the previous slew.)

           For such systems, it is possible to save the measurement history across restarts of
           chronyd (assuming no changes are made to the system clock behaviour whilst it is not
           running). The dumpdir directive defines the directory where the measurement histories
           are saved when chronyd exits, or the dump command in chronyc is issued.

           An example of the directive is:

               dumpdir /run/chrony

           A source whose IP address is 1.2.3.4 would have its measurement history saved in the
           file /run/chrony/1.2.3.4.dat. History of reference clocks is saved to files named by
           their reference ID in form of refid:XXXXXXXX.dat.

       maxsamples samples
           The maxsamples directive sets the default maximum number of samples that chronyd
           should keep for each source. This setting can be overridden for individual sources in
           the server and refclock directives. The default value is 0, which disables the
           configurable limit. The useful range is 4 to 64.

       minsamples samples
           The minsamples directive sets the default minimum number of samples that chronyd
           should keep for each source. This setting can be overridden for individual sources in
           the server and refclock directives. The default value is 6. The useful range is 4 to
           64.

           Forcing chronyd to keep more samples than it would normally keep reduces noise in the
           estimated frequency and offset, but slows down the response to changes in the
           frequency and offset of the clock. The offsets in the tracking and sourcestats reports
           (and the tracking.log and statistics.log files) may be smaller than the actual
           offsets.

   Source selection
       combinelimit limit
           When chronyd has multiple sources available for synchronisation, it has to select one
           source as the synchronisation source. The measured offsets and frequencies of the
           system clock relative to the other sources, however, can be combined with the selected
           source to improve the accuracy of the system clock.

           The combinelimit directive limits which sources are included in the combining
           algorithm. Their synchronisation distance has to be shorter than the distance of the
           selected source multiplied by the value of the limit. Also, their measured frequencies
           have to be close to the frequency of the selected source. If the selected source was
           specified with the prefer option, it can be combined only with other sources specified
           with this option.

           By default, the limit is 3. Setting the limit to 0 effectively disables the source
           combining algorithm and only the selected source will be used to control the system
           clock.

       maxdistance distance
           The maxdistance directive sets the maximum allowed root distance of the sources to not
           be rejected by the source selection algorithm. The distance includes the accumulated
           dispersion, which might be large when the source is no longer synchronised, and half
           of the total round-trip delay to the primary source.

           By default, the maximum root distance is 3 seconds.

           Setting maxdistance to a larger value can be useful to allow synchronisation with a
           server that only has a very infrequent connection to its sources and can accumulate a
           large dispersion between updates of its clock.

       maxjitter jitter
           The maxjitter directive sets the maximum allowed jitter of the sources to not be
           rejected by the source selection algorithm. This prevents synchronisation with sources
           that have a small root distance, but their time is too variable.

           By default, the maximum jitter is 1 second.

       minsources sources
           The minsources directive sets the minimum number of sources that need to be considered
           as selectable in the source selection algorithm before the local clock is updated. The
           default value is 1.

           Setting this option to a larger number can be used to improve the reliability. More
           sources will have to agree with each other and the clock will not be updated when only
           one source (which could be serving incorrect time) is reachable.

       reselectdist distance
           When chronyd selects a synchronisation source from available sources, it will prefer
           the one with the shortest synchronisation distance. However, to avoid frequent
           reselecting when there are sources with similar distance, a fixed distance is added to
           the distance for sources that are currently not selected. This can be set with the
           reselectdist directive. By default, the distance is 100 microseconds.

       stratumweight distance
           The stratumweight directive sets how much distance should be added per stratum to the
           synchronisation distance when chronyd selects the synchronisation source from
           available sources.

           By default, the weight is 0.001 seconds. This means that the stratum of the sources in
           the selection process matters only when the differences between the distances are in
           milliseconds.

   System clock
       corrtimeratio ratio
           When chronyd is slewing the system clock to correct an offset, the rate at which it is
           slewing adds to the frequency error of the clock. On all supported systems, with the
           exception of macOS 12 and earlier, this rate can be controlled.

           The corrtimeratio directive sets the ratio between the duration in which the clock is
           slewed for an average correction according to the source history and the interval in
           which the corrections are done (usually the NTP polling interval). Corrections larger
           than the average take less time and smaller corrections take more time, the amount of
           the correction and the correction time are inversely proportional.

           Increasing corrtimeratio improves the overall frequency error of the system clock, but
           increases the overall time error as the corrections take longer.

           By default, the ratio is set to 3, the time accuracy of the clock is preferred over
           its frequency accuracy.

           The maximum allowed slew rate can be set by the maxslewrate directive. The current
           remaining correction is shown in the tracking report as the System time value.

       driftfile file
           One of the main activities of the chronyd program is to work out the rate at which the
           system clock gains or loses time relative to real time.

           Whenever chronyd computes a new value of the gain or loss rate, it is desirable to
           record it somewhere. This allows chronyd to begin compensating the system clock at
           that rate whenever it is restarted, even before it has had a chance to obtain an
           equally good estimate of the rate during the new run. (This process can take many
           minutes, at least.)

           The driftfile directive allows a file to be specified into which chronyd can store the
           rate information. Two parameters are recorded in the file. The first is the rate at
           which the system clock gains or loses time, expressed in parts per million, with gains
           positive. Therefore, a value of 100.0 indicates that when the system clock has
           advanced by a second, it has gained 100 microseconds in reality (so the true time has
           only advanced by 999900 microseconds). The second is an estimate of the error bound
           around the first value in which the true rate actually lies.

           An example of the driftfile directive is:

               driftfile /var/lib/chrony/drift

       fallbackdrift min-interval max-interval
           Fallback drifts are long-term averages of the system clock drift calculated over
           exponentially increasing intervals. They are used to avoid quickly drifting away from
           true time when the clock was not updated for a longer period of time and there was a
           short-term deviation in the drift before the updates stopped.

           The directive specifies the minimum and maximum interval since the last clock update
           to switch between fallback drifts. They are defined as a power of 2 (in seconds). The
           syntax is as follows:

               fallbackdrift 16 19

           In this example, the minimum interval is 16 (18 hours) and the maximum interval is 19
           (6 days). The system clock frequency will be set to the first fallback 18 hours after
           last clock update, to the second after 36 hours, and so on. This might be a good
           setting to cover frequency changes due to daily and weekly temperature fluctuations.
           When the frequency is set to a fallback, the state of the clock will change to ‘Not
           synchronised’.

           By default (or if the specified maximum or minimum is 0), no fallbacks are used and
           the clock frequency changes only with new measurements from NTP sources, reference
           clocks, or manual input.

       leapsecmode mode
           A leap second is an adjustment that is occasionally applied to UTC to keep it close to
           the mean solar time. When a leap second is inserted, the last day of June or December
           has an extra second 23:59:60.

           For computer clocks that is a problem. The Unix time is defined as number of seconds
           since 00:00:00 UTC on 1 January 1970 without leap seconds. The system clock cannot
           have time 23:59:60, every minute has 60 seconds and every day has 86400 seconds by
           definition. The inserted leap second is skipped and the clock is suddenly ahead of UTC
           by one second. The leapsecmode directive selects how that error is corrected. There
           are four options:

           system
               When inserting a leap second, the kernel steps the system clock backwards by one
               second when the clock gets to 00:00:00 UTC. When deleting a leap second, it steps
               forward by one second when the clock gets to 23:59:59 UTC. This is the default
               mode when the system driver supports leap seconds (i.e. all supported systems with
               the exception of macOS 12 and earlier).

           step
               This is similar to the system mode, except the clock is stepped by chronyd instead
               of the kernel. It can be useful to avoid bugs in the kernel code that would be
               executed in the system mode. This is the default mode when the system driver does
               not support leap seconds.

           slew
               The clock is corrected by slewing started at 00:00:00 UTC when a leap second is
               inserted or 23:59:59 UTC when a leap second is deleted. This might be preferred
               over the system and step modes when applications running on the system are
               sensitive to jumps in the system time and it is acceptable that the clock will be
               off for a longer time. On Linux with the default maxslewrate value the correction
               takes 12 seconds.

           ignore
               No correction is applied to the clock for the leap second. The clock will be
               corrected later in normal operation when new measurements are made and the
               estimated offset includes the one second error.

           When serving time to NTP clients that cannot be configured to correct their clocks for
           a leap second by slewing, or to clients that would correct at slightly different rates
           when it is necessary to keep them close together, the slew mode can be combined with
           the smoothtime directive to enable a server leap smear.

           When smearing a leap second, the leap status is suppressed on the server and the
           served time is corrected slowly be slewing instead of stepping. The clients do not
           need any special configuration as they do not know there is any leap second and they
           follow the server time which eventually brings them back to UTC. Care must be taken to
           ensure they use only NTP servers which smear the leap second in exactly the same way
           for synchronisation.

           This feature must be used carefully, because the server is intentionally not serving
           its best estimate of the true time.

           A recommended configuration to enable a server leap smear is:

               leapsecmode slew
               maxslewrate 1000
               smoothtime 400 0.001 leaponly

           The first directive is necessary to disable the clock step which would reset the
           smoothing process. The second directive limits the slewing rate of the local clock to
           1000 ppm, which improves the stability of the smoothing process when the local
           correction starts and ends. The third directive enables the server time smoothing
           process. It will start when the clock gets to 00:00:00 UTC and it will take 17 hours
           34 minutes to finish. The frequency offset will be changing by 0.001 ppm per second
           and will reach a maximum of 31.623 ppm. The leaponly option makes the duration of the
           leap smear constant and allows the clients to safely synchronise with multiple
           identically configured leap smearing servers.

       leapsectz timezone
           This directive specifies a timezone in the system tz database which chronyd can use to
           determine when will the next leap second occur and what is the current offset between
           TAI and UTC. It will periodically check if 23:59:59 and 23:59:60 are valid times in
           the timezone. This typically works with the right/UTC timezone.

           When a leap second is announced, the timezone needs to be updated at least 12 hours
           before the leap second. It is not necessary to restart chronyd.

           This directive is useful with reference clocks and other time sources which do not
           announce leap seconds, or announce them too late for an NTP server to forward them to
           its own clients. Clients of leap smearing servers must not use this directive.

           It is also useful when the system clock is required to have correct TAI-UTC offset.
           Note that the offset is set only when leap seconds are handled by the kernel, i.e.
           leapsecmode is set to system.

           The specified timezone is not used as an exclusive source of information about leap
           seconds. If a majority of time sources announce on the last day of June or December
           that a leap second should be inserted or deleted, it will be accepted even if it is
           not included in the timezone.

           An example of the directive is:

               leapsectz right/UTC

           The following shell command verifies that the timezone contains leap seconds and can
           be used with this directive:

               $ TZ=right/UTC date -d 'Dec 31 2008 23:59:60'
               Wed Dec 31 23:59:60 UTC 2008

       makestep threshold limit
           Normally chronyd will cause the system to gradually correct any time offset, by
           slowing down or speeding up the clock as required. In certain situations, the system
           clock might be so far adrift that this slewing process would take a very long time to
           correct the system clock.

           This directive forces chronyd to step the system clock if the adjustment is larger
           than a threshold value, but only if there were no more clock updates since chronyd was
           started than a specified limit (a negative value can be used to disable the limit).

           This is particularly useful when using reference clocks, because the initstepslew
           directive works only with NTP sources.

           An example of the use of this directive is:

               makestep 0.1 3

           This would step the system clock if the adjustment is larger than 0.1 seconds, but
           only in the first three clock updates.

       maxchange offset start ignore
           This directive sets the maximum allowed offset corrected on a clock update. The check
           is performed only after the specified number of updates to allow a large initial
           adjustment of the system clock. When an offset larger than the specified maximum
           occurs, it will be ignored for the specified number of times and then chronyd will
           give up and exit (a negative value can be used to never exit). In both cases a message
           is sent to syslog.

           An example of the use of this directive is:

               maxchange 1000 1 2

           After the first clock update, chronyd will check the offset on every clock update, it
           will ignore two adjustments larger than 1000 seconds and exit on another one.

       maxclockerror error-in-ppm
           The maxclockerror directive sets the maximum assumed frequency error that the system
           clock can gain on its own between clock updates. It describes the stability of the
           clock.

           By default, the maximum error is 1 ppm.

           Typical values for error-in-ppm might be 10 for a low quality clock and 0.1 for a high
           quality clock using a temperature compensated crystal oscillator.

       maxdrift drift-in-ppm
           This directive specifies the maximum assumed drift (frequency error) of the system
           clock. It limits the frequency adjustment that chronyd is allowed to use to correct
           the measured drift. It is an additional limit to the maximum adjustment that can be
           set by the system driver (100000 ppm on Linux, 500 ppm on FreeBSD, NetBSD, and macOS
           10.13+, 32500 ppm on Solaris).

           By default, the maximum assumed drift is 500000 ppm, i.e. the adjustment is limited by
           the system driver rather than this directive.

       maxupdateskew skew-in-ppm
           One of chronyd’s tasks is to work out how fast or slow the computer’s clock runs
           relative to its reference sources. In addition, it computes an estimate of the error
           bounds around the estimated value.

           If the range of error is too large, it probably indicates that the measurements have
           not settled down yet, and that the estimated gain or loss rate is not very reliable.

           The maxupdateskew directive sets the threshold for determining whether an estimate
           might be so unreliable that it should not be used. By default, the threshold is 1000
           ppm.

           Typical values for skew-in-ppm might be 100 for a dial-up connection to servers over a
           phone line, and 5 or 10 for a computer on a LAN.

           It should be noted that this is not the only means of protection against using
           unreliable estimates. At all times, chronyd keeps track of both the estimated gain or
           loss rate, and the error bound on the estimate. When a new estimate is generated
           following another measurement from one of the sources, a weighted combination
           algorithm is used to update the master estimate. So if chronyd has an existing
           highly-reliable master estimate and a new estimate is generated which has large error
           bounds, the existing master estimate will dominate in the new master estimate.

       maxslewrate rate-in-ppm
           The maxslewrate directive sets the maximum rate at which chronyd is allowed to slew
           the time. It limits the slew rate controlled by the correction time ratio (which can
           be set by the corrtimeratio directive) and is effective only on systems where chronyd
           is able to control the rate (i.e. all supported systems with the exception of macOS 12
           or earlier).

           For each system there is a maximum frequency offset of the clock that can be set by
           the driver. On Linux it is 100000 ppm, on FreeBSD, NetBSD and macOS 10.13+ it is 5000
           ppm, and on Solaris it is 32500 ppm. Also, due to a kernel limitation, setting
           maxslewrate on FreeBSD, NetBSD, macOS 10.13+ to a value between 500 ppm and 5000 ppm
           will effectively set it to 500 ppm.

           In early beta releases of macOS 13 this capability is disabled because of a system
           kernel bug. When the kernel bug is fixed, chronyd will detect this and re-enable the
           capability (see above limitations) with no recompilation required.

           By default, the maximum slew rate is set to 83333.333 ppm (one twelfth).

       tempcomp file interval T0 k0 k1 k2, tempcomp file interval points-file
           Normally, changes in the rate of drift of the system clock are caused mainly by
           changes in the temperature of the crystal oscillator on the motherboard.

           If there are temperature measurements available from a sensor close to the oscillator,
           the tempcomp directive can be used to compensate for the changes in the temperature
           and improve the stability and accuracy of the clock.

           The result depends on many factors, including the resolution of the sensor, the amount
           of noise in the measurements, the polling interval of the time source, the
           compensation update interval, how well the compensation is specified, and how close
           the sensor is to the oscillator. When it is working well, the frequency reported in
           the tracking.log file is more stable and the maximum reached offset is smaller.

           There are two forms of the directive. The first one has six parameters: a path to the
           file containing the current temperature from the sensor (in text format), the
           compensation update interval (in seconds), and temperature coefficients T0, k0, k1,
           k2.

           The frequency compensation is calculated (in ppm) as

               k0 + (T - T0) * k1 + (T - T0)^2 * k2

           The result has to be between -10 ppm and 10 ppm, otherwise the measurement is
           considered invalid and will be ignored. The k0 coefficient can be adjusted to keep the
           compensation in that range.

           An example of the use is:

               tempcomp /sys/class/hwmon/hwmon0/temp2_input 30 26000 0.0 0.000183 0.0

           The measured temperature will be read from the file in the Linux sysfs filesystem
           every 30 seconds. When the temperature is 26000 (26 degrees Celsius), the frequency
           correction will be zero. When it is 27000 (27 degrees Celsius), the clock will be set
           to run faster by 0.183 ppm, etc.

           The second form has three parameters: the path to the sensor file, the update
           interval, and a path to a file containing a list of (temperature, compensation)
           points, from which the compensation is linearly interpolated or extrapolated.

           An example is:

               tempcomp /sys/class/hwmon/hwmon0/temp2_input 30 /etc/chrony.tempcomp

           where the /etc/chrony.tempcomp file could have

               20000 1.0
               21000 0.64
               22000 0.36
               23000 0.16
               24000 0.04
               25000 0.0
               26000 0.04
               27000 0.16
               28000 0.36
               29000 0.64
               30000 1.0

           Valid measurements with corresponding compensations are logged to the tempcomp.log
           file if enabled by the log tempcomp directive.

   NTP server
       allow [all] [subnet]
           The allow directive is used to designate a particular subnet from which NTP clients
           are allowed to access the computer as an NTP server.

           The default is that no clients are allowed access, i.e. chronyd operates purely as an
           NTP client. If the allow directive is used, chronyd will be both a client of its
           servers, and a server to other clients.

           Examples of the use of the directive are as follows:

               allow 1.2.3.4
               allow 1.2
               allow 3.4.5
               allow 6.7.8/22
               allow 6.7.8.9/22
               allow 2001:db8::/32
               allow 0/0
               allow ::/0
               allow

           The first directive allows a node with IPv4 address 1.2.3.4 to be an NTP client of
           this computer. The second directive allows any node with an IPv4 address of the form
           1.2.x.y (with x and y arbitrary) to be an NTP client of this computer. Likewise, the
           third directive allows any node with an IPv4 address of the form 3.4.5.x to have
           client NTP access. The fourth and fifth forms allow access from any node with an IPv4
           address of the form 6.7.8.x, 6.7.9.x, 6.7.10.x or 6.7.11.x (with x arbitrary), i.e.
           the value 22 is the number of bits defining the specified subnet. In the fifth form,
           the final byte is ignored. The sixth form is used for IPv6 addresses. The seventh and
           eighth forms allow access by any IPv4 and IPv6 node respectively. The ninth forms
           allows access by any node (IPv4 or IPv6).

           A second form of the directive, allow all, has a greater effect, depending on the
           ordering of directives in the configuration file. To illustrate the effect, consider
           the two examples:

               allow 1.2.3.4
               deny 1.2.3
               allow 1.2

           and

               allow 1.2.3.4
               deny 1.2.3
               allow all 1.2

           In the first example, the effect is the same regardless of what order the three
           directives are given in. So the 1.2.x.y subnet is allowed access, except for the
           1.2.3.x subnet, which is denied access, however the host 1.2.3.4 is allowed access.

           In the second example, the allow all 1.2 directives overrides the effect of any
           previous directive relating to a subnet within the specified subnet. Within a
           configuration file this capability is probably rather moot; however, it is of greater
           use for reconfiguration at run-time via chronyc with the allow all command.

           The directive allows a hostname to be specified instead of an IP address, but the name
           must be resolvable when chronyd is started (i.e. chronyd needs to be started when the
           network is already up and DNS is working).

           Note, if the initstepslew directive is used in the configuration file, each of the
           computers listed in that directive must allow client access by this computer for it to
           work.

       deny [all] [subnet]
           This is similar to the allow directive, except that it denies NTP client access to a
           particular subnet or host, rather than allowing it.

           The syntax is identical.

           There is also a deny all directive with similar behaviour to the allow all directive.

       bindaddress address
           The bindaddress directive binds the socket on which chronyd listens for NTP requests
           to a local address of the computer. On systems other than Linux, the address of the
           computer needs to be already configured when chronyd is started.

           An example of the use of the directive is:

               bindaddress 192.168.1.1

           Currently, for each of the IPv4 and IPv6 protocols, only one bindaddress directive can
           be specified. Therefore, it is not useful on computers which should serve NTP on
           multiple network interfaces.

       broadcast interval address [port]
           The broadcast directive is used to declare a broadcast address to which chronyd should
           send packets in the NTP broadcast mode (i.e. make chronyd act as a broadcast server).
           Broadcast clients on that subnet will be able to synchronise.

           The syntax is as follows:

               broadcast 30 192.168.1.255
               broadcast 60 192.168.2.255 12123
               broadcast 60 ff02::101

           In the first example, the destination port defaults to UDP port 123 (the normal NTP
           port). In the second example, the destination port is specified as 12123. The first
           parameter in each case (30 or 60 respectively) is the interval in seconds between
           broadcast packets being sent. The second parameter in each case is the broadcast
           address to send the packet to. This should correspond to the broadcast address of one
           of the network interfaces on the computer where chronyd is running.

           You can have more than 1 broadcast directive if you have more than 1 network interface
           onto which you want to send NTP broadcast packets.

           chronyd itself cannot act as a broadcast client; it must always be configured as a
           point-to-point client by defining specific NTP servers and peers. This broadcast
           server feature is intended for providing a time source to other NTP implementations.

           If ntpd is used as the broadcast client, it will try to measure the round-trip delay
           between the server and client with normal client mode packets. Thus, the broadcast
           subnet should also be the subject of an allow directive.

       clientloglimit limit
           This directive specifies the maximum amount of memory that chronyd is allowed to
           allocate for logging of client accesses and the state that chronyd as an NTP server
           needs to support the interleaved mode for its clients. The default limit is 524288
           bytes, which is sufficient for monitoring about four thousand clients at the same
           time.

           In older chrony versions if the limit was set to 0, the memory allocation was
           unlimited.

           An example of the use of this directive is:

               clientloglimit 1048576

       noclientlog
           This directive, which takes no arguments, specifies that client accesses are not to be
           logged. Normally they are logged, allowing statistics to be reported using the clients
           command in chronyc. This option also effectively disables server support for the NTP
           interleaved mode.

       local [option]...
           The local directive enables a local reference mode, which allows chronyd operating as
           an NTP server to appear synchronised to real time (from the viewpoint of clients
           polling it), even when it was never synchronised or the last update of the clock
           happened a long time ago.

           This directive is normally used in an isolated network, where computers are required
           to be synchronised to one another, but not necessarily to real time. The server can be
           kept vaguely in line with real time by manual input.

           The local directive has the following options:

           stratum stratum
               This option sets the stratum of the server which will be reported to clients when
               the local reference is active. The specified value is in the range 1 through 15,
               and the default value is 10. It should be larger than the maximum expected stratum
               in the network when external NTP servers are accessible.

               Stratum 1 indicates a computer that has a true real-time reference directly
               connected to it (e.g. GPS, atomic clock, etc.), such computers are expected to be
               very close to real time. Stratum 2 computers are those which have a stratum 1
               server; stratum 3 computers have a stratum 2 server and so on. A value of 10
               indicates that the clock is so many hops away from a reference clock that its time
               is fairly unreliable.

           distance distance
               This option sets the threshold for the root distance which will activate the local
               reference. If chronyd was synchronised to some source, the local reference will
               not be activated until its root distance reaches the specified value (the rate at
               which the distance is increasing depends on how well the clock was tracking the
               source). The default value is 1 second.

               The current root distance can be calculated from root delay and root dispersion
               (reported by the tracking command in chronyc) as:

                   distance = delay / 2 + dispersion

           orphan
               This option enables a special ‘orphan’ mode, where sources with stratum equal to
               the local stratum are assumed to not serve real time. They are ignored unless no
               other source is selectable and their reference IDs are smaller than the local
               reference ID.

               This allows multiple servers in the network to use the same local configuration
               and to be synchronised to one another, without confusing clients that poll more
               than one server. Each server needs to be configured to poll all other servers with
               the local directive. This ensures only the server with the smallest reference ID
               has the local reference active and others are synchronised to it. When that server
               fails, another will take over.

               The orphan mode is compatible with the ntpd’s orphan mode (enabled by the tos
               orphan command).

           An example of the directive is:

               local stratum 10 orphan

       ntpsigndsocket directory
           This directive specifies the location of the Samba ntp_signd socket when it is running
           as a Domain Controller (DC). If chronyd is compiled with this feature, responses to
           MS-SNTP clients will be signed by the smbd daemon.

           Note that MS-SNTP requests are not authenticated and any client that is allowed to
           access the server by the allow directive, or the allow command in chronyc, can get an
           MS-SNTP response signed with a trust account’s password and try to crack the password
           in a brute-force attack. Access to the server should be carefully controlled.

           An example of the directive is:

               ntpsigndsocket /var/lib/samba/ntp_signd

       port port
           This option allows you to configure the port on which chronyd will listen for NTP
           requests. The port will be open only when an address is allowed by the allow directive
           or the allow command in chronyc, an NTP peer is configured, or the broadcast server
           mode is enabled.

           The default value is 123, the standard NTP port. If set to 0, chronyd will never open
           the server port and will operate strictly in a client-only mode. The source port used
           in NTP client requests can be set by the acquisitionport directive.

       ratelimit [option]...
           This directive enables response rate limiting for NTP packets. Its purpose is to
           reduce network traffic with misconfigured or broken NTP clients that are polling the
           server too frequently. The limits are applied to individual IP addresses. If multiple
           clients share one IP address (e.g. multiple hosts behind NAT), the sum of their
           traffic will be limited. If a client that increases its polling rate when it does not
           receive a reply is detected, its rate limiting will be temporarily suspended to avoid
           increasing the overall amount of traffic. The maximum number of IP addresses which can
           be monitored at the same time depends on the memory limit set by the clientloglimit
           directive.

           The ratelimit directive supports a number of options (which can be defined in any
           order):

           interval
               This option sets the minimum interval between responses. It is defined as a power
               of 2 in seconds. The default value is 3 (8 seconds). The minimum value is -19
               (524288 packets per second) and the maximum value is 12 (one packet per 4096
               seconds). Note that with values below -4 the rate limiting is coarse (responses
               are allowed in bursts, even if the interval between them is shorter than the
               specified interval).

           burst
               This option sets the maximum number of responses that can be sent in a burst,
               temporarily exceeding the limit specified by the interval option. This is useful
               for clients that make rapid measurements on start (e.g. chronyd with the iburst
               option). The default value is 8. The minimum value is 1 and the maximum value is
               255.

           leak
               This option sets the rate at which responses are randomly allowed even if the
               limits specified by the interval and burst options are exceeded. This is necessary
               to prevent an attacker who is sending requests with a spoofed source address from
               completely blocking responses to that address. The leak rate is defined as a power
               of 1/2 and it is 2 by default, i.e. on average at least every fourth request has a
               response. The minimum value is 1 and the maximum value is 4.

           An example use of the directive is:

               ratelimit interval 1 burst 16

           This would reduce the response rate for IP addresses sending packets on average more
           than once per 2 seconds, or sending packets in bursts of more than 16 packets, by up
           to 75% (with default leak of 2).

       smoothtime max-freq max-wander [leaponly]
           The smoothtime directive can be used to enable smoothing of the time that chronyd
           serves to its clients to make it easier for them to track it and keep their clocks
           close together even when large offset or frequency corrections are applied to the
           server’s clock, for example after being offline for a longer time.

           BE WARNED: The server is intentionally not serving its best estimate of the true time.
           If a large offset has been accumulated, it can take a very long time to smooth it out.
           This directive should be used only when the clients are not configured to also poll
           another NTP server, because they could reject this server as a falseticker or fail to
           select a source completely.

           The smoothing process is implemented with a quadratic spline function with two or
           three pieces. It is independent from any slewing applied to the local system clock,
           but the accumulated offset and frequency will be reset when the clock is corrected by
           stepping, e.g. by the makestep directive or the makestep command in chronyc. The
           process can be reset without stepping the clock by the smoothtime reset command.

           The first two arguments of the directive are the maximum frequency offset of the
           smoothed time to the tracked NTP time (in ppm) and the maximum rate at which the
           frequency offset is allowed to change (in ppm per second). leaponly is an optional
           third argument which enables a mode where only leap seconds are smoothed out and
           normal offset and frequency changes are ignored. The leaponly option is useful in a
           combination with the leapsecmode slew directive to allow the clients to use multiple
           time smoothing servers safely.

           The smoothing process is activated automatically when 1/10000 of the estimated skew of
           the local clock falls below the maximum rate of frequency change. It can be also
           activated manually by the smoothtime activate command, which is particularly useful
           when the clock is synchronised only with manual input and the skew is always larger
           than the threshold. The smoothing command can be used to monitor the process.

           An example suitable for clients using ntpd and 1024 second polling interval could be:

               smoothtime 400 0.001

           An example suitable for clients using chronyd on Linux could be:

               smoothtime 50000 0.01

   Command and monitoring access
       bindcmdaddress address
           The bindcmdaddress directive allows you to specify an IP address of an interface on
           which chronyd will listen for monitoring command packets (issued by chronyc). On
           systems other than Linux, the address of the interface needs to be already configured
           when chronyd is started.

           This directive can also change the path of the Unix domain command socket, which is
           used by chronyc to send configuration commands. The socket must be in a directory that
           is accessible only by the root or chrony user. The directory will be created on start
           if it does not exist. The compiled-in default path of the socket is
           /run/chrony/chronyd.sock. The socket can be disabled by setting the path to /.

           By default, chronyd binds to the loopback interface (with addresses 127.0.0.1 and
           ::1). This blocks all access except from localhost. To listen for command packets on
           all interfaces, you can add the lines:

               bindcmdaddress 0.0.0.0
               bindcmdaddress ::

           to the configuration file.

           For each of the IPv4, IPv6, and Unix domain protocols, only one bindcmdaddress
           directive can be specified.

           An example that sets the path of the Unix domain command socket is:

               bindcmdaddress /var/run/chrony/chronyd.sock

       cmdallow [all] [subnet]
           This is similar to the allow directive, except that it allows monitoring access
           (rather than NTP client access) to a particular subnet or host. (By ‘monitoring
           access’ is meant that chronyc can be run on those hosts and retrieve monitoring data
           from chronyd on this computer.)

           The syntax is identical to the allow directive.

           There is also a cmdallow all directive with similar behaviour to the allow all
           directive (but applying to monitoring access in this case, of course).

           Note that chronyd has to be configured with the bindcmdaddress directive to not listen
           only on the loopback interface to actually allow remote access.

       cmddeny [all] [subnet]
           This is similar to the cmdallow directive, except that it denies monitoring access to
           a particular subnet or host, rather than allowing it.

           The syntax is identical.

           There is also a cmddeny all directive with similar behaviour to the cmdallow all
           directive.

       cmdport port
           The cmdport directive allows the port that is used for run-time monitoring (via the
           chronyc program) to be altered from its default (323). If set to 0, chronyd will not
           open the port, this is useful to disable chronyc access from the Internet. (It does
           not disable the Unix domain command socket.)

           An example shows the syntax:

               cmdport 257

           This would make chronyd use UDP 257 as its command port. (chronyc would need to be run
           with the -p 257 switch to inter-operate correctly.)

       cmdratelimit [option]...
           This directive enables response rate limiting for command packets. It is similar to
           the ratelimit directive, except responses to localhost are never limited and the
           default interval is -4 (16 packets per second).

           An example of the use of the directive is:

               cmdratelimit interval 2

   Real-time clock (RTC)
       hwclockfile file
           The hwclockfile directive sets the location of the adjtime file which is used by the
           hwclock program on Linux. chronyd parses the file to find out if the RTC keeps local
           time or UTC. It overrides the rtconutc directive.

           The compiled-in default value is '/etc/adjtime'.

           An example of the directive is:

               hwclockfile /etc/adjtime

       rtcautotrim threshold
           The rtcautotrim directive is used to keep the RTC close to the system clock
           automatically. When the system clock is synchronised and the estimated error between
           the two clocks is larger than the specified threshold, chronyd will trim the RTC as if
           the trimrtc command in chronyc was issued.

           This directive is effective only with the rtcfile directive.

           An example of the use of this directive is:

               rtcautotrim 30

           This would set the threshold error to 30 seconds.

       rtcdevice device
           The rtcdevice directive sets the path to the device file for accessing the RTC. The
           default path is /dev/rtc.

       rtcfile file
           The rtcfile directive defines the name of the file in which chronyd can save
           parameters associated with tracking the accuracy of the RTC.

           An example of the directive is:

               rtcfile /var/lib/chrony/rtc

           chronyd saves information in this file when it exits and when the writertc command is
           issued in chronyc. The information saved is the RTC’s error at some epoch, that epoch
           (in seconds since January 1 1970), and the rate at which the RTC gains or loses time.

           So far, the support for real-time clocks is limited; their code is even more
           system-specific than the rest of the software. You can only use the RTC facilities
           (the rtcfile directive and the -s command-line option to chronyd) if the following
           three conditions apply:

            1. You are running Linux.

            2. The kernel is compiled with extended real-time clock support (i.e. the /dev/rtc
               device is capable of doing useful things).

            3. You do not have other applications that need to make use of /dev/rtc at all.

       rtconutc
           chronyd assumes by default that the RTC keeps local time (including any daylight
           saving changes). This is convenient on PCs running Linux which are dual-booted with
           Windows.

           If you keep the RTC on local time and your computer is off when daylight saving
           (summer time) starts or ends, the computer’s system time will be one hour in error
           when you next boot and start chronyd.

           An alternative is for the RTC to keep Universal Coordinated Time (UTC). This does not
           suffer from the 1 hour problem when daylight saving starts or ends.

           If the rtconutc directive appears, it means the RTC is required to keep UTC. The
           directive takes no arguments. It is equivalent to specifying the -u switch to the
           Linux hwclock program.

           Note that this setting is overridden by the hwclockfile file and is not relevant for
           the rtcsync directive.

       rtcsync
           The rtcsync directive enables a mode where the system time is periodically copied to
           the RTC and chronyd does not try to track its drift. This directive cannot be used
           with the rtcfile directive.

           On Linux, the RTC copy is performed by the kernel every 11 minutes.

           On macOS, chronyd will perform the RTC copy every 60 minutes when the system clock is
           in a synchronised state.

           On other systems this directive does nothing.

   Logging
       log [option]...
           The log directive indicates that certain information is to be logged. The log files
           are written to the directory specified by the logdir directive. A banner is
           periodically written to the files to indicate the meanings of the columns.

           rawmeasurements
               This option logs the raw NTP measurements and related information to a file called
               measurements.log. An entry is made for each packet received from the source. This
               can be useful when debugging a problem. An example line (which actually appears as
               a single line in the file) from the log file is shown below.

                   2016-11-09 05:40:50 203.0.113.15    N  2 111 111 1111  10 10 1.0 \
                      -4.966e-03  2.296e-01  1.577e-05  1.615e-01  7.446e-03 CB00717B 4B D K

               The columns are as follows (the quantities in square brackets are the values from
               the example line above):

                1. Date [2015-10-13]

                2. Hour:Minute:Second. Note that the date-time pair is expressed in UTC, not the
                   local time zone. [05:40:50]

                3. IP address of server or peer from which measurement came [203.0.113.15]

                4. Leap status (N means normal, + means that the last minute of the current month
                   has 61 seconds, - means that the last minute of the month has 59 seconds, ?
                   means the remote computer is not currently synchronised.) [N]

                5. Stratum of remote computer. [2]

                6. RFC 5905 tests 1 through 3 (1=pass, 0=fail) [111]

                7. RFC 5905 tests 5 through 7 (1=pass, 0=fail) [111]

                8. Tests for maximum delay, maximum delay ratio and maximum delay dev ratio,
                   against defined parameters, and a test for synchronisation loop (1=pass,
                   0=fail) [1111]

                9. Local poll [10]

                10. Remote poll [10]

                11. ‘Score’ (an internal score within each polling level used to decide when to
                   increase or decrease the polling level. This is adjusted based on number of
                   measurements currently being used for the regression algorithm). [1.0]

                12. The estimated local clock error (theta in RFC 5905). Positive indicates that
                   the local clock is slow of the remote source. [-4.966e-03]

                13. The peer delay (delta in RFC 5905). [2.296e-01]

                14. The peer dispersion (epsilon in RFC 5905). [1.577e-05]

                15. The root delay (DELTA in RFC 5905). [1.615e-01]

                16. The root dispersion (EPSILON in RFC 5905). [7.446e-03]

                17. Reference ID of the server’s source as a hexadecimal number. [CB00717B]

                18. NTP mode of the received packet (1=active peer, 2=passive peer, 4=server,
                   B=basic, I=interleaved). [4B]

                19. Source of the local transmit timestamp (D=daemon, K=kernel, H=hardware). [D]

                20. Source of the local receive timestamp (D=daemon, K=kernel, H=hardware). [K]

           measurements
               This option is identical to the rawmeasurements option, except it logs only valid
               measurements from synchronised sources, i.e. measurements which passed the RFC
               5905 tests 1 through 7. This can be useful for producing graphs of the source’s
               performance.

           statistics
               This option logs information about the regression processing to a file called
               statistics.log. An example line (which actually appears as a single line in the
               file) from the log file is shown below.

                   2016-08-10 05:40:50 203.0.113.15     6.261e-03 -3.247e-03 \
                        2.220e-03  1.874e-06  1.080e-06 7.8e-02  16   0   8  0.00

               The columns are as follows (the quantities in square brackets are the values from
               the example line above):

                1. Date [2015-07-22]

                2. Hour:Minute:Second. Note that the date-time pair is expressed in UTC, not the
                   local time zone. [05:40:50]

                3. IP address of server or peer from which measurement comes [203.0.113.15]

                4. The estimated standard deviation of the measurements from the source (in
                   seconds). [6.261e-03]

                5. The estimated offset of the source (in seconds, positive means the local clock
                   is estimated to be fast, in this case). [-3.247e-03]

                6. The estimated standard deviation of the offset estimate (in seconds).
                   [2.220e-03]

                7. The estimated rate at which the local clock is gaining or losing time relative
                   to the source (in seconds per second, positive means the local clock is
                   gaining). This is relative to the compensation currently being applied to the
                   local clock, not to the local clock without any compensation. [1.874e-06]

                8. The estimated error in the rate value (in seconds per second). [1.080e-06].

                9. The ratio of |old_rate - new_rate| / old_rate_error. Large values indicate the
                   statistics are not modelling the source very well. [7.8e-02]

                10. The number of measurements currently being used for the regression algorithm.
                   [16]

                11. The new starting index (the oldest sample has index 0; this is the method
                   used to prune old samples when it no longer looks like the measurements fit a
                   linear model). [0, i.e. no samples discarded this time]

                12. The number of runs. The number of runs of regression residuals with the same
                   sign is computed. If this is too small it indicates that the measurements are
                   no longer represented well by a linear model and that some older samples need
                   to be discarded. The number of runs for the data that is being retained is
                   tabulated. Values of approximately half the number of samples are expected.
                   [8]

                13. The estimated or configured asymmetry of network jitter on the path to the
                   source which was used to correct the measured offsets. The asymmetry can be
                   between -0.5 and +0.5. A negative value means the delay of packets sent to the
                   source is more variable than the delay of packets sent from the source back.
                   [0.00, i.e. no correction for asymmetry]

           tracking
               This option logs changes to the estimate of the system’s gain or loss rate, and
               any slews made, to a file called tracking.log. An example line (which actually
               appears as a single line in the file) from the log file is shown below.

                   2017-08-22 13:22:36 203.0.113.15     2     -3.541      0.075 -8.621e-06 N \
                               2  2.940e-03 -2.084e-04  1.534e-02  3.472e-04  8.304e-03

               The columns are as follows (the quantities in square brackets are the values from
               the example line above) :

                1. Date [2017-08-22]

                2. Hour:Minute:Second. Note that the date-time pair is expressed in UTC, not the
                   local time zone. [13:22:36]

                3. The IP address of the server or peer to which the local system is
                   synchronised. [203.0.113.15]

                4. The stratum of the local system. [2]

                5. The local system frequency (in ppm, positive means the local system runs fast
                   of UTC). [-3.541]

                6. The error bounds on the frequency (in ppm). [0.075]

                7. The estimated local offset at the epoch, which is normally corrected by
                   slewing the local clock (in seconds, positive indicates the clock is fast of
                   UTC). [-8.621e-06]

                8. Leap status (N means normal, + means that the last minute of this month has 61
                   seconds, - means that the last minute of the month has 59 seconds, ? means the
                   clock is not currently synchronised.) [N]

                9. The number of combined sources. [2]

                10. The estimated standard deviation of the combined offset (in seconds).
                   [2.940e-03]

                11. The remaining offset correction from the previous update (in seconds,
                   positive means the system clock is slow of UTC). [-2.084e-04]

                12. The total of the network path delays to the reference clock to which the
                   local clock is ultimately synchronised (in seconds). [1.534e-02]

                13. The total dispersion accumulated through all the servers back to the
                   reference clock to which the local clock is ultimately synchronised (in
                   seconds). [3.472e-04]

                14. The maximum estimated error of the system clock in the interval since the
                   previous update (in seconds). It includes the offset, remaining offset
                   correction, root delay, and dispersion from the previous update with the
                   dispersion which accumulated in the interval. [8.304e-03]

           rtc
               This option logs information about the system’s real-time clock. An example line
               (which actually appears as a single line in the file) from the rtc.log file is
               shown below.

                   2015-07-22 05:40:50     -0.037360 1       -0.037434\
                             -37.948  12   5  120

               The columns are as follows (the quantities in square brackets are the values from
               the example line above):

                1. Date [2015-07-22]

                2. Hour:Minute:Second. Note that the date-time pair is expressed in UTC, not the
                   local time zone. [05:40:50]

                3. The measured offset between the RTC and the system clock in seconds. Positive
                   indicates that the RTC is fast of the system time [-0.037360].

                4. Flag indicating whether the regression has produced valid coefficients. (1 for
                   yes, 0 for no). [1]

                5. Offset at the current time predicted by the regression process. A large
                   difference between this value and the measured offset tends to indicate that
                   the measurement is an outlier with a serious measurement error. [-0.037434]

                6. The rate at which the RTC is losing or gaining time relative to the system
                   clock. In ppm, with positive indicating that the RTC is gaining time.
                   [-37.948]

                7. The number of measurements used in the regression. [12]

                8. The number of runs of regression residuals of the same sign. Low values
                   indicate that a straight line is no longer a good model of the measured data
                   and that older measurements should be discarded. [5]

                9. The measurement interval used prior to the measurement being made (in
                   seconds). [120]

           refclocks
               This option logs the raw and filtered reference clock measurements to a file
               called refclocks.log. An example line (which actually appears as a single line in
               the file) from the log file is shown below.

                   2009-11-30 14:33:27.000000 PPS2    7 N 1  4.900000e-07 -6.741777e-07  1.000e-06

               The columns are as follows (the quantities in square brackets are the values from
               the example line above):

                1. Date [2009-11-30]

                2. Hour:Minute:Second.Microsecond. Note that the date-time pair is expressed in
                   UTC, not the local time zone. [14:33:27.000000]

                3. Reference ID of the reference clock from which the measurement came. [PPS2]

                4. Sequence number of driver poll within one polling interval for raw samples, or
                   - for filtered samples. [7]

                5. Leap status (N means normal, + means that the last minute of the current month
                   has 61 seconds, - means that the last minute of the month has 59 seconds). [N]

                6. Flag indicating whether the sample comes from PPS source. (1 for yes, 0 for
                   no, or - for filtered sample). [1]

                7. Local clock error measured by reference clock driver, or - for filtered
                   sample. [4.900000e-07]

                8. Local clock error with applied corrections. Positive indicates that the local
                   clock is slow. [-6.741777e-07]

                9. Assumed dispersion of the sample. [1.000e-06]

           tempcomp
               This option logs the temperature measurements and system rate compensations to a
               file called tempcomp.log. An example line (which actually appears as a single line
               in the file) from the log file is shown below.

                   2015-04-19 10:39:48  2.8000e+04  3.6600e-01

               The columns are as follows (the quantities in square brackets are the values from
               the example line above):

                1. Date [2015-04-19]

                2. Hour:Minute:Second. Note that the date-time pair is expressed in UTC, not the
                   local time zone. [10:39:48]

                3. Temperature read from the sensor. [2.8000e+04]

                4. Applied compensation in ppm, positive means the system clock is running faster
                   than it would be without the compensation. [3.6600e-01]

           An example of the directive is:

               log measurements statistics tracking

       logbanner entries
           A banner is periodically written to the log files enabled by the log directive to
           indicate the meanings of the columns.

           The logbanner directive specifies after how many entries in the log file should be the
           banner written. The default is 32, and 0 can be used to disable it entirely.

       logchange threshold
           This directive sets the threshold for the adjustment of the system clock that will
           generate a syslog message. Clock errors detected via NTP packets, reference clocks, or
           timestamps entered via the settime command of chronyc are logged.

           By default, the threshold is 1 second.

           An example of the use is:

               logchange 0.1

           which would cause a syslog message to be generated if a system clock error of over 0.1
           seconds starts to be compensated.

       logdir directory
           This directive allows the directory where log files are written to be specified.

           An example of the use of this directive is:

               logdir /var/log/chrony

       mailonchange email threshold
           This directive defines an email address to which mail should be sent if chronyd
           applies a correction exceeding a particular threshold to the system clock.

           An example of the use of this directive is:

               mailonchange root@localhost 0.5

           This would send a mail message to root if a change of more than 0.5 seconds were
           applied to the system clock.

           This directive cannot be used when a system call filter is enabled by the -F option as
           the chronyd process will not be allowed to fork and execute the sendmail binary.

   Miscellaneous
       hwtimestamp interface [option]...
           This directive enables hardware timestamping of NTP packets sent to and received from
           the specified network interface. The network interface controller (NIC) uses its own
           clock to accurately timestamp the actual transmissions and receptions, avoiding
           processing and queueing delays in the kernel, network driver, and hardware. This can
           significantly improve the accuracy of the timestamps and the measured offset, which is
           used for synchronisation of the system clock. In order to get the best results, both
           sides receiving and sending NTP packets (i.e. server and client, or two peers) need to
           use HW timestamping. If the server or peer supports the interleaved mode, it needs to
           be enabled by the xleave option in the server or the peer directive.

           This directive is supported on Linux 3.19 and newer. The NIC must support HW
           timestamping, which can be verified with the ethtool -T command. The list of
           capabilities should include SOF_TIMESTAMPING_RAW_HARDWARE,
           SOF_TIMESTAMPING_TX_HARDWARE, and SOF_TIMESTAMPING_RX_HARDWARE. Receive filter
           HWTSTAMP_FILTER_ALL, or HWTSTAMP_FILTER_NTP_ALL, is necessary for timestamping of
           received packets. Timestamping of packets received from bridged and bonded interfaces
           is supported on Linux 4.13 and newer. When chronyd is running, no other process (e.g.
           a PTP daemon) should be working with the NIC clock.

           If the kernel supports software timestamping, it will be enabled for all interfaces.
           The source of timestamps (i.e. hardware, kernel, or daemon) is indicated in the
           measurements.log file if enabled by the log measurements directive, and the ntpdata
           report in chronyc.

           If the specified interface is *, chronyd will try to enable HW timestamping on all
           available interfaces.

           The hwtimestamp directive has the following options:

           minpoll poll
               This option specifies the minimum interval between readings of the NIC clock. It’s
               defined as a power of two. It should correspond to the minimum polling interval of
               all NTP sources and the minimum expected polling interval of NTP clients. The
               default value is 0 (1 second) and the minimum value is -6 (1/64th of a second).

           minsamples samples
               This option specifies the minimum number of readings kept for tracking of the NIC
               clock. The default value is 2.

           maxsamples samples
               This option specifies the maximum number of readings kept for tracking of the NIC
               clock. The default value is 16.

           precision precision
               This option specifies the assumed precision of reading of the NIC clock. The
               default value is 100e-9 (100 nanoseconds).

           txcomp compensation
               This option specifies the difference in seconds between the actual transmission
               time at the physical layer and the reported transmit timestamp. This value will be
               added to transmit timestamps obtained from the NIC. The default value is 0.

           rxcomp compensation
               This option specifies the difference in seconds between the reported receive
               timestamp and the actual reception time at the physical layer. This value will be
               subtracted from receive timestamps obtained from the NIC. The default value is 0.

           nocrossts
               Some hardware can precisely cross timestamp the NIC clock with the system clock.
               This option disables the use of the cross timestamping.

           rxfilter filter
               This option selects the receive timestamping filter. The filter can be one of the
               following:

               all
                   Enables timestamping of all received packets.

               ntp
                   Enables timestamping of received NTP packets.

               none
                   Disables timestamping of received packets.

               The most specific filter for timestamping NTP packets which is supported by the
               NIC is selected by default. Some NICs can timestamp only PTP packets, which limits
               the selection to the none filter. Forcing timestamping of all packets with the all
               filter when the NIC supports both all and ntp filters can be useful when packets
               are received from or on a non-standard UDP port (e.g. specified by the port
               directive).

           Examples of the directive are:

               hwtimestamp eth0
               hwtimestamp eth1 txcomp 300e-9 rxcomp 645e-9
               hwtimestamp *

       include pattern
           The include directive includes a configuration file or multiple configuration files if
           a wildcard pattern is specified. This can be useful when maintaining configuration on
           multiple hosts to keep the differences in separate files.

           An example of the directive is:

               include /etc/chrony/chrony.d/*.conf

       keyfile file
           This directive is used to specify the location of the file containing ID-key pairs for
           authentication of NTP packets.

           The format of the directive is shown in the example below:

               keyfile /etc/chrony/chrony.keys

           The argument is simply the name of the file containing the ID-key pairs. The format of
           the file is shown below:

               10 tulip
               11 hyacinth
               20 MD5 ASCII:crocus
               25 SHA1 HEX:1dc764e0791b11fa67efc7ecbc4b0d73f68a070c
                ...

           Each line consists of an ID, name of an authentication hash function (optional), and a
           password. The ID can be any unsigned integer in the range 1 through 2^32-1. The
           default hash function is MD5, which is always supported.

           If chronyd was built with enabled support for hashing using a crypto library (nettle,
           nss, or libtomcrypt), the following functions are available: MD5, SHA1, SHA256,
           SHA384, SHA512. Depending on which library and version is chronyd using, some or all
           of the following functions may also be available: SHA3-224, SHA3-256, SHA3-384,
           SHA3-512, RMD128, RMD160, RMD256, RMD320, TIGER, WHIRLPOOL.

           The password can be specified as a string of characters not containing white space
           with an optional ASCII: prefix, or as a hexadecimal number with the HEX: prefix. The
           maximum length of the line is 2047 characters.

           The password is used with the hash function to generate and verify a message
           authentication code (MAC) in NTP packets. It is recommended to use SHA1, or stronger,
           hash function with random passwords specified in the hexadecimal format that have at
           least 128 bits. chronyd will log a warning to syslog on start if a source is specified
           in the configuration file with a key that has password shorter than 80 bits.

           The keygen command of chronyc can be used to generate random keys for the key file. By
           default, it generates 160-bit MD5 or SHA1 keys.

           For security reasons, the file should be readable only by root and the user under
           which chronyd is normally running (to allow chronyd to re-read the file when the rekey
           command is issued by chronyc).

       lock_all
           The lock_all directive will lock chronyd into RAM so that it will never be paged out.
           This mode is supported on Linux, FreeBSD, NetBSD, and Solaris. This directive uses the
           POSIX mlockall() system call to prevent chronyd from ever being swapped out. This
           should result in lower and more consistent latency. It should not have significant
           impact on performance as chronyd’s memory usage is modest. The mlockall(2) man page
           has more details.

       pidfile file
           Unless chronyd is started with the -Q option, it writes its process ID (PID) to a
           file, and checks this file on startup to see if another chronyd might already be
           running on the system. By default, the file used is /run/chronyd.pid. The pidfile
           directive allows the name to be changed, e.g.:

               pidfile /run/chronyd.pid

       sched_priority priority
           On Linux, FreeBSD, NetBSD, and Solaris, the sched_priority directive will select the
           SCHED_FIFO real-time scheduler at the specified priority (which must be between 0 and
           100). On macOS, this option must have either a value of 0 (the default) to disable the
           thread time constraint policy or 1 for the policy to be enabled.

           On systems other than macOS, this directive uses the pthread_setschedparam() system
           call to instruct the kernel to use the SCHED_FIFO first-in, first-out real-time
           scheduling policy for chronyd with the specified priority. This means that whenever
           chronyd is ready to run it will run, interrupting whatever else is running unless it
           is a higher priority real-time process. This should not impact performance as chronyd
           resource requirements are modest, but it should result in lower and more consistent
           latency since chronyd will not need to wait for the scheduler to get around to running
           it. You should not use this unless you really need it. The pthread_setschedparam(3)
           man page has more details.

           On macOS, this directive uses the thread_policy_set() kernel call to specify real-time
           scheduling. As noted above, you should not use this directive unless you really need
           it.

       user user
           The user directive sets the name of the system user to which chronyd will switch after
           start in order to drop root privileges.

           On Linux, chronyd needs to be compiled with support for the libcap library. On macOS,
           FreeBSD, NetBSD and Solaris 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.

           The compiled-in default value is _chrony.

EXAMPLES

   NTP client with permanent connection to NTP servers
       This section shows how to configure chronyd for computers that are connected to the
       Internet (or to any network containing true NTP servers which ultimately derive their time
       from a reference clock) permanently or most of the time.

       To operate in this mode, you will need to know the names of the NTP servers you want to
       use. You might be able to find names of suitable servers by one of the following methods:

       •   Your institution might already operate servers on its network. Contact your system
           administrator to find out.

       •   Your ISP probably has one or more NTP servers available for its customers.

       •   Somewhere under the NTP homepage there is a list of public stratum 1 and stratum 2
           servers. You should find one or more servers that are near to you. Check that their
           access policy allows you to use their facilities.

       •   Use public servers from the pool.ntp.org <http://www.pool.ntp.org/> project.

       Assuming   that   your   NTP  servers  are  called  foo.example.net,  bar.example.net  and
       baz.example.net, your chrony.conf file could contain as a minimum:

           server foo.example.net
           server bar.example.net
           server baz.example.net

       However, you will probably want to include some of the other  directives.  The  driftfile,
       makestep  and  rtcsync might be particularly useful. Also, the iburst option of the server
       directive is  useful  to  speed  up  the  initial  synchronisation.  The  smallest  useful
       configuration file would look something like:

           server foo.example.net iburst
           server bar.example.net iburst
           server baz.example.net iburst
           driftfile /var/lib/chrony/drift
           makestep 1.0 3
           rtcsync

       When using a pool of NTP servers (one name is used for multiple servers which might change
       over time), it is better to specify them with  the  pool  directive  instead  of  multiple
       server directives. The configuration file could in this case look like:

           pool pool.ntp.org iburst
           driftfile /var/lib/chrony/drift
           makestep 1.0 3
           rtcsync

   NTP client with infrequent connection to NTP servers
       This section shows how to configure chronyd for computers that have occasional connections
       to NTP servers. In this case, you will need some additional configuration to tell  chronyd
       when  the  connection goes up and down. This saves the program from continuously trying to
       poll the servers when they are inaccessible.

       Again, assuming that your NTP servers  are  called  foo.example.net,  bar.example.net  and
       baz.example.net, your chrony.conf file would now contain:

           server foo.example.net offline
           server bar.example.net offline
           server baz.example.net offline
           driftfile /var/lib/chrony/drift
           makestep 1.0 3
           rtcsync

       The  offline  keyword  indicates that the servers start in an offline state, and that they
       should not be contacted until chronyd receives notification from chronyc that the link  to
       the  Internet  is  present. To tell chronyd when to start and finish sampling the servers,
       the online and offline commands of chronyc need to be used.

       To give an example of their use, assuming that pppd is the program being used  to  connect
       to  the  Internet  and  that  chronyc  has  been installed at /usr/bin/chronyc, the script
       /etc/ppp/ip-up would include:

           /usr/bin/chronyc online

       and the script /etc/ppp/ip-down would include:

           /usr/bin/chronyc offline

       chronyd’s polling of the servers would now only  occur  whilst  the  machine  is  actually
       connected to the Internet.

   Isolated networks
       This  section  shows  how  to  configure  chronyd  for  computers  that never have network
       conectivity to any computer which ultimately derives its time from a reference clock.

       In this situation, one computer is  selected  to  be  the  master  timeserver.  The  other
       computers are either direct clients of the master, or clients of clients.

       The  local  directive  enables  a  local  reference  mode,  which allows chronyd to appear
       synchronised even when it is not.

       The rate value in the master’s drift file needs to be set to the average rate at which the
       master  gains  or loses time. chronyd includes support for this, in the form of the manual
       directive and the settime command in the chronyc program.

       If the master is rebooted, chronyd can  re-read  the  drift  rate  from  the  drift  file.
       However,  the master has no accurate estimate of the current time. To get around this, the
       system can be configured so that the master can initially set itself to a  ‘majority-vote’
       of  selected  clients' times; this allows the clients to ‘flywheel’ the master while it is
       rebooting.

       The smoothtime directive is useful when the clocks of  the  clients  need  to  stay  close
       together  when  the  local  time is adjusted by the settime command. The smoothing process
       needs to be activated by the smoothtime activate command when the local time is  ready  to
       be served. After that point, any adjustments will be smoothed out.

       A typical configuration file for the master (called master) might be (assuming the clients
       and the master are in the 192.168.165.x subnet):

           initstepslew 1 client1 client3 client6
           driftfile /var/lib/chrony/drift
           local stratum 8
           manual
           allow 192.168.165.0/24
           smoothtime 400 0.01
           rtcsync

       For the clients that have to resynchronise the master when it restarts, the  configuration
       file might be:

           server master iburst
           driftfile /var/lib/chrony/drift
           allow 192.168.165.0/24
           makestep 1.0 3
           rtcsync

       The  rest  of  the  clients  would  be  the  same,  except that the allow directive is not
       required.

       If there is no suitable computer to be designated as the master, or there is a requirement
       to  keep  the  clients  synchronised  even  when  it fails, the orphan option of the local
       directive enables a special mode where the master  is  selected  from  multiple  computers
       automatically. They all need to use the same local configuration and poll one another. The
       server with the smallest reference ID (which is based on its IP  address)  will  take  the
       role  of  the master and others will be synchronised to it. When it fails, the server with
       the second smallest reference ID will take over and so on.

       A configuration file for the first server might  be  (assuming  there  are  three  servers
       called master1, master2, and master3):

           initstepslew 1 master2 master3
           server master2
           server master3
           driftfile /var/lib/chrony/drift
           local stratum 8 orphan
           manual
           allow 192.168.165.0/24
           rtcsync

       The  other  servers would be the same, except the hostnames in the initstepslew and server
       directives would be modified  to  specify  the  other  servers.  Their  clients  might  be
       configured to poll all three servers.

   RTC tracking
       This  section considers a computer which has occasional connections to the Internet and is
       turned off between ‘sessions’. In this case, chronyd  relies  on  the  computer’s  RTC  to
       maintain  the time between the periods when it is powered up. It assumes that Linux is run
       exclusively on the computer. Dual-boot systems might work; it depends what  (if  anything)
       the  other  system  does  to  the RTC. On 2.6 and later kernels, if your motherboard has a
       HPET, you will need to enable the HPET_EMULATE_RTC option in  your  kernel  configuration.
       Otherwise, chronyd will not be able to interact with the RTC device and will give up using
       it.

       When the computer is connected to the Internet, chronyd has access to external NTP servers
       which it makes measurements from. These measurements are saved, and straight-line fits are
       performed on them to provide an estimate of the computer’s time error and rate of  gaining
       or losing time.

       When  the  computer  is  taken offline from the Internet, the best estimate of the gain or
       loss rate is used to free-run the computer until it next goes online.

       Whilst the computer is running, chronyd makes measurements of the RTC  (via  the  /dev/rtc
       interface,  which  must be compiled into the kernel). An estimate is made of the RTC error
       at a particular RTC second, and the rate at which the RTC gains or loses time relative  to
       true time.

       When  the  computer is powered down, the measurement histories for all the NTP servers are
       saved to files, and the RTC tracking information is also saved to a file (if  the  rtcfile
       directive  has been specified). These pieces of information are also saved if the dump and
       writertc commands respectively are issued through chronyc.

       When the computer is rebooted, chronyd reads the current RTC time and the RTC  information
       saved  at  the last shutdown. This information is used to set the system clock to the best
       estimate of what its time would have been now, had it been left running continuously.  The
       measurement histories for the servers are then reloaded.

       The next time the computer goes online, the previous sessions' measurements can contribute
       to the line-fitting process, which gives a much better estimate of the computer’s gain  or
       loss rate.

       One  problem  with  saving  the measurements and RTC data when the machine is shut down is
       what happens if there is a power failure; the most recent data will not be saved. Although
       chronyd  is  robust  enough  to  cope with this, some performance might be lost. (The main
       danger arises if the RTC has been changed during the session, with the trimrtc command  in
       chronyc. Because of this, trimrtc will make sure that a meaningful RTC file is saved after
       the change is completed).

       The easiest protection against power failure is to put the dump and writertc  commands  in
       the  same  place as the offline command is issued to take chronyd offline; because chronyd
       free-runs between online sessions, no parameters will change significantly  between  going
       offline from the Internet and any power failure.

       A  final  point regards computers which are left running for extended periods and where it
       is desired to spin down the hard disc when it is not in use (e.g. when not accessed for 15
       minutes).  chronyd  has been planned so it supports such operation; this is the reason why
       the RTC tracking parameters are not saved to disc after every update, but  only  when  the
       user  requests such a write, or during the shutdown sequence. The only other facility that
       will generate periodic writes to the disc is the log rtc  facility  in  the  configuration
       file; this option should not be used if you want your disc to spin down.

       To  illustrate  how  a  computer  might be configured for this case, example configuration
       files are shown.

       For the chrony.conf file, the following can be used as an example.

           server foo.example.net maxdelay 0.4 offline
           server bar.example.net maxdelay 0.4 offline
           server baz.example.net maxdelay 0.4 offline
           logdir /var/log/chrony
           log statistics measurements tracking
           driftfile /var/lib/chrony/drift
           makestep 1.0 3
           maxupdateskew 100.0
           dumpdir /var/lib/chrony
           rtcfile /var/lib/chrony/rtc

       pppd is used for connecting to the Internet. This  runs  two  scripts  /etc/ppp/ip-up  and
       /etc/ppp/ip-down when the link goes online and offline respectively.

       The relevant part of the /etc/ppp/ip-up file is:

           /usr/bin/chronyc online

       and the relevant part of the /etc/ppp/ip-down script is:

           /usr/bin/chronyc -m offline dump writertc

       chronyd  is  started during the boot sequence with the -r and -s options. It might need to
       be started before any software that depends on the system  clock  not  jumping  or  moving
       backwards, depending on the directives in chronyd’s configuration file.

       For the system shutdown, chronyd should receive a SIGTERM several seconds before the final
       SIGKILL; the SIGTERM causes the measurement histories and RTC information to be saved.

   Public NTP server
       chronyd can be configured to operate as a public NTP server, e.g. to join the pool.ntp.org
       <http://www.pool.ntp.org/en/join.html>  project.  The  configuration is similar to the NTP
       client with permanent connection,  except  it  needs  to  allow  client  access  from  all
       addresses. It is recommended to find at least four good servers (e.g. from the pool, or on
       the NTP homepage). If the server has a hardware reference clock (e.g. a GPS receiver),  it
       can be specified by the refclock directive.

       The  amount of memory used for logging client accesses can be increased in order to enable
       clients to use the interleaved mode even when the server has a large  number  of  clients,
       and  better  support rate limiting if it is enabled by the ratelimit directive. The system
       timezone database, if it is kept up to date and includes the right/UTC  timezone,  can  be
       used  as  a reliable source to determine when a leap second will be applied to UTC. The -r
       option with the dumpdir directive shortens the time in which chronyd will not be  able  to
       serve  time  to its clients when it needs to be restarted (e.g. after upgrading to a newer
       version, or a change in the configuration).

       The configuration file could look like:

           server foo.example.net iburst
           server bar.example.net iburst
           server baz.example.net iburst
           server qux.example.net iburst
           makestep 1.0 3
           rtcsync
           allow
           clientloglimit 100000000
           leapsectz right/UTC
           driftfile /var/lib/chrony/drift
           dumpdir /run/chrony

SEE ALSO

       chronyc(1), chronyd(8)

BUGS

       For instructions on how to report bugs, please visit <https://chrony.tuxfamily.org/>.

AUTHORS

       chrony was written by Richard Curnow, Miroslav Lichvar, and others.