doc: update FAQ
This commit is contained in:
parent
d46d7ad947
commit
698404b02f
1 changed files with 80 additions and 87 deletions
167
chrony.texi.in
167
chrony.texi.in
|
@ -4487,7 +4487,7 @@ command is issued.
|
||||||
@menu
|
@menu
|
||||||
* Administrative issues::
|
* Administrative issues::
|
||||||
* Chrony compared to other programs::
|
* Chrony compared to other programs::
|
||||||
* Selection of NTP servers::
|
* Configuration::
|
||||||
* Computer is not synchronising::
|
* Computer is not synchronising::
|
||||||
* Issues with chronyc::
|
* Issues with chronyc::
|
||||||
* Real-time clock issues::
|
* Real-time clock issues::
|
||||||
|
@ -4507,8 +4507,9 @@ For the current development from the developers' version control system see the
|
||||||
@code{Git} link on the web site.
|
@code{Git} link on the web site.
|
||||||
|
|
||||||
@subsection Are there any packaged versions of chrony?
|
@subsection Are there any packaged versions of chrony?
|
||||||
We are aware of packages for Debian, Fedora, Gentoo, Mandriva, Slackware, and
|
We are aware of packages for Arch, Debian, Fedora, Gentoo, Mandriva, Slackware,
|
||||||
Ubuntu. We are not involved with how these are built or distributed.
|
Ubuntu, FreeBSD and NetBSD. We are not involved with how these are built or
|
||||||
|
distributed.
|
||||||
|
|
||||||
@subsection Where is the home page?
|
@subsection Where is the home page?
|
||||||
It is currently at
|
It is currently at
|
||||||
|
@ -4534,25 +4535,25 @@ BSD-like license.
|
||||||
@c {{{ S:Chrony compared to other programs
|
@c {{{ S:Chrony compared to other programs
|
||||||
@node Chrony compared to other programs
|
@node Chrony compared to other programs
|
||||||
@section Chrony compared to other programs
|
@section Chrony compared to other programs
|
||||||
@subsection How does chrony compare to xntpd?
|
@subsection How does chrony compare to ntpd?
|
||||||
If your computer is permenently connected, or connected for long periods (that
|
Chrony can usually synchronise the system clock faster and with better time
|
||||||
is, for the several hours it takes xntpd to settle down), or you need to
|
accuracy, but it doesn't implement all NTP features, e.g. broadcast/multicast
|
||||||
support hardware reference clocks to your computer, then xntpd will work fine.
|
mode, or authentication based on public-key cryptography. For a more detailed
|
||||||
Apart from not supporting hardware clocks, chrony will work fine too.
|
comparison, see section @code{Comparison with ntpd} in the manual.
|
||||||
|
|
||||||
If your computer connects to the 'net for 5 minutes once a day (or something
|
If your computer connects to the 'net only for few minutes at a time, you turn
|
||||||
like that), or you turn your Linux computer off when you're not using it, or
|
your Linux computer off or suspend it frequently, the clock is not very stable
|
||||||
you want to use NTP on an isolated network with no hardware clocks in sight,
|
(e.g. it is a virtual machine), or you want to use NTP on an isolated network
|
||||||
chrony will work much better for you.
|
with no hardware clocks in sight, chrony will probably work much better for
|
||||||
|
you.
|
||||||
|
|
||||||
The reason I wrote chrony was that I could not get xntpd to do anything
|
The original reason chrony was written was that ntpd (called xntpd at the
|
||||||
sensible on my PC at home, which is connected to the 'net for about 5 minutes
|
time) could not to do anything sensible on a PC which was connected to
|
||||||
once or twice a day, mainly to upload/download email and news. Nowadays it is
|
the 'net only for about 5 minutes once or twice a day, mainly to
|
||||||
also turned off for 22-23 hours a day, when not in use. I wanted a program
|
upload/download email and news. The requirements were
|
||||||
which would
|
|
||||||
|
|
||||||
@itemize @bullet
|
@itemize @bullet
|
||||||
@item slew the time to correct it when I go online and NTP servers become
|
@item slew the time to correct it when going online and NTP servers become
|
||||||
visible
|
visible
|
||||||
@item determine the rate at which the computer gains or loses time and use this
|
@item 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
|
information to keep it reasonably correct between connects to the 'net. This
|
||||||
|
@ -4561,22 +4562,21 @@ availability of the references or the fact the computer is turned off between
|
||||||
groups of measurements.
|
groups of measurements.
|
||||||
@item maintain the time across reboots, by working out the error and drift rate
|
@item 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
|
of the computer's real-time clock and using this information to set the system
|
||||||
clock correctly at boot up. (In the last few months, it became impossible for
|
clock correctly at boot up.
|
||||||
me to leave my computer powered permanently.)
|
|
||||||
@end itemize
|
@end itemize
|
||||||
|
|
||||||
Also, when working with isolated networks with no true time references
|
Also, when working with isolated networks with no true time references at all
|
||||||
at all, I found xntpd gave me no help with managing the local clock's
|
ntpd was found to give no help with managing the local clock's gain/loss rate
|
||||||
gain/loss rate on the NTP master node (which I set from my watch). I
|
on the NTP master node (which was set from watch). Some automated support was
|
||||||
added some automated support in chrony to deal with this.
|
added to chrony to deal with this.
|
||||||
|
|
||||||
@c }}}
|
@c }}}
|
||||||
@c {{{ S:Selection of NTP servers
|
@c {{{ S:Configuration
|
||||||
@node Selection of NTP servers
|
@node Configuration
|
||||||
@section Selection of NTP servers
|
@section Configuration
|
||||||
|
|
||||||
@subsection I have several computers on a LAN. Should I make one the master, or make them all clients of an external server?
|
@subsection I have several computers on a LAN. Should be all clients of an external server?
|
||||||
I think the best configuration is to make one computer the master, with the
|
The best configuration is usually to make one computer the master, with the
|
||||||
others as clients of it. Add a @code{local} directive to the master's
|
others as clients of it. Add a @code{local} directive to the master's
|
||||||
chrony.conf file. This configuration will be better because
|
chrony.conf file. This configuration will be better because
|
||||||
|
|
||||||
|
@ -4587,6 +4587,28 @@ chrony.conf file. This configuration will be better because
|
||||||
maintain a common time with each other.
|
maintain a common time with each other.
|
||||||
@end itemize
|
@end itemize
|
||||||
|
|
||||||
|
@subsection Must I specify servers by IP address if DNS is not available on chronyd start?
|
||||||
|
No. Starting from version 1.25, @code{chronyd} will keep trying to resolve the
|
||||||
|
hostnames specified in the @code{server} and @code{peer} directives in
|
||||||
|
increasing intervals until it succeeds. The @code{online} command can be
|
||||||
|
issued from @code{chronyc} to try to resolve them immediately.
|
||||||
|
|
||||||
|
@subsection How can I make chronyd more secure?
|
||||||
|
If you don't need to serve time to NTP clients, you can add @code{port 0} to
|
||||||
|
the @file{chrony.conf} file to disable the NTP server/peer sockets and prevent
|
||||||
|
NTP requests from reaching @code{chronyd}.
|
||||||
|
|
||||||
|
If you don't need to use @code{chronyc} remotely, you can add the following
|
||||||
|
directives to the configuration file to bind the command sockets to the
|
||||||
|
loopback interface
|
||||||
|
|
||||||
|
@example
|
||||||
|
bindcmdaddress 127.0.0.1
|
||||||
|
bindcmdaddress ::1
|
||||||
|
@end example
|
||||||
|
|
||||||
|
If you don't need to use @code{chronyc} at all, you can disable the command
|
||||||
|
sockets by adding @code{cmdport 0} to the configuration file.
|
||||||
@c }}}
|
@c }}}
|
||||||
@c {{{ S:Computer is not synchronising
|
@c {{{ S:Computer is not synchronising
|
||||||
@node Computer is not synchronising
|
@node Computer is not synchronising
|
||||||
|
@ -4597,16 +4619,13 @@ following questions.
|
||||||
|
|
||||||
@subsection Behind a firewall?
|
@subsection Behind a firewall?
|
||||||
If there is a firewall between you and the NTP server you're trying to use,
|
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 etherfind or tcpdump to see
|
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,
|
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
|
see if the receive light blinks straight after the transmit light (when the
|
||||||
link is quiet apart from the NTP traffic.) Try adding @code{log measurements}
|
link is quiet apart from the NTP traffic.) Try adding @code{log measurements}
|
||||||
to the @file{chrony.conf} file and look in the measurements.log file after
|
to the @file{chrony.conf} file and look in the measurements.log file after
|
||||||
chrony has been running for a short period. See if any measurements appear.
|
chrony has been running for a short period. See if any measurements appear.
|
||||||
|
|
||||||
Most people run chronyd on the firewall itself, to avoid all issues of UDP
|
|
||||||
packet forwarding and/or masquerading.
|
|
||||||
|
|
||||||
@subsection Do you have a non-permanent (i.e. intermittent) Internet connection?
|
@subsection Do you have a non-permanent (i.e. intermittent) Internet connection?
|
||||||
Check that you're using chronyc's @code{online} and @code{offline} commands
|
Check that you're using chronyc's @code{online} and @code{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
|
||||||
|
@ -4622,21 +4641,21 @@ will arise. You should always make X quite high (e.g. 10) in this directive.
|
||||||
@section Issues with chronyc
|
@section Issues with chronyc
|
||||||
|
|
||||||
@subsection I keep getting the error @code{506 Cannot talk to daemon}
|
@subsection I keep getting the error @code{506 Cannot talk to daemon}
|
||||||
Make sure that the @file{chrony.conf} file (on the computer where chronyd is
|
Make sure that the @file{chrony.conf} file (on the computer where
|
||||||
running) has a @code{cmdallow} entry for the computer you are running chronyc
|
@code{chronyd} is running) has a @code{cmdallow} entry for the computer you are
|
||||||
on. This isn't necessary for localhost.
|
running @code{chronyc} on. This isn't necessary for localhost.
|
||||||
|
|
||||||
Perhaps chronyd is not running. Try using the ps command (e.g. on Linux, 'ps
|
Perhaps @code{chronyd} is not running. Try using the ps command (e.g. on
|
||||||
-auxw') to see if it's running. Or try 'netstat -a' and see if the ports
|
Linux, 'ps -auxw') to see if it's running. Or try 'netstat -a' and see if the
|
||||||
123/udp and 323/udp are listening. If @code{chronyd} is not running, you may
|
ports 123/udp and 323/udp are listening. If @code{chronyd} is not running, you
|
||||||
have a problem with the way you are trying to start it (e.g. at boot time).
|
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
|
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.
|
||||||
|
|
||||||
@subsection Is the chronyc<->chronyd protocol documented anywhere?
|
@subsection Is the chronyc<->chronyd protocol documented anywhere?
|
||||||
Only by the source code :-) See cmdmon.c (chronyd side) and client.c (chronyc
|
Only by the source code :-) See cmdmon.c (@code{chronyd} side) and client.c
|
||||||
side).
|
(@code{chronyc} side).
|
||||||
@c }}}
|
@c }}}
|
||||||
@c {{{ S:Real-time clock issues
|
@c {{{ S:Real-time clock issues
|
||||||
@node Real-time clock issues
|
@node Real-time clock issues
|
||||||
|
@ -4653,13 +4672,13 @@ details.
|
||||||
The hwclock program is often set-up by default in the boot and shutdown scripts
|
The hwclock program is often set-up by default in the boot and shutdown scripts
|
||||||
with many Linux installations. If you want to use chronyd's real-time clock
|
with many Linux installations. If you want to use chronyd's real-time clock
|
||||||
support, the important thing is to disable hwclock in the shutdown procedure.
|
support, the important thing is to disable hwclock in the shutdown procedure.
|
||||||
If you don't, it will over-write the RTC with a new value, unknown to chronyd.
|
If you don't, it will over-write the RTC with a new value, unknown to
|
||||||
At the next reboot, chronyd will compensate this (wrong) time with its estimate
|
@code{chronyd}. At the next reboot, @code{chronyd} will compensate this (wrong)
|
||||||
of how far the RTC has drifted whilst the power was off, giving a meaningless
|
time with its estimate of how far the RTC has drifted whilst the power was off,
|
||||||
initial system time.
|
giving a meaningless initial system time.
|
||||||
|
|
||||||
There is no need to remove hwclock from the boot process, as long as chronyd is
|
There is no need to remove hwclock from the boot process, as long as
|
||||||
started after it has run.
|
@code{chronyd} is started after it has run.
|
||||||
|
|
||||||
@subsection I just keep getting the '513 RTC driver not running' message
|
@subsection 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
|
For the real time clock support to work, you need the following three things
|
||||||
|
@ -4674,50 +4693,34 @@ For the real time clock support to work, you need the following three things
|
||||||
@section Microsoft Windows
|
@section Microsoft Windows
|
||||||
|
|
||||||
@subsection Does chrony support Windows?
|
@subsection Does chrony support Windows?
|
||||||
No. The chronyc program (the command-line client used for configuring
|
No. The @code{chronyc} program (the command-line client used for configuring
|
||||||
chronyd while it is running) has been successfully built and run under Cygwin
|
@code{chronyd} while it is running) has been successfully built and run under
|
||||||
in the past. chronyd is not portable, because part of it is very
|
Cygwin in the past. @code{chronyd} is not portable, because part of it is very
|
||||||
system-dependent. It needs adapting to work with Windows' equivalent of the
|
system-dependent. It needs adapting to work with Windows' equivalent of the
|
||||||
adjtimex() call, and it needs to be made to work as an NT service.
|
adjtimex() call, and it needs to be made to work as an NT service.
|
||||||
|
|
||||||
@subsection Are there any plans to support Windows?
|
@subsection 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.
|
||||||
|
|
||||||
@subsection What alternative NTP clients are there for Windows?
|
|
||||||
Some of the names we've seen mentioned are
|
|
||||||
@itemize @bullet
|
|
||||||
@item Automachron
|
|
||||||
@item NetTime (nettime.sourceforge.net)
|
|
||||||
@end itemize
|
|
||||||
@c }}}
|
@c }}}
|
||||||
@c {{{ S:NTP-specific issues
|
@c {{{ S:NTP-specific issues
|
||||||
@node NTP-specific issues
|
@node NTP-specific issues
|
||||||
@section NTP-specific issues
|
@section NTP-specific issues
|
||||||
|
|
||||||
@subsection Can chrony be driven from broadcast NTP servers?
|
@subsection Can chrony be driven from broadcast NTP servers?
|
||||||
No. I remember looking at how they worked when I was first writing chrony.
|
No, this NTP mode is not implemented yet.
|
||||||
Since the 'target market' then was dial-up systems, broadcast packets were not
|
|
||||||
relevant so I didn't bother working out how to deal with the complexities of
|
|
||||||
doing the delay estimation.
|
|
||||||
|
|
||||||
I no longer have root access to a LAN environment to develop and test broadcast
|
|
||||||
server support. Neither have I the time to work on this. I would be very
|
|
||||||
happy to accept a patch from anyone who can develop, test and debug the
|
|
||||||
necessary changes!
|
|
||||||
|
|
||||||
@subsection Can chronyd transmit broadcast NTP packets (e.g. to synchronise other computers on a private LAN)?
|
@subsection Can chronyd transmit broadcast NTP packets (e.g. to synchronise other computers on a private LAN)?
|
||||||
Yes. Starting from version 1.17, chrony has this capability.
|
Yes. Starting from version 1.17, chrony has this capability.
|
||||||
|
|
||||||
@subsection Can chrony keep the system clock a fixed offset away from real time?
|
@subsection Can chrony keep the system clock a fixed offset away from real time?
|
||||||
I have not experimented much, but I don't believe this would be possible as
|
This is not possible as the program currently stands.
|
||||||
the program currently stands.
|
|
||||||
|
|
||||||
@subsection What happens if the network connection is dropped without using chronyc's 'offline' command first?
|
@subsection What happens if the network connection is dropped without using chronyc's 'offline' command first?
|
||||||
In this case chronyd will keep trying to access the server(s) that it thinks
|
In this case @code{chronyd} will keep trying to access the server(s) that it
|
||||||
are online. Eventually it will decide that they are unreachable and no longer
|
thinks are online. Eventually it will decide that they are unreachable and no
|
||||||
consider itself synchronised to them. If you have other computers on your LAN
|
longer consider itself synchronised to them. If you have other computers on
|
||||||
accessing the computer that is affected this way, they too will become
|
your LAN accessing the computer that is affected this way, they too will become
|
||||||
'unsynchronised', unless you have the 'local' directive set up on the master
|
'unsynchronised', unless you have the 'local' directive set up on the master
|
||||||
computer.
|
computer.
|
||||||
|
|
||||||
|
@ -4728,17 +4731,8 @@ useful to avoid this situation.
|
||||||
@node Linux-specific issues
|
@node Linux-specific issues
|
||||||
@section Linux-specific issues
|
@section Linux-specific issues
|
||||||
|
|
||||||
@subsection Why does the source code include kernel header files?
|
|
||||||
The program needs to see the definitions of structures used to interact with
|
|
||||||
the real time clock (via /dev/rtc) and with the adjtimex() system call. Sadly
|
|
||||||
this has led to a number of compilation problems with newer kernels which have
|
|
||||||
been increasingly hard to fix in a way that makes the code compilable on all
|
|
||||||
Linux kernel versions. Hopefully
|
|
||||||
the situation will not deteriorate further with future kernel versions.
|
|
||||||
|
|
||||||
@subsection I get "Could not open /dev/rtc, Device or resource busy" in my syslog file
|
@subsection I get "Could not open /dev/rtc, Device or resource busy" in my syslog file
|
||||||
Check that you haven't accidentally got two copies of chronyd running (perhaps
|
Some other program running on the system may be using the device.
|
||||||
defined in different start-up scripts.)
|
|
||||||
@c }}}
|
@c }}}
|
||||||
@c {{{ S:Solaris-specific issues
|
@c {{{ S:Solaris-specific issues
|
||||||
@node Solaris-specific issues
|
@node Solaris-specific issues
|
||||||
|
@ -4748,10 +4742,9 @@ defined in different start-up scripts.)
|
||||||
(The dosynctodr variable controls whether Solaris couples the equivalent of its
|
(The dosynctodr variable controls whether Solaris couples the equivalent of its
|
||||||
BIOS clock into its system clock at regular intervals). The Solaris port of
|
BIOS clock into its system clock at regular intervals). The Solaris port of
|
||||||
chrony was developed in the Solaris 2.5 era. Some aspect of the Solaris kernel
|
chrony was developed in the Solaris 2.5 era. Some aspect of the Solaris kernel
|
||||||
has changed which prevents the same technique working. I no longer have root
|
has changed which prevents the same technique working. We no longer have root
|
||||||
access to any Solaris machines to work on this, and am reliant on somebody
|
access to any Solaris machines to work on this, and we are reliant on somebody
|
||||||
developing the patch and testing it. A good starting point would be to see if
|
developing the patch and testing it.
|
||||||
xntpd has been modified to work for Solaris 2.8.
|
|
||||||
@c }}}
|
@c }}}
|
||||||
@c }}}
|
@c }}}
|
||||||
@c {{{ apx:GNU General Public License
|
@c {{{ apx:GNU General Public License
|
||||||
|
|
Loading…
Reference in a new issue