This is a set of questions and answers to common problems and issues.

As we receive more emails about the software, we will add new questions to this page.


The developers can be reached via the chrony-dev mailing list. See question 1.4. for details.




1.1. Where can I get chrony source code?

Tarballs are available via the Download link on the Chrony
Web site.  For the current development from the developers' version control
system see the Git link on the Web site.

1.2. Are there any packaged versions of chrony?

We are aware of packages for Debian, Fedora, Gentoo, Mandriva, Slackware,
and Ubuntu.  We are not involved with how these are built or distributed.

1.3. Where is the home page?

It is currently at http://chrony.tuxfamily.org/. 

1.4. Is there a mailing list?

Yes, it's currently at chrony-users@chrony.tuxfamily.org. 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 with the subject subscribe to chrony-users-request@chrony.tuxfamily.org or
chrony-announce-request@chrony.tuxfamily.org respectively.

For those who want to contribute to the development of chrony, there is a
developers' mailing list.  You can subscribe by sending mail with the
subject subscribe to
chrony-dev-request@chrony.tuxfamily.org.

1.5. What licence is applied to chrony?

Starting from version 1.15, chrony is licensed under the GNU General Public
License, Version 2.  Versions prior to 1.15 were licensed under a custom BSD-like
license.


2.1. How does chrony compare to xntpd?

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.


3.1. How do I apply source patches?

Sometimes we release source patches rather than a full version when we 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

3.2. Can I compile chrony with an ANSI-C compiler that is not GCC v2.x?network with noi>4.2.9 commandkey

  • 4.2.10 cmdport
  • 4.2.11 deny
  • 4.2.12 driftfile
  • 4.2.13 dumpdir
  • 4.2.14 dumponexit
  • 4.2.15 initstepslew
  • 4.2.16 keyfile
  • 4.2.17 local
  • 4.2.18 linux_hz
  • 4.2.19 linux_freq_scale
  • 4.2.20 log
  • 4.2.21 logchange
  • 4.2.22 logdir
  • 4.2.23 mailonchange
  • 4.2.24 makestep
  • 4.2.25 manual
  • 4.2.26 maxupdateskew
  • 4.2.27 noclientlog
  • 4.2.28 clientloglimit
  • 4.2.29 peer
  • 4.2.30 pidfile
  • 4.2.31 port
  • 4.2.32 refclock
  • 4.2.33 rtcdevice
  • 4.2.34 rtcfile
  • 4.2.35 rtconutc
  • 4.2.36 sched_priority
  • 4.2.37 lock_all
  • 4.2.38 server
  • 4.3 Running chronyc
  • Appendix A Porting guide
  • Appendix B GNU General Public License
  • ./usr/share/doc/chrony/faq.html0000644000000000000000000006264413024024310015331 0ustar rootroot Frequently asked questions

    This is a set of questions and answers to common problems and issues.

    As we receive more emails about the software, we will add new questions to this page.


    The developers can be reached via the chrony-dev mailing list. See question 1.4. for details.




    1.1. Where can I get chrony source code?

    Tarballs are available via the Download link on the Chrony
    Web site.  For the current development from the developers' version control
    system see the Git link on the Web site.
    
    

    1.2. Are there any packaged versions of chrony?

    We are aware of packages for Debian, Fedora, Gentoo, Mandriva, Slackware,
    and Ubuntu.  We are not involved with how these are built or distributed.
    
    

    1.3. Where is the home page?

    It is currently at http://chrony.tuxfamily.org/. 
    
    

    1.4. Is there a mailing list?

    Yes, it's currently at chrony-users@chrony.tuxfamily.org. 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 with the subject subscribe to chrony-users-request@chrony.tuxfamily.org or
    chrony-announce-request@chrony.tuxfamily.org respectively.
    
    For those who want to contribute to the development of chrony, there is a
    developers' mailing list.  You can subscribe by sending mail with the
    subject subscribe to
    chrony-dev-request@chrony.tuxfamily.org.
    
    

    1.5. What licence is applied to chrony?

    Starting from version 1.15, chrony is licensed under the GNU General Public
    License, Version 2.  Versions prior to 1.15 were licensed under a custom BSD-like
    license.
    
    

    2.1. How does chrony compare to xntpd?

    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 aut