Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
CHRONY.CONF(5)		      Configuration Files		CHRONY.CONF(5)

NAME
       chrony.conf - chronyd configuration file

SYNOPSIS
       chrony.conf

DESCRIPTION
       This file configures the	chronyd	daemon.	The compiled-in	location is
       /usr/local/etc/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 /var/run/chrony

	   A source whose IP address is	1.2.3.4	would have its measurement
	   history saved in the	file /var/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/db/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
	   /var/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 ''.

	   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/db/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 /usr/local/etc/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 /usr/local/etc/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 /var/run/chrony/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 chronyd.

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:

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

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

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

       o   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/db/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/db/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/db/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/local/bin/chronyc,  the script /etc/ppp/ip-up would
       include:

	   /usr/local/bin/chronyc online

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

	   /usr/local/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/db/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/db/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/db/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/db/chrony/drift
	   makestep 1.0	3
	   maxupdateskew 100.0
	   dumpdir /var/db/chrony
	   rtcfile /var/db/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/local/bin/chronyc online

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

	   /usr/local/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/db/chrony/drift
	   dumpdir /var/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.

chrony 3.5.1			  2020-08-19			CHRONY.CONF(5)

NAME | SYNOPSIS | DESCRIPTION | DIRECTIVES | EXAMPLES | SEE ALSO | BUGS | AUTHORS

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=chrony.conf&sektion=5&manpath=FreeBSD+12.1-RELEASE+and+Ports>

home | help