54c8732c46
Enable the PRV_Name2IPAddress() function with seccomp support and start the helper process before loading the seccomp filter (but after dropping root privileges). This will move the getaddrinfo() call outside the seccomp filter and should make it more reliable as the list of required system calls won't depend on what glibc NSS modules are used on the system.
382 lines
17 KiB
Text
382 lines
17 KiB
Text
:toc:
|
|
:numbered:
|
|
|
|
Frequently Asked Questions
|
|
==========================
|
|
|
|
== +chrony+ compared to other programs
|
|
|
|
=== 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
|
|
doesn't implement some of the less useful NTP modes like broadcast client or
|
|
multicast server/client.
|
|
|
|
For a more detailed comparison of features and performance, see the
|
|
http://chrony.tuxfamily.org/comparison.html[comparison page] on the +chrony+
|
|
website and the
|
|
http://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
|
|
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
|
|
on an isolated network with no hardware reference clocks in sight, +chrony+
|
|
will probably work much better for you.
|
|
|
|
The original reason +chrony+ was written was that +ntpd+ (called +xntpd+ at the
|
|
time) could not to do anything sensible on a PC which was connected to the 'net
|
|
only for about 5 minutes once or twice a day, mainly to upload/download email
|
|
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
|
|
|
|
=== What is the minimum recommended configuration for an NTP client?
|
|
|
|
First, the client needs to know which NTP servers it should ask for the current
|
|
time. They are specified by the +server+ or +pool+ directive. The +pool+
|
|
directive can be used for names that resolve to multiple addresses. For good
|
|
reliability the client should have at least three servers. The +iburst+ option
|
|
speeds up the initial synchronisation.
|
|
|
|
To stabilize the initial synchronisation on the next start, the estimated drift
|
|
of the system clock is saved by adding the +driftfile+ directive.
|
|
|
|
If the system clock can be far from the true time after boot for any reason,
|
|
+chronyd+ should be allowed to correct it quickly by stepping instead of
|
|
slewing, which would take a very long time. The +makestep+ directive does
|
|
that.
|
|
|
|
In order to keep the real-time clock (RTC) close to the true time on Linux, so
|
|
the system time is reasonably close to the true time when it's initialized on
|
|
the next boot from the RTC, the +rtcsync+ directive enables a kernel mode in
|
|
which the system time is copied to the RTC every 11 minutes.
|
|
|
|
If you want to use public NTP servers from the
|
|
http://www.pool.ntp.org/[pool.ntp.org] project, the minimal 'chrony.conf' file
|
|
could be:
|
|
|
|
----
|
|
pool pool.ntp.org iburst
|
|
driftfile /var/lib/chrony/drift
|
|
makestep 1 3
|
|
rtcsync
|
|
----
|
|
|
|
=== How do I make an NTP server from an NTP client?
|
|
|
|
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
|
|
specified subnet allows all IPv4 and IPv6 addresses.
|
|
|
|
=== 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 others as clients of it. Add a +local+ directive to the master's
|
|
'chrony.conf' file. This configuration will be better because
|
|
|
|
* the load on the external connection is less
|
|
* the load on the external NTP server(s) is less
|
|
* if your external connection goes down, the computers on the LAN
|
|
will maintain a common time with each other.
|
|
|
|
=== Must I specify servers by IP address if DNS is not available on chronyd start?
|
|
|
|
No. Starting from version 1.25, +chronyd+ will keep trying to resolve
|
|
the hostnames specified in the +server+ and +peer+ directives in
|
|
increasing intervals until it succeeds. The +online+ command can be
|
|
issued from +chronyc+ to try to resolve them immediately.
|
|
|
|
=== 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+
|
|
to the 'chrony.conf' file to completely disable the NTP server functionality
|
|
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+
|
|
directive or command, an NTP peer is configured, or the +broadcast+ directive
|
|
is used.
|
|
|
|
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
|
|
loopback interface. This is done by default since version 2.0.
|
|
|
|
----
|
|
bindcmdaddress 127.0.0.1
|
|
bindcmdaddress ::1
|
|
----
|
|
|
|
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
|
|
socket since version 2.2), you can disable the internet command sockets
|
|
completely by adding +cmdport 0+ to the configuration file.
|
|
|
|
You can specify an unprivileged user with the +-u+ option, or the +user+
|
|
directive in the 'chrony.conf' file, to which +chronyd+ will switch after start
|
|
in order to drop root privileges. The configure script has a +--with-user+
|
|
option, which sets the default user. On Linux, +chronyd+ needs to be compiled
|
|
with support for the +libcap+ library. On other systems, +chronyd+ forks into
|
|
two processes. The child process retains root privileges, but can only perform
|
|
a very limited range of privileged system calls on behalf of the parent.
|
|
|
|
Also, if +chronyd+ is compiled with support for the Linux secure computing
|
|
(seccomp) facility, you can enable a system call filter with the +-F+ option.
|
|
It will significantly reduce the kernel attack surface and possibly prevent
|
|
kernel exploits from the +chronyd+ process if it's compromised. It's
|
|
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
|
|
calls made from libraries that +chronyd+ is using (e.g. libc) and different
|
|
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
|
|
normal operation.
|
|
|
|
=== How can I improve the accuracy of the system clock with NTP sources?
|
|
|
|
Select NTP servers that are well synchronised, stable and close to your
|
|
network. It's better to use more than one server, three or four is usually
|
|
recommended as the minimum, so +chronyd+ can detect falsetickers and combine
|
|
measurements from multiple sources.
|
|
|
|
There are also useful options which can be set in the +server+ directive, they
|
|
are +minpoll+, +maxpoll+, +polltarget+, +maxdelay+, +maxdelayratio+ and
|
|
+maxdelaydevratio+.
|
|
|
|
The first three options set the minimum and maximum allowed polling interval,
|
|
and how should be the actual interval adjusted in the specified range. Their
|
|
default values are 6 (64 seconds) for +minpoll+, 10 (1024 seconds) for
|
|
+maxpoll+ and 6 (samples) for +polltarget+. The default values should be used
|
|
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
|
|
shorter polling intervals may significantly improve the accuracy of the system
|
|
clock.
|
|
|
|
The optimal polling interval depends on many factors, including the ratio
|
|
between the wander of the clock and the network jitter (sometimes expressed in
|
|
NTP documents as the Allan intercept), the temperature sensitivity of the
|
|
crystal oscillator and the maximum rate of change of the temperature.
|
|
|
|
An example of the directive for an NTP server on the internet that you are
|
|
allowed to poll frequently could be
|
|
|
|
----
|
|
server foo.example.net minpoll 4 maxpoll 6 polltarget 16
|
|
----
|
|
|
|
An example using very short polling intervals for a server located in the same
|
|
LAN could be
|
|
|
|
----
|
|
server ntp.local minpoll 2 maxpoll 4 polltarget 30
|
|
----
|
|
|
|
The maxdelay options are useful to ignore measurements with larger delay (e.g.
|
|
due to congestion in the network) and improve the stability of the
|
|
synchronisation. The +maxdelaydevratio+ option could be added to the example
|
|
with local NTP server
|
|
|
|
----
|
|
server ntp.local minpoll 2 maxpoll 4 polltarget 30 maxdelaydevratio 2
|
|
----
|
|
|
|
=== What happened to the +commandkey+ and +generatecommandkey+ directives?
|
|
|
|
They were removed in version 2.2. Authentication is no longer supported in the
|
|
command protocol. Commands that required authentication are now allowed only
|
|
through a Unix domain socket, which is accessible only by the root and chrony
|
|
users. If you need to configure +chronyd+ remotely or locally without the root
|
|
password, please consider using ssh and/or sudo to run +chronyc+ under the root
|
|
or chrony user on the same host as +chronyd+ is running.
|
|
|
|
== Computer is not synchronising
|
|
|
|
This is the most common problem. There are a number of reasons, see the
|
|
following questions.
|
|
|
|
=== Behind a firewall?
|
|
|
|
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
|
|
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
|
|
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
|
|
been running for a short period. See if any measurements appear.
|
|
|
|
=== Are NTP servers specified with the +offline+ option?
|
|
|
|
Check that you're using +chronyc+\'s +online+ and +offline+ commands
|
|
appropriately. Again, check in 'measurements.log' to see if you're getting any
|
|
data back from the server.
|
|
|
|
=== Is +chronyd+ allowed to step the system clock?
|
|
|
|
By default, +chronyd+ adjusts the clock gradually by slowing it down or
|
|
speeding it up. If the clock is too far from the correct time, it will take
|
|
a long time to correct the error. The +System time+ value printed by the
|
|
+chronyc+'s +tracking+ command is the remaining correction that needs to be
|
|
applied to the system clock.
|
|
|
|
The +makestep+ directive can be used to allow +chronyd+ to step the clock. For
|
|
example, if 'chrony.conf' had
|
|
|
|
----
|
|
makestep 1 3
|
|
----
|
|
|
|
the clock would be stepped in the first three updates if its offset was larger
|
|
than one second. Normally, it's recommended to allow the step only in the
|
|
first few updates, but in some cases (e.g. a computer without RTC or virtual
|
|
machine which can be suspended and resumed with incorrect time) it may be
|
|
necessary to allow the step at any clock update. The example above would
|
|
change to
|
|
|
|
----
|
|
makestep 1 -1
|
|
----
|
|
|
|
== Issues with +chronyc+
|
|
|
|
=== I keep getting the error +506 Cannot talk to daemon+
|
|
|
|
When accessing +chronyd+ remotely, make sure that the 'chrony.conf' file (on
|
|
the computer where +chronyd+ is running) has a 'cmdallow' entry for the
|
|
computer you are running +chronyc+ on and an appropriate 'bindcmdaddress'
|
|
directive. This isn't necessary for localhost.
|
|
|
|
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
|
|
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).
|
|
|
|
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.
|
|
|
|
=== I keep getting the error +501 Not authorised+
|
|
|
|
Since version 2.2, the +password+ command doesn't do anything and +chronyc+
|
|
needs to run under the root or chrony user, which are allowed to access the
|
|
Unix domain command socket.
|
|
|
|
=== Is the +chronyc+ / +chronyd+ protocol documented anywhere?
|
|
|
|
Only by the source code :-) See 'cmdmon.c' (+chronyd+ side) and 'client.c'
|
|
(+chronyc+ side).
|
|
|
|
== Real-time clock issues
|
|
|
|
=== What is the real-time clock (RTC)?
|
|
|
|
This is the clock which keeps the time even when your computer is turned off.
|
|
It is used to initialize the system clock on boot. It normally doesn't drift
|
|
more than few seconds per day.
|
|
|
|
There are two approaches how +chronyd+ can work with it. One is to use the
|
|
+rtcsync+ directive, which tells +chronyd+ to enable a kernel mode which sets
|
|
the RTC from the system clock every 11 minutes. +chronyd+ itself won't touch
|
|
the RTC. If the computer is not turned off for a long time, the RTC should
|
|
still be close to the true time when the system clock will be initialized from
|
|
it on the next boot.
|
|
|
|
The other option is to use the +rtcfile+ directive, which will tell +chronyd+
|
|
to monitor the rate at which the RTC gains or loses time. When +chronyd+ is
|
|
started with the +-s+ option on the next boot, it will set the system time from
|
|
the RTC and also compensate for the drift it has measured previously. The
|
|
+rtcautotrim+ directive can be used to keep the RTC close to the true time, but
|
|
it'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.
|
|
|
|
=== 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
|
|
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
|
|
system clock is synchronised. If you want to use +chronyd+'s RTC monitoring
|
|
(+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
|
|
to +chronyd+. At the next reboot, +chronyd+ started with the +-s+ option will
|
|
compensate this (wrong) time with its estimate of how far the RTC has drifted
|
|
whilst the power was off, giving a meaningless initial system time.
|
|
|
|
There is no need to remove +hwclock+ from the boot process, as long as +chronyd+
|
|
is started after it has run.
|
|
|
|
=== I just keep getting the +513 RTC driver not running+ message
|
|
|
|
For the real time clock support to work, you need the following three
|
|
things
|
|
|
|
* a kernel that is supported (e.g. 2.2 onwards)
|
|
* enhanced RTC support compiled into the kernel
|
|
* an +rtcfile+ directive in your 'chrony.conf' file
|
|
|
|
== NTP-specific issues
|
|
|
|
=== 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.
|
|
|
|
== Microsoft Windows
|
|
|
|
=== Does +chrony+ support Windows?
|
|
|
|
No. The +chronyc+ program (the command-line client used for configuring
|
|
+chronyd+ while it is running) has been successfully built and run under
|
|
Cygwin in the past. +chronyd+ is not portable, because part of it is
|
|
very system-dependent. It needs adapting to work with Windows'
|
|
equivalent of the adjtimex() call, and it needs to be made to work as a
|
|
service.
|
|
|
|
=== Are there any plans to support Windows?
|
|
|
|
We have no plans to do this. Anyone is welcome to pick this work up and
|
|
contribute it back to the project.
|