doc: update FAQ

This commit is contained in:
Miroslav Lichvar 2016-05-12 15:21:26 +02:00
parent b48e4421de
commit 99e1c44c25

View file

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