This is a set of questions and answers to common problems and issues.
As I receive more emails about the software, I will add new questions to this page.
The author can be reached by email
PLEASE include the word "chrony" in your subject line if possible (so that my mail reader can keep my mail sorted by topic)!
1.1. Where can I get chrony source code?
1.2. Are there any packaged versions of chrony?
1.3. Where is the home page?
1.4. Is there a mailing list?
1.5. What licence is applied to chrony?
2.1. How does chrony compare to xntpd?
3.1. How do I apply source patches?
3.2. Can I compile chrony with an ANSI-C compiler that is not GCC v2.x?
3.3. I get errors like 'client.c:44: readline/readline.h: file not found'
3.4. I have RedHat 7.3 and can't compile rtc_linux.c (error in spinlock.h)
4.1. I have several computers on a LAN. Should I make one the master, or make them all clients of an external server?
Via the home page, see below.
I am aware of packages for Debian, Mandrake and Redhat. I am not personally
involved with how these are built or distributed.
It is currently at http://chrony.sunsite.dk/.
Yes, it's currently at chrony-users@sunsite.dk. There is a low-volume
list called chrony-announce which is just for announcements of new releases or
similar matters of high importance. You can join the lists by sending a
message to chrony-users-subscribe@sunsite.dk or
chrony-announce-subscribe@sunsite.dk respectively.
For those who want to contribute to the development of chrony, there is a
developers' mailing list. You can subscribe by sending mail to
chrony-dev-subscribe@sunsite.dk.
Starting from version 1.15, chrony is licensed under the GNU General Public
License. Versions prior to 1.15 were licensed under a custom BSD-like
license.
If you want to use parts of chrony in non-free software, you will need to use
older versions of the source code. Alternatively, contact me - I may be
prepared to licence parts of the source code to suit your purposes. I am quite
sympathetic to projects licensed under other free/open-source (but non-GPL)
licences, as well as to commercial projects which are of a single-customer
"turnkey" nature (as opposed to mass-market "shrink-wrap" or "floating-licence"
products).
If your computer is permenently connected, or connected for long periods (that
is, for the several hours it takes xntpd to settle down), or you need to
support hardware reference clocks to your computer, then xntpd will work fine.
Apart from not supporting hardware clocks, chrony will work fine too.
If your computer connects to the 'net for 5 minutes once a day (or something
like that), or you turn your (Linux v2.0) computer off when you're not using
it, or you want to use NTP on an isolated network with no hardware clocks in
sight, chrony will work much better for you.
The reason I wrote chrony was that I could not get xntpd to do
anything sensible on my PC at home, which is connected to the 'net for
about 5 minutes once or twice a day, mainly to upload/download email
and news. Nowadays it is also turned off for 22-23 hours a day, when
not in use. I wanted a program which would :
- slew the time to correct it when I go 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. (In the last few months, it became impossible for
me to leave my computer powered permanently.)
Also, when working with isolated networks with no true time references
at all, I found xntpd gave me no help with managing the local clock's
gain/loss rate on the NTP master node (which I set from my watch). I
added some automated support in chrony to deal with this.
Sometimes I release source patches rather than a full version when I need to
provide a fix for small problems. Supposing you have chrony-1.X.tar.gz and a
source patch chrony-1.X-1.X.1.gz. The steps required are:
tar xzvf ../chrony-1.X.tar.gz
cd chrony-1.X
gunzip < ../../chrony-1.X-1.X.1.gz | patch -p1
./configure
make
make install
I have had reports that chrony can be compiled with GCC v1.42, by using the
following trick when running make
make CC='gcc -D__FUNCTION__=\"function_not_available\"'
(this gets around the lack of a __FUNCTION__ macro in GCC v1.)
The same trick may be enough to allow other compilers to be used.
Read the section about 'readline' in the INSTALL file or in chrony.txt. You
may need to disable readline support (e.g. if you haven't got readline
installed at all, or just don't want it), or specify the location of the
readline files (e.g. if you've installed them in a non-standard place).
The following solution has been found for this. Enter the following 3 commands
(as root):
cd /usr/include/
mv linux linux.rh
ln -s /usr/src/linux/include/linux ./linux
The problem seems to be that RedHat provide their own kernel header files in
/usr/include/linux. Besides differing from those used by your current kernel,
if you compiled it yourself, they also seem to have been changed in a way that
causes a problem compiling chrony. Chrony compiles fine with standard kernel
header files.
There have also been reports that just replacing the file
/usr/src/linux/spinlock.h by the equivalent file from a vanilla kernel source
tree is sufficient to fix the problem.
Note : from version 1.21 onwards, this problem no longer exists. The kernel
header files are no longer included.
I think the best configuration is 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.