--- chrony-1.21z.orig/Makefile.in +++ chrony-1.21z/Makefile.in @@ -96,23 +96,23 @@ [ -d $(DESTDIR)$(INSTALL_PREFIX) ] || mkdir -p $(DESTDIR)$(INSTALL_PREFIX) [ -d $(DESTDIR)$(INSTALL_PREFIX)/sbin ] || mkdir -p $(DESTDIR)$(INSTALL_PREFIX)/sbin [ -d $(DESTDIR)$(INSTALL_PREFIX)/bin ] || mkdir -p $(DESTDIR)$(INSTALL_PREFIX)/bin - [ -d $(DESTDIR)$(INSTALL_PREFIX)/doc ] || mkdir -p $(DESTDIR)$(INSTALL_PREFIX)/doc + [ -d $(DESTDIR)$(INSTALL_PREFIX)/share/doc ] || mkdir -p $(DESTDIR)$(INSTALL_PREFIX)/share/doc [ -d $(DESTDIR)$(MANDIR)/man1 ] || mkdir -p $(DESTDIR)$(MANDIR)/man1 [ -d $(DESTDIR)$(MANDIR)/man5 ] || mkdir -p $(DESTDIR)$(MANDIR)/man5 [ -d $(DESTDIR)$(MANDIR)/man8 ] || mkdir -p $(DESTDIR)$(MANDIR)/man8 - [ -d $(DESTDIR)$(INSTALL_PREFIX)/doc/chrony ] || mkdir -p $(DESTDIR)$(INSTALL_PREFIX)/doc/chrony + [ -d $(DESTDIR)$(INSTALL_PREFIX)/share/doc/chrony ] || mkdir -p $(DESTDIR)$(INSTALL_PREFIX)/share/doc/chrony if [ -f $(DESTDIR)$(INSTALL_PREFIX)/sbin/chronyd ]; then rm -f $(DESTDIR)$(INSTALL_PREFIX)/sbin/chronyd ; fi if [ -f $(DESTDIR)$(INSTALL_PREFIX)/bin/chronyc ]; then rm -f $(DESTDIR)$(INSTALL_PREFIX)/bin/chronyc ; fi cp chronyd $(DESTDIR)$(INSTALL_PREFIX)/sbin/chronyd chmod 555 $(DESTDIR)$(INSTALL_PREFIX)/sbin/chronyd cp chronyc $(DESTDIR)$(INSTALL_PREFIX)/bin/chronyc chmod 555 $(DESTDIR)$(INSTALL_PREFIX)/bin/chronyc - cp chrony.txt $(DESTDIR)$(INSTALL_PREFIX)/doc/chrony/chrony.txt - chmod 444 $(DESTDIR)$(INSTALL_PREFIX)/doc/chrony/chrony.txt - cp COPYING $(DESTDIR)$(INSTALL_PREFIX)/doc/chrony/COPYING - chmod 444 $(DESTDIR)$(INSTALL_PREFIX)/doc/chrony/COPYING - cp README $(DESTDIR)$(INSTALL_PREFIX)/doc/chrony/README - chmod 444 $(DESTDIR)$(INSTALL_PREFIX)/doc/chrony/README + cp chrony.txt $(DESTDIR)$(INSTALL_PREFIX)/share/doc/chrony/chrony.txt + chmod 444 $(DESTDIR)$(INSTALL_PREFIX)/share/doc/chrony/chrony.txt + cp COPYING $(DESTDIR)$(INSTALL_PREFIX)/share/doc/chrony/COPYING + chmod 444 $(DESTDIR)$(INSTALL_PREFIX)/share/doc/chrony/COPYING + cp README $(DESTDIR)$(INSTALL_PREFIX)/share/doc/chrony/README + chmod 444 $(DESTDIR)$(INSTALL_PREFIX)/share/doc/chrony/README cp chrony.1 $(DESTDIR)$(MANDIR)/man1 chmod 444 $(DESTDIR)$(MANDIR)/man1/chrony.1 cp chronyc.1 $(DESTDIR)$(MANDIR)/man1 @@ -134,13 +134,13 @@ MAKEINFO:=makeinfo install-docs : docs - [ -d $(DESTDIR)$(INSTALL_PREFIX)/doc ] || mkdir -p $(DESTDIR)$(INSTALL_PREFIX)/doc - cp chrony.txt $(DESTDIR)$(INSTALL_PREFIX)/doc/chrony/chrony.txt - chown root $(DESTDIR)$(INSTALL_PREFIX)/doc/chrony/chrony.txt - chmod 444 $(DESTDIR)$(INSTALL_PREFIX)/doc/chrony/chrony.txt - cp chrony.html $(DESTDIR)$(INSTALL_PREFIX)/doc/chrony/chrony.html - chown root $(DESTDIR)$(INSTALL_PREFIX)/doc/chrony/chrony.html - chmod 444 $(DESTDIR)$(INSTALL_PREFIX)/doc/chrony/chrony.html + [ -d $(DESTDIR)$(INSTALL_PREFIX)/share/doc ] || mkdir -p $(DESTDIR)$(INSTALL_PREFIX)/share/doc + cp chrony.txt $(DESTDIR)$(INSTALL_PREFIX)/share/doc/chrony/chrony.txt + chown root $(DESTDIR)$(INSTALL_PREFIX)/share/doc/chrony/chrony.txt + chmod 444 $(DESTDIR)$(INSTALL_PREFIX)/share/doc/chrony/chrony.txt + cp chrony.html $(DESTDIR)$(INSTALL_PREFIX)/share/doc/chrony/chrony.html + chown root $(DESTDIR)$(INSTALL_PREFIX)/share/doc/chrony/chrony.html + chmod 444 $(DESTDIR)$(INSTALL_PREFIX)/share/doc/chrony/chrony.html [ -d $(DESTDIR)$(INFODIR) ] || mkdir -p $(DESTDIR)$(INFODIR) cp chrony.info* $(DESTDIR)$(INFODIR) chown root $(DESTDIR)$(INFODIR)/chrony.info* @@ -156,8 +156,3 @@ chrony.info : chrony.texi $(MAKEINFO) chrony.texi - -# This is only relevant if you're maintaining the website! -faq.php : faq.txt faqgen.pl - perl faqgen.pl < faq.txt > faq.php - --- chrony-1.21z.orig/addrfilt.c +++ chrony-1.21z/addrfilt.c @@ -43,17 +43,15 @@ /* Define the table size */ #define TABLE_SIZE (1UL<extended != NULL) { for (i=0; iextended))[i]); + child_node = node->extended + i; close_node(child_node); } Free(node->extended); @@ -124,10 +122,11 @@ if (node->extended == NULL) { - node->extended = MallocNew(ExtendedTable); + + node->extended = (TableNode *) MallocArray(ExtendedTable, TABLE_SIZE); for (i=0; iextended))[i]); + child_node = node->extended + i; child_node->state = AS_PARENT; child_node->extended = NULL; } @@ -168,7 +167,7 @@ if (!(node->extended)) { open_node(node); } - node = &((*(node->extended))[subnet]); + node = node->extended + subnet; bits_to_go -= NBITS; } @@ -187,7 +186,7 @@ if (!(node->extended)) { open_node(node); } - node = &((*(node->extended))[subnet]); + node = node->extended + subnet; bits_to_go -= NBITS; } @@ -199,7 +198,7 @@ } for (i=subnet, j=0; jextended))[i]); + this_node = node->extended + i; if (delete_children) { close_node(this_node); } @@ -283,7 +282,7 @@ if (node->extended) { subnet = get_subnet(residual); residual = get_residual(residual); - node = &((*(node->extended))[subnet]); + node = node->extended + subnet; } else { /* Make decision on this node */ finished = 1; --- chrony-1.21z.orig/chrony.conf.5 +++ chrony-1.21z/chrony.conf.5 @@ -29,9 +29,9 @@ server a.b.c server d.e.f server g.h.i - keyfile /etc/chrony.keys + keyfile /etc/chrony/chrony.keys commandkey 1 - driftfile /etc/chrony.drift + driftfile /etc/chrony/chrony.drift .SH "SEE ALSO" --- chrony-1.21z.orig/chrony.texi +++ chrony-1.21z/chrony.texi @@ -448,8 +448,10 @@ Now that the software is successfully installed, the next step is to set up a configuration file. The contents of this depend on the -network environment in which the computer operates. Typical scenarios -are described in the following section of the document. +network environment in which the computer operates. The Debian +package installs a simple configuration file suitable for a dial-up +pc. You should edit it to suit your situation. Typical scenarios are +described in the following section of the document. @c }}} @menu * readline support:: If readline or ncurses in in a non-standard place @@ -567,8 +569,9 @@ Assuming that you have found some servers, you need to set up a configuration file to run chrony. The (compiled-in) default location -for this file is @file{/etc/chrony.conf}. Assuming that your ntp -servers are called @code{a.b.c} and @code{d.e.f}, your +for this file is @file{/etc/chrony.conf}. In the Debian package the +configuration files are in the directory @file{/etc/chrony}. Assuming +that your ntp servers are called @code{a.b.c} and @code{d.e.f}, your @file{chrony.conf} file could contain as a minimum @example @@ -654,9 +657,11 @@ comes before @samp{dns} in the @samp{hosts} line of the @file{/etc/nsswitch.conf} file. -In order to notify @code{chronyd} of the presence of the link, you will need to -be able to log in to it with the program chronyc. To do this, @code{chronyd} -needs to be configured with an administrator password. To set up an +In order to notify @code{chronyd} of the presence of the link, you +will need to be able to log in to it with the program chronyc. To do +this, @code{chronyd} needs to be configured with an administrator +password. The Debian package puts a randomly generated key in +@file{/etc/chrony/chrony.keys}. You should change it. To set up an administrator password, you can create a file @file{/etc/chrony.keys} containing a single line @@ -717,6 +722,9 @@ EOF @end example +The Debian package puts scripts similar to those above in the +directories @file{/etc/ppp/ip-up.d} and @file{/etc/ppp/ip-down.d}. + @code{chronyd's} polling of the servers will now only occur whilst the machine is actually connected to the Internet. @c }}} @@ -965,6 +973,9 @@ fi @end example +The Debian package puts a script which handles this and shutdown in +@file{/etc/init.d/chrony}. + The placement of this command may be important on some systems. In particular, @code{chronyd} may need to be started several seconds (about 10 as a minimum) before any software that depends on the system clock @@ -1044,6 +1055,8 @@ /usr/local/sbin/chronyd @end example +The Debian package uses @file{/usr/sbin/chronyd}. + Information messages and warnings will be logged to syslog. The command line options supported are as follows: --- chrony-1.21z.orig/chronyc.1 +++ chrony-1.21z/chronyc.1 @@ -31,7 +31,8 @@ .TP \fB\-n\fR display raw IP addresses (don't attempt to look up hostnames) -.TP \fIcommand\fR +.TP +\fIcommand\fR specify command. If no command is given, chronyc will read commands interactively. @@ -43,7 +44,7 @@ To report bugs, please contact the author and/or visit \fIhttp://go.to/chrony\fR .SH "SEE ALSO" -.BR chronyd(1), +.BR chronyd(8), .BR chrony(1) .I http://chrony.sunsite.dk/ --- chrony-1.21z.orig/chronyd.8 +++ chrony-1.21z/chronyd.8 @@ -43,7 +43,7 @@ .TP \fB\-f\fR \fIconf-file\fR This option can be used to specify an alternate location for the -configuration file (default \fI/etc/chrony.conf\fR). +configuration file (default \fI/etc/chrony/chrony.conf\fR). .TP .B \-r This option will reload sample histories for each of the servers being used. @@ -83,7 +83,7 @@ This option displays \fBchronyd\fR's version number to the terminal and exits .SH FILES -\fI/etc/chrony.conf\fR +\fI/etc/chrony/chrony.conf\fR .SH VERSION Version 1.17 @@ -96,7 +96,7 @@ distribution (\fIchrony.txt\fR and \fIchrony.texi\fR) and is also available from \fIhttp://go.to/chrony\fR -.BR chrony(1), +.BR chrony(8), .BR chronyc(1), .BR chrony.conf(5), .BR clock(8), --- chrony-1.21z.orig/client.c +++ chrony-1.21z/client.c @@ -1383,10 +1383,10 @@ int n_sources, i; int verbose = 0; - long orig_latest_meas, latest_meas, est_offset; + int32_t orig_latest_meas, latest_meas, est_offset; /* Was long JGH */ unsigned long ip_addr; - unsigned long latest_meas_err, est_offset_err; - unsigned long latest_meas_ago; + uint32_t latest_meas_err, est_offset_err; /* Was unsigned long JGH */ + uint32_t latest_meas_ago; /* Was unsigned long JGH */ unsigned short poll, stratum; unsigned short state, mode; double resid_freq, resid_skew; @@ -1485,14 +1485,14 @@ } printf(" %-25s %2d %2d ", hostname_buf, stratum, poll); - print_seconds(latest_meas_ago); + print_seconds((unsigned long)latest_meas_ago); /* Added cast JGH */ printf(" "); - print_signed_microseconds(latest_meas); + print_signed_microseconds((long)latest_meas); /* Added cast JGH */ printf("["); - print_signed_microseconds(orig_latest_meas); + print_signed_microseconds((long)orig_latest_meas); /* Added cast JGH */ printf("]"); printf(" +/- "); - print_microseconds(latest_meas_err); + print_microseconds((unsigned long)latest_meas_err); /* Added cast JGH */ printf("\n"); } } --- chrony-1.21z.orig/conf.c +++ chrony-1.21z/conf.c @@ -55,7 +55,7 @@ /* ================================================== */ -#define DEFAULT_CONF_FILE "/etc/chrony.conf" +#define DEFAULT_CONF_FILE "/etc/chrony/chrony.conf" /* ================================================== */ /* Forward prototypes */ --- chrony-1.21z.orig/getdate.c +++ chrony-1.21z/getdate.c @@ -1,27 +1,97 @@ +/* A Bison parser, made by GNU Bison 2.0. */ -/* A Bison parser, made from getdate.y - by GNU Bison version 1.25 - */ - -#define YYBISON 1 /* Identify Bison output. */ - -#define tAGO 258 -#define tDAY 259 -#define tDAY_UNIT 260 -#define tDAYZONE 261 -#define tDST 262 -#define tHOUR_UNIT 263 -#define tID 264 -#define tMERIDIAN 265 -#define tMINUTE_UNIT 266 -#define tMONTH 267 -#define tMONTH_UNIT 268 -#define tSEC_UNIT 269 -#define tSNUMBER 270 -#define tUNUMBER 271 -#define tYEAR_UNIT 272 -#define tZONE 273 +/* Skeleton parser for Yacc-like parsing with Bison, + Copyright (C) 1984, 1989, 1990, 2000, 2001, 2002, 2003, 2004 Free Software Foundation, Inc. + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2, or (at your option) + any later version. + + 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., 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + +/* As a special exception, when this file is copied by Bison into a + Bison output file, you may use that output file without restriction. + This special exception was added by the Free Software Foundation + in version 1.24 of Bison. */ + +/* Written by Richard Stallman by simplifying the original so called + ``semantic'' parser. */ + +/* All symbols defined below should begin with yy or YY, to avoid + infringing on user name space. This should be done even for local + variables, as they might otherwise be expanded by user macros. + There are some unavoidable exceptions within include files to + define necessary library symbols; they are noted "INFRINGES ON + USER NAME SPACE" below. */ + +/* Identify Bison output. */ +#define YYBISON 1 + +/* Skeleton name. */ +#define YYSKELETON_NAME "yacc.c" + +/* Pure parsers. */ +#define YYPURE 0 + +/* Using locations. */ +#define YYLSP_NEEDED 0 + + + +/* Tokens. */ +#ifndef YYTOKENTYPE +# define YYTOKENTYPE + /* Put the tokens into the symbol table, so that GDB and other debuggers + know about them. */ + enum yytokentype { + tAGO = 258, + tDAY = 259, + tDAY_UNIT = 260, + tDAYZONE = 261, + tDST = 262, + tHOUR_UNIT = 263, + tID = 264, + tMERIDIAN = 265, + tMINUTE_UNIT = 266, + tMONTH = 267, + tMONTH_UNIT = 268, + tSEC_UNIT = 269, + tSNUMBER = 270, + tUNUMBER = 271, + tYEAR_UNIT = 272, + tZONE = 273 + }; +#endif +#define tAGO 258 +#define tDAY 259 +#define tDAY_UNIT 260 +#define tDAYZONE 261 +#define tDST 262 +#define tHOUR_UNIT 263 +#define tID 264 +#define tMERIDIAN 265 +#define tMINUTE_UNIT 266 +#define tMONTH 267 +#define tMONTH_UNIT 268 +#define tSEC_UNIT 269 +#define tSNUMBER 270 +#define tUNUMBER 271 +#define tYEAR_UNIT 272 +#define tZONE 273 + + + + +/* Copy the first part of user declarations. */ #line 1 "getdate.y" /* @@ -196,446 +266,799 @@ static int yyRelYear; + +/* Enabling traces. */ +#ifndef YYDEBUG +# define YYDEBUG 0 +#endif + +/* Enabling verbose error messages. */ +#ifdef YYERROR_VERBOSE +# undef YYERROR_VERBOSE +# define YYERROR_VERBOSE 1 +#else +# define YYERROR_VERBOSE 0 +#endif + +#if ! defined (YYSTYPE) && ! defined (YYSTYPE_IS_DECLARED) #line 175 "getdate.y" -typedef union { +typedef union YYSTYPE { int Number; enum _MERIDIAN Meridian; } YYSTYPE; -#include - -#ifndef __cplusplus -#ifndef __STDC__ -#define const -#endif +/* Line 190 of yacc.c. */ +#line 291 "y.tab.c" +# define yystype YYSTYPE /* obsolescent; will be withdrawn */ +# define YYSTYPE_IS_DECLARED 1 +# define YYSTYPE_IS_TRIVIAL 1 #endif -#define YYFINAL 61 -#define YYFLAG -32768 -#define YYNTBASE 22 - -#define YYTRANSLATE(x) ((unsigned)(x) <= 273 ? yytranslate[x] : 32) - -static const char yytranslate[] = { 0, - 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, - 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, - 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, - 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, - 2, 2, 2, 20, 2, 2, 21, 2, 2, 2, - 2, 2, 2, 2, 2, 2, 2, 19, 2, 2, - 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, - 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, - 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, - 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, - 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, - 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, - 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, - 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, - 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, - 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, - 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, - 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, - 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, - 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, - 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, - 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, - 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, - 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, - 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, - 2, 2, 2, 2, 2, 1, 2, 3, 4, 5, - 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, - 16, 17, 18 -}; +/* Copy the second part of user declarations. */ -#if YYDEBUG != 0 -static const short yyprhs[] = { 0, - 0, 1, 4, 6, 8, 10, 12, 14, 16, 19, - 24, 29, 36, 43, 45, 47, 50, 52, 55, 58, - 62, 68, 72, 76, 79, 84, 87, 91, 94, 96, - 99, 102, 104, 107, 110, 112, 115, 118, 120, 123, - 126, 128, 131, 134, 136, 139, 142, 144, 146, 147 -}; -static const short yyrhs[] = { -1, - 22, 23, 0, 24, 0, 25, 0, 27, 0, 26, - 0, 28, 0, 30, 0, 16, 10, 0, 16, 19, - 16, 31, 0, 16, 19, 16, 15, 0, 16, 19, - 16, 19, 16, 31, 0, 16, 19, 16, 19, 16, - 15, 0, 18, 0, 6, 0, 18, 7, 0, 4, - 0, 4, 20, 0, 16, 4, 0, 16, 21, 16, - 0, 16, 21, 16, 21, 16, 0, 16, 15, 15, - 0, 16, 12, 15, 0, 12, 16, 0, 12, 16, - 20, 16, 0, 16, 12, 0, 16, 12, 16, 0, - 29, 3, 0, 29, 0, 16, 17, 0, 15, 17, - 0, 17, 0, 16, 13, 0, 15, 13, 0, 13, - 0, 16, 5, 0, 15, 5, 0, 5, 0, 16, - 8, 0, 15, 8, 0, 8, 0, 16, 11, 0, - 15, 11, 0, 11, 0, 16, 14, 0, 15, 14, - 0, 14, 0, 16, 0, 0, 10, 0 -}; +/* Line 213 of yacc.c. */ +#line 303 "y.tab.c" -#endif +#if ! defined (yyoverflow) || YYERROR_VERBOSE -#if YYDEBUG != 0 -static const short yyrline[] = { 0, - 191, 192, 195, 198, 201, 204, 207, 210, 213, 219, - 225, 234, 240, 252, 255, 258, 264, 268, 272, 278, - 282, 300, 306, 312, 316, 321, 325, 332, 340, 343, - 346, 349, 352, 355, 358, 361, 364, 367, 370, 373, - 376, 379, 382, 385, 388, 391, 394, 399, 432, 436 -}; -#endif +# ifndef YYFREE +# define YYFREE free +# endif +# ifndef YYMALLOC +# define YYMALLOC malloc +# endif +/* The parser invokes alloca or malloc; define the necessary symbols. */ -#if YYDEBUG != 0 || defined (YYERROR_VERBOSE) +# ifdef YYSTACK_USE_ALLOCA +# if YYSTACK_USE_ALLOCA +# ifdef __GNUC__ +# define YYSTACK_ALLOC __builtin_alloca +# else +# define YYSTACK_ALLOC alloca +# endif +# endif +# endif + +# ifdef YYSTACK_ALLOC + /* Pacify GCC's `empty if-body' warning. */ +# define YYSTACK_FREE(Ptr) do { /* empty */; } while (0) +# else +# if defined (__STDC__) || defined (__cplusplus) +# include /* INFRINGES ON USER NAME SPACE */ +# define YYSIZE_T size_t +# endif +# define YYSTACK_ALLOC YYMALLOC +# define YYSTACK_FREE YYFREE +# endif +#endif /* ! defined (yyoverflow) || YYERROR_VERBOSE */ + + +#if (! defined (yyoverflow) \ + && (! defined (__cplusplus) \ + || (defined (YYSTYPE_IS_TRIVIAL) && YYSTYPE_IS_TRIVIAL))) + +/* A type that is properly aligned for any stack member. */ +union yyalloc +{ + short int yyss; + YYSTYPE yyvs; + }; + +/* The size of the maximum gap between one aligned stack and the next. */ +# define YYSTACK_GAP_MAXIMUM (sizeof (union yyalloc) - 1) + +/* The size of an array large to enough to hold all stacks, each with + N elements. */ +# define YYSTACK_BYTES(N) \ + ((N) * (sizeof (short int) + sizeof (YYSTYPE)) \ + + YYSTACK_GAP_MAXIMUM) + +/* Copy COUNT objects from FROM to TO. The source and destination do + not overlap. */ +# ifndef YYCOPY +# if defined (__GNUC__) && 1 < __GNUC__ +# define YYCOPY(To, From, Count) \ + __builtin_memcpy (To, From, (Count) * sizeof (*(From))) +# else +# define YYCOPY(To, From, Count) \ + do \ + { \ + register YYSIZE_T yyi; \ + for (yyi = 0; yyi < (Count); yyi++) \ + (To)[yyi] = (From)[yyi]; \ + } \ + while (0) +# endif +# endif + +/* Relocate STACK from its old location to the new one. The + local variables YYSIZE and YYSTACKSIZE give the old and new number of + elements in the stack, and YYPTR gives the new location of the + stack. Advance YYPTR to a properly aligned location for the next + stack. */ +# define YYSTACK_RELOCATE(Stack) \ + do \ + { \ + YYSIZE_T yynewbytes; \ + YYCOPY (&yyptr->Stack, Stack, yysize); \ + Stack = &yyptr->Stack; \ + yynewbytes = yystacksize * sizeof (*Stack) + YYSTACK_GAP_MAXIMUM; \ + yyptr += yynewbytes / sizeof (*yyptr); \ + } \ + while (0) -static const char * const yytname[] = { "$","error","$undefined.","tAGO","tDAY", -"tDAY_UNIT","tDAYZONE","tDST","tHOUR_UNIT","tID","tMERIDIAN","tMINUTE_UNIT", -"tMONTH","tMONTH_UNIT","tSEC_UNIT","tSNUMBER","tUNUMBER","tYEAR_UNIT","tZONE", -"':'","','","'/'","spec","item","time","zone","day","date","rel","relunit","number", -"o_merid", NULL -}; #endif -static const short yyr1[] = { 0, - 22, 22, 23, 23, 23, 23, 23, 23, 24, 24, - 24, 24, 24, 25, 25, 25, 26, 26, 26, 27, - 27, 27, 27, 27, 27, 27, 27, 28, 28, 29, - 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, - 29, 29, 29, 29, 29, 29, 29, 30, 31, 31 -}; +#if defined (__STDC__) || defined (__cplusplus) + typedef signed char yysigned_char; +#else + typedef short int yysigned_char; +#endif -static const short yyr2[] = { 0, - 0, 2, 1, 1, 1, 1, 1, 1, 2, 4, - 4, 6, 6, 1, 1, 2, 1, 2, 2, 3, - 5, 3, 3, 2, 4, 2, 3, 2, 1, 2, - 2, 1, 2, 2, 1, 2, 2, 1, 2, 2, - 1, 2, 2, 1, 2, 2, 1, 1, 0, 1 +/* YYFINAL -- State number of the termination state. */ +#define YYFINAL 2 +/* YYLAST -- Last index in YYTABLE. */ +#define YYLAST 50 + +/* YYNTOKENS -- Number of terminals. */ +#define YYNTOKENS 22 +/* YYNNTS -- Number of nonterminals. */ +#define YYNNTS 11 +/* YYNRULES -- Number of rules. */ +#define YYNRULES 51 +/* YYNRULES -- Number of states. */ +#define YYNSTATES 61 + +/* YYTRANSLATE(YYLEX) -- Bison symbol number corresponding to YYLEX. */ +#define YYUNDEFTOK 2 +#define YYMAXUTOK 273 + +#define YYTRANSLATE(YYX) \ + ((unsigned int) (YYX) <= YYMAXUTOK ? yytranslate[YYX] : YYUNDEFTOK) + +/* YYTRANSLATE[YYLEX] -- Bison symbol number corresponding to YYLEX. */ +static const unsigned char yytranslate[] = +{ + 0, 2, 2, 2, 2, 2, 2, 2, 2, 2, + 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, + 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, + 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, + 2, 2, 2, 2, 20, 2, 2, 21, 2, 2, + 2, 2, 2, 2, 2, 2, 2, 2, 19, 2, + 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, + 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, + 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, + 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, + 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, + 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, + 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, + 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, + 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, + 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, + 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, + 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, + 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, + 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, + 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, + 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, + 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, + 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, + 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, + 2, 2, 2, 2, 2, 2, 1, 2, 3, 4, + 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, + 15, 16, 17, 18 }; -static const short yydefact[] = { 1, - 0, 17, 38, 15, 41, 44, 0, 35, 47, 0, - 48, 32, 14, 2, 3, 4, 6, 5, 7, 29, - 8, 18, 24, 37, 40, 43, 34, 46, 31, 19, - 36, 39, 9, 42, 26, 33, 45, 0, 30, 0, - 0, 16, 28, 0, 23, 27, 22, 49, 20, 25, - 50, 11, 0, 10, 0, 49, 21, 13, 12, 0, - 0 +#if YYDEBUG +/* YYPRHS[YYN] -- Index of the first RHS symbol of rule number YYN in + YYRHS. */ +static const unsigned char yyprhs[] = +{ + 0, 0, 3, 4, 7, 9, 11, 13, 15, 17, + 19, 22, 27, 32, 39, 46, 48, 50, 53, 55, + 58, 61, 65, 71, 75, 79, 82, 87, 90, 94, + 97, 99, 102, 105, 107, 110, 113, 115, 118, 121, + 123, 126, 129, 131, 134, 137, 139, 142, 145, 147, + 149, 150 }; -static const short yydefgoto[] = { 1, - 14, 15, 16, 17, 18, 19, 20, 21, 54 +/* YYRHS -- A `-1'-separated list of the rules' RHS. */ +static const yysigned_char yyrhs[] = +{ + 23, 0, -1, -1, 23, 24, -1, 25, -1, 26, + -1, 28, -1, 27, -1, 29, -1, 31, -1, 16, + 10, -1, 16, 19, 16, 32, -1, 16, 19, 16, + 15, -1, 16, 19, 16, 19, 16, 32, -1, 16, + 19, 16, 19, 16, 15, -1, 18, -1, 6, -1, + 18, 7, -1, 4, -1, 4, 20, -1, 16, 4, + -1, 16, 21, 16, -1, 16, 21, 16, 21, 16, + -1, 16, 15, 15, -1, 16, 12, 15, -1, 12, + 16, -1, 12, 16, 20, 16, -1, 16, 12, -1, + 16, 12, 16, -1, 30, 3, -1, 30, -1, 16, + 17, -1, 15, 17, -1, 17, -1, 16, 13, -1, + 15, 13, -1, 13, -1, 16, 5, -1, 15, 5, + -1, 5, -1, 16, 8, -1, 15, 8, -1, 8, + -1, 16, 11, -1, 15, 11, -1, 11, -1, 16, + 14, -1, 15, 14, -1, 14, -1, 16, -1, -1, + 10, -1 }; -static const short yypact[] = {-32768, - 0, -19,-32768,-32768,-32768,-32768, -13,-32768,-32768, 30, - 15,-32768, 14,-32768,-32768,-32768,-32768,-32768,-32768, 19, --32768,-32768, 4,-32768,-32768,-32768,-32768,-32768,-32768,-32768, --32768,-32768,-32768,-32768, -6,-32768,-32768, 16,-32768, 17, - 23,-32768,-32768, 24,-32768,-32768,-32768, 27, 28,-32768, --32768,-32768, 29,-32768, 32, -8,-32768,-32768,-32768, 50, --32768 +/* YYRLINE[YYN] -- source line where rule number YYN was defined. */ +static const unsigned short int yyrline[] = +{ + 0, 191, 191, 192, 195, 198, 201, 204, 207, 210, + 213, 219, 225, 234, 240, 252, 255, 259, 264, 268, + 272, 278, 282, 300, 306, 312, 316, 321, 325, 332, + 340, 343, 346, 349, 352, 355, 358, 361, 364, 367, + 370, 373, 376, 379, 382, 385, 388, 391, 394, 399, + 433, 436 }; +#endif -static const short yypgoto[] = {-32768, --32768,-32768,-32768,-32768,-32768,-32768,-32768,-32768, -5 +#if YYDEBUG || YYERROR_VERBOSE +/* YYTNME[SYMBOL-NUM] -- String name of the symbol SYMBOL-NUM. + First, the terminals, then, starting at YYNTOKENS, nonterminals. */ +static const char *const yytname[] = +{ + "$end", "error", "$undefined", "tAGO", "tDAY", "tDAY_UNIT", "tDAYZONE", + "tDST", "tHOUR_UNIT", "tID", "tMERIDIAN", "tMINUTE_UNIT", "tMONTH", + "tMONTH_UNIT", "tSEC_UNIT", "tSNUMBER", "tUNUMBER", "tYEAR_UNIT", + "tZONE", "':'", "','", "'/'", "$accept", "spec", "item", "time", "zone", + "day", "date", "rel", "relunit", "number", "o_merid", 0 }; +#endif +# ifdef YYPRINT +/* YYTOKNUM[YYLEX-NUM] -- Internal token number corresponding to + token YYLEX-NUM. */ +static const unsigned short int yytoknum[] = +{ + 0, 256, 257, 258, 259, 260, 261, 262, 263, 264, + 265, 266, 267, 268, 269, 270, 271, 272, 273, 58, + 44, 47 +}; +# endif -#define YYLAST 51 - +/* YYR1[YYN] -- Symbol number of symbol that rule YYN derives. */ +static const unsigned char yyr1[] = +{ + 0, 22, 23, 23, 24, 24, 24, 24, 24, 24, + 25, 25, 25, 25, 25, 26, 26, 26, 27, 27, + 27, 28, 28, 28, 28, 28, 28, 28, 28, 29, + 29, 30, 30, 30, 30, 30, 30, 30, 30, 30, + 30, 30, 30, 30, 30, 30, 30, 30, 30, 31, + 32, 32 +}; -static const short yytable[] = { 60, - 22, 51, 23, 2, 3, 4, 58, 5, 45, 46, - 6, 7, 8, 9, 10, 11, 12, 13, 30, 31, - 42, 43, 32, 44, 33, 34, 35, 36, 37, 38, - 47, 39, 48, 40, 24, 41, 51, 25, 49, 50, - 26, 52, 27, 28, 56, 53, 29, 57, 55, 61, - 59 +/* YYR2[YYN] -- Number of symbols composing right hand side of rule YYN. */ +static const unsigned char yyr2[] = +{ + 0, 2, 0, 2, 1, 1, 1, 1, 1, 1, + 2, 4, 4, 6, 6, 1, 1, 2, 1, 2, + 2, 3, 5, 3, 3, 2, 4, 2, 3, 2, + 1, 2, 2, 1, 2, 2, 1, 2, 2, 1, + 2, 2, 1, 2, 2, 1, 2, 2, 1, 1, + 0, 1 }; -static const short yycheck[] = { 0, - 20, 10, 16, 4, 5, 6, 15, 8, 15, 16, - 11, 12, 13, 14, 15, 16, 17, 18, 4, 5, - 7, 3, 8, 20, 10, 11, 12, 13, 14, 15, - 15, 17, 16, 19, 5, 21, 10, 8, 16, 16, - 11, 15, 13, 14, 16, 19, 17, 16, 21, 0, - 56 +/* YYDEFACT[STATE-NAME] -- Default rule to reduce with in state + STATE-NUM when YYTABLE doesn't specify something else to do. Zero + means the default is an error. */ +static const unsigned char yydefact[] = +{ + 2, 0, 1, 18, 39, 16, 42, 45, 0, 36, + 48, 0, 49, 33, 15, 3, 4, 5, 7, 6, + 8, 30, 9, 19, 25, 38, 41, 44, 35, 47, + 32, 20, 37, 40, 10, 43, 27, 34, 46, 0, + 31, 0, 0, 17, 29, 0, 24, 28, 23, 50, + 21, 26, 51, 12, 0, 11, 0, 50, 22, 14, + 13 }; -/* -*-C-*- Note some compilers choke on comments on `#line' lines. */ -#line 3 "/usr/local/share/bison.simple" -/* Skeleton output parser for bison, - Copyright (C) 1984, 1989, 1990 Free Software Foundation, Inc. +/* YYDEFGOTO[NTERM-NUM]. */ +static const yysigned_char yydefgoto[] = +{ + -1, 1, 15, 16, 17, 18, 19, 20, 21, 22, + 55 +}; - This program is free software; you can redistribute it and/or modify - it under the terms of the GNU General Public License as published by - the Free Software Foundation; either version 2, or (at your option) - any later version. +/* YYPACT[STATE-NUM] -- Index in YYTABLE of the portion describing + STATE-NUM. */ +#define YYPACT_NINF -20 +static const yysigned_char yypact[] = +{ + -20, 0, -20, -19, -20, -20, -20, -20, -13, -20, + -20, 30, 15, -20, 14, -20, -20, -20, -20, -20, + -20, 19, -20, -20, 4, -20, -20, -20, -20, -20, + -20, -20, -20, -20, -20, -20, -6, -20, -20, 16, + -20, 17, 23, -20, -20, 24, -20, -20, -20, 27, + 28, -20, -20, -20, 29, -20, 32, -8, -20, -20, + -20 +}; - 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. +/* YYPGOTO[NTERM-NUM]. */ +static const yysigned_char yypgoto[] = +{ + -20, -20, -20, -20, -20, -20, -20, -20, -20, -20, + -7 +}; - 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., 675 Mass Ave, Cambridge, MA 02139, USA. */ +/* YYTABLE[YYPACT[STATE-NUM]]. What to do in state STATE-NUM. If + positive, shift that token. If negative, reduce the rule which + number is the opposite. If zero, do what YYDEFACT says. + If YYTABLE_NINF, syntax error. */ +#define YYTABLE_NINF -1 +static const unsigned char yytable[] = +{ + 2, 23, 52, 24, 3, 4, 5, 59, 6, 46, + 47, 7, 8, 9, 10, 11, 12, 13, 14, 31, + 32, 43, 44, 33, 45, 34, 35, 36, 37, 38, + 39, 48, 40, 49, 41, 25, 42, 52, 26, 50, + 51, 27, 53, 28, 29, 57, 54, 30, 58, 56, + 60 +}; -/* As a special exception, when this file is copied by Bison into a - Bison output file, you may use that output file without restriction. - This special exception was added by the Free Software Foundation - in version 1.24 of Bison. */ +static const unsigned char yycheck[] = +{ + 0, 20, 10, 16, 4, 5, 6, 15, 8, 15, + 16, 11, 12, 13, 14, 15, 16, 17, 18, 4, + 5, 7, 3, 8, 20, 10, 11, 12, 13, 14, + 15, 15, 17, 16, 19, 5, 21, 10, 8, 16, + 16, 11, 15, 13, 14, 16, 19, 17, 16, 21, + 57 +}; -#ifndef alloca -#ifdef __GNUC__ -#define alloca __builtin_alloca -#else /* not GNU C. */ -#if (!defined (__STDC__) && defined (sparc)) || defined (__sparc__) || defined (__sparc) || defined (__sgi) -#include -#else /* not sparc */ -#if defined (MSDOS) && !defined (__TURBOC__) -#include -#else /* not MSDOS, or __TURBOC__ */ -#if defined(_AIX) -#include - #pragma alloca -#else /* not MSDOS, __TURBOC__, or _AIX */ -#ifdef __hpux -#include -#ifdef _ULONG_T /* defined in on HP-UX 10 */ -#include -#else /* earlier HP-UX versions have alloca as a library function */ -#ifdef __cplusplus -extern "C" { -void *alloca (unsigned int); +/* YYSTOS[STATE-NUM] -- The (internal number of the) accessing + symbol of state STATE-NUM. */ +static const unsigned char yystos[] = +{ + 0, 23, 0, 4, 5, 6, 8, 11, 12, 13, + 14, 15, 16, 17, 18, 24, 25, 26, 27, 28, + 29, 30, 31, 20, 16, 5, 8, 11, 13, 14, + 17, 4, 5, 8, 10, 11, 12, 13, 14, 15, + 17, 19, 21, 7, 3, 20, 15, 16, 15, 16, + 16, 16, 10, 15, 19, 32, 21, 16, 16, 15, + 32 }; -#else /* not __cplusplus */ -#define alloca __builtin_alloca -#endif /* not __cplusplus */ -#endif /* HP-UX <= 9 */ -#endif /* __hpux */ -#endif /* not _AIX */ -#endif /* not MSDOS, or __TURBOC__ */ -#endif /* not sparc. */ -#endif /* not GNU C. */ -#endif /* alloca not defined. */ - -/* This is the parser code that is written into each bison parser - when the %semantic_parser declaration is not specified in the grammar. - It was written by Richard Stallman by simplifying the hairy parser - used when %semantic_parser is specified. */ - -/* Note: there must be only one dollar sign in this file. - It is replaced by the list of actions, each action - as one case of the switch. */ + +#if ! defined (YYSIZE_T) && defined (__SIZE_TYPE__) +# define YYSIZE_T __SIZE_TYPE__ +#endif +#if ! defined (YYSIZE_T) && defined (size_t) +# define YYSIZE_T size_t +#endif +#if ! defined (YYSIZE_T) +# if defined (__STDC__) || defined (__cplusplus) +# include /* INFRINGES ON USER NAME SPACE */ +# define YYSIZE_T size_t +# endif +#endif +#if ! defined (YYSIZE_T) +# define YYSIZE_T unsigned int +#endif #define yyerrok (yyerrstatus = 0) #define yyclearin (yychar = YYEMPTY) -#define YYEMPTY -2 +#define YYEMPTY (-2) #define YYEOF 0 -#define YYACCEPT return(0) -#define YYABORT return(1) -#define YYERROR goto yyerrlab1 -/* Like YYERROR except do call yyerror. - This remains here temporarily to ease the - transition to the new meaning of YYERROR, for GCC. + +#define YYACCEPT goto yyacceptlab +#define YYABORT goto yyabortlab +#define YYERROR goto yyerrorlab + + +/* Like YYERROR except do call yyerror. This remains here temporarily + to ease the transition to the new meaning of YYERROR, for GCC. Once GCC version 2 has supplanted version 1, this can go. */ + #define YYFAIL goto yyerrlab + #define YYRECOVERING() (!!yyerrstatus) -#define YYBACKUP(token, value) \ + +#define YYBACKUP(Token, Value) \ do \ if (yychar == YYEMPTY && yylen == 1) \ - { yychar = (token), yylval = (value); \ - yychar1 = YYTRANSLATE (yychar); \ + { \ + yychar = (Token); \ + yylval = (Value); \ + yytoken = YYTRANSLATE (yychar); \ YYPOPSTACK; \ goto yybackup; \ } \ else \ - { yyerror ("syntax error: cannot back up"); YYERROR; } \ + { \ + yyerror ("syntax error: cannot back up");\ + YYERROR; \ + } \ while (0) + #define YYTERROR 1 #define YYERRCODE 256 -#ifndef YYPURE -#define YYLEX yylex() + +/* YYLLOC_DEFAULT -- Set CURRENT to span from RHS[1] to RHS[N]. + If N is 0, then set CURRENT to the empty location which ends + the previous symbol: RHS[0] (always defined). */ + +#define YYRHSLOC(Rhs, K) ((Rhs)[K]) +#ifndef YYLLOC_DEFAULT +# define YYLLOC_DEFAULT(Current, Rhs, N) \ + do \ + if (N) \ + { \ + (Current).first_line = YYRHSLOC (Rhs, 1).first_line; \ + (Current).first_column = YYRHSLOC (Rhs, 1).first_column; \ + (Current).last_line = YYRHSLOC (Rhs, N).last_line; \ + (Current).last_column = YYRHSLOC (Rhs, N).last_column; \ + } \ + else \ + { \ + (Current).first_line = (Current).last_line = \ + YYRHSLOC (Rhs, 0).last_line; \ + (Current).first_column = (Current).last_column = \ + YYRHSLOC (Rhs, 0).last_column; \ + } \ + while (0) #endif -#ifdef YYPURE -#ifdef YYLSP_NEEDED -#ifdef YYLEX_PARAM -#define YYLEX yylex(&yylval, &yylloc, YYLEX_PARAM) -#else -#define YYLEX yylex(&yylval, &yylloc) + +/* YY_LOCATION_PRINT -- Print the location on the stream. + This macro was not mandated originally: define only if we know + we won't break user code: when these are the locations we know. */ + +#ifndef YY_LOCATION_PRINT +# if YYLTYPE_IS_TRIVIAL +# define YY_LOCATION_PRINT(File, Loc) \ + fprintf (File, "%d.%d-%d.%d", \ + (Loc).first_line, (Loc).first_column, \ + (Loc).last_line, (Loc).last_column) +# else +# define YY_LOCATION_PRINT(File, Loc) ((void) 0) +# endif #endif -#else /* not YYLSP_NEEDED */ + + +/* YYLEX -- calling `yylex' with the right arguments. */ + #ifdef YYLEX_PARAM -#define YYLEX yylex(&yylval, YYLEX_PARAM) +# define YYLEX yylex (YYLEX_PARAM) #else -#define YYLEX yylex(&yylval) -#endif -#endif /* not YYLSP_NEEDED */ +# define YYLEX yylex () #endif -/* If nonreentrant, generate the variables here */ +/* Enable debugging if requested. */ +#if YYDEBUG + +# ifndef YYFPRINTF +# include /* INFRINGES ON USER NAME SPACE */ +# define YYFPRINTF fprintf +# endif -#ifndef YYPURE +# define YYDPRINTF(Args) \ +do { \ + if (yydebug) \ + YYFPRINTF Args; \ +} while (0) + +# define YY_SYMBOL_PRINT(Title, Type, Value, Location) \ +do { \ + if (yydebug) \ + { \ + YYFPRINTF (stderr, "%s ", Title); \ + yysymprint (stderr, \ + Type, Value); \ + YYFPRINTF (stderr, "\n"); \ + } \ +} while (0) -int yychar; /* the lookahead symbol */ -YYSTYPE yylval; /* the semantic value of the */ - /* lookahead symbol */ +/*------------------------------------------------------------------. +| yy_stack_print -- Print the state stack from its BOTTOM up to its | +| TOP (included). | +`------------------------------------------------------------------*/ -#ifdef YYLSP_NEEDED -YYLTYPE yylloc; /* location data for the lookahead */ - /* symbol */ +#if defined (__STDC__) || defined (__cplusplus) +static void +yy_stack_print (short int *bottom, short int *top) +#else +static void +yy_stack_print (bottom, top) + short int *bottom; + short int *top; #endif +{ + YYFPRINTF (stderr, "Stack now"); + for (/* Nothing. */; bottom <= top; ++bottom) + YYFPRINTF (stderr, " %d", *bottom); + YYFPRINTF (stderr, "\n"); +} + +# define YY_STACK_PRINT(Bottom, Top) \ +do { \ + if (yydebug) \ + yy_stack_print ((Bottom), (Top)); \ +} while (0) -int yynerrs; /* number of parse errors so far */ -#endif /* not YYPURE */ -#if YYDEBUG != 0 -int yydebug; /* nonzero means print parse trace */ -/* Since this is uninitialized, it does not stop multiple parsers - from coexisting. */ +/*------------------------------------------------. +| Report that the YYRULE is going to be reduced. | +`------------------------------------------------*/ + +#if defined (__STDC__) || defined (__cplusplus) +static void +yy_reduce_print (int yyrule) +#else +static void +yy_reduce_print (yyrule) + int yyrule; #endif +{ + int yyi; + unsigned int yylno = yyrline[yyrule]; + YYFPRINTF (stderr, "Reducing stack by rule %d (line %u), ", + yyrule - 1, yylno); + /* Print the symbols being reduced, and their result. */ + for (yyi = yyprhs[yyrule]; 0 <= yyrhs[yyi]; yyi++) + YYFPRINTF (stderr, "%s ", yytname [yyrhs[yyi]]); + YYFPRINTF (stderr, "-> %s\n", yytname [yyr1[yyrule]]); +} + +# define YY_REDUCE_PRINT(Rule) \ +do { \ + if (yydebug) \ + yy_reduce_print (Rule); \ +} while (0) + +/* Nonzero means print parse trace. It is left uninitialized so that + multiple parsers can coexist. */ +int yydebug; +#else /* !YYDEBUG */ +# define YYDPRINTF(Args) +# define YY_SYMBOL_PRINT(Title, Type, Value, Location) +# define YY_STACK_PRINT(Bottom, Top) +# define YY_REDUCE_PRINT(Rule) +#endif /* !YYDEBUG */ -/* YYINITDEPTH indicates the initial size of the parser's stacks */ +/* YYINITDEPTH -- initial size of the parser's stacks. */ #ifndef YYINITDEPTH -#define YYINITDEPTH 200 +# define YYINITDEPTH 200 #endif -/* YYMAXDEPTH is the maximum size the stacks can grow to - (effective only if the built-in stack extension method is used). */ +/* YYMAXDEPTH -- maximum size the stacks can grow to (effective only + if the built-in stack extension method is used). -#if YYMAXDEPTH == 0 -#undef YYMAXDEPTH -#endif + Do not make this value too large; the results are undefined if + SIZE_MAX < YYSTACK_BYTES (YYMAXDEPTH) + evaluated with infinite-precision integer arithmetic. */ #ifndef YYMAXDEPTH -#define YYMAXDEPTH 10000 +# define YYMAXDEPTH 10000 #endif -/* Prevent warning if -Wstrict-prototypes. */ -#ifdef __GNUC__ -int yyparse (void); -#endif -/* Define __yy_memcpy. Note that the size argument - should be passed with type unsigned int, because that is what the non-GCC - definitions require. With GCC, __builtin_memcpy takes an arg - of type size_t, but it can handle unsigned int. */ - -#if __GNUC__ > 1 /* GNU C and GNU C++ define this. */ -#define __yy_memcpy(TO,FROM,COUNT) __builtin_memcpy(TO,FROM,COUNT) -#else /* not GNU C or C++ */ -#ifndef __cplusplus -/* This is the most reliable way to avoid incompatibilities - in available built-in functions on various systems. */ -static void -__yy_memcpy (to, from, count) - char *to; - char *from; - unsigned int count; -{ - register char *f = from; - register char *t = to; - register int i = count; +#if YYERROR_VERBOSE + +# ifndef yystrlen +# if defined (__GLIBC__) && defined (_STRING_H) +# define yystrlen strlen +# else +/* Return the length of YYSTR. */ +static YYSIZE_T +# if defined (__STDC__) || defined (__cplusplus) +yystrlen (const char *yystr) +# else +yystrlen (yystr) + const char *yystr; +# endif +{ + register const char *yys = yystr; + + while (*yys++ != '\0') + continue; - while (i-- > 0) - *t++ = *f++; + return yys - yystr - 1; } +# endif +# endif + +# ifndef yystpcpy +# if defined (__GLIBC__) && defined (_STRING_H) && defined (_GNU_SOURCE) +# define yystpcpy stpcpy +# else +/* Copy YYSRC to YYDEST, returning the address of the terminating '\0' in + YYDEST. */ +static char * +# if defined (__STDC__) || defined (__cplusplus) +yystpcpy (char *yydest, const char *yysrc) +# else +yystpcpy (yydest, yysrc) + char *yydest; + const char *yysrc; +# endif +{ + register char *yyd = yydest; + register const char *yys = yysrc; + + while ((*yyd++ = *yys++) != '\0') + continue; -#else /* __cplusplus */ + return yyd - 1; +} +# endif +# endif -/* This is the most reliable way to avoid incompatibilities - in available built-in functions on various systems. */ +#endif /* !YYERROR_VERBOSE */ + + + +#if YYDEBUG +/*--------------------------------. +| Print this symbol on YYOUTPUT. | +`--------------------------------*/ + +#if defined (__STDC__) || defined (__cplusplus) static void -__yy_memcpy (char *to, char *from, unsigned int count) +yysymprint (FILE *yyoutput, int yytype, YYSTYPE *yyvaluep) +#else +static void +yysymprint (yyoutput, yytype, yyvaluep) + FILE *yyoutput; + int yytype; + YYSTYPE *yyvaluep; +#endif { - register char *f = from; - register char *t = to; - register int i = count; + /* Pacify ``unused variable'' warnings. */ + (void) yyvaluep; - while (i-- > 0) - *t++ = *f++; + if (yytype < YYNTOKENS) + YYFPRINTF (yyoutput, "token %s (", yytname[yytype]); + else + YYFPRINTF (yyoutput, "nterm %s (", yytname[yytype]); + + +# ifdef YYPRINT + if (yytype < YYNTOKENS) + YYPRINT (yyoutput, yytoknum[yytype], *yyvaluep); +# endif + switch (yytype) + { + default: + break; + } + YYFPRINTF (yyoutput, ")"); } +#endif /* ! YYDEBUG */ +/*-----------------------------------------------. +| Release the memory associated to this symbol. | +`-----------------------------------------------*/ + +#if defined (__STDC__) || defined (__cplusplus) +static void +yydestruct (const char *yymsg, int yytype, YYSTYPE *yyvaluep) +#else +static void +yydestruct (yymsg, yytype, yyvaluep) + const char *yymsg; + int yytype; + YYSTYPE *yyvaluep; #endif -#endif +{ + /* Pacify ``unused variable'' warnings. */ + (void) yyvaluep; + + if (!yymsg) + yymsg = "Deleting"; + YY_SYMBOL_PRINT (yymsg, yytype, yyvaluep, yylocationp); + + switch (yytype) + { + + default: + break; + } +} -#line 196 "/usr/local/share/bison.simple" -/* The user can define YYPARSE_PARAM as the name of an argument to be passed - into yyparse. The argument should have type void *. - It should actually point to an object. - Grammar actions can access the variable by casting it - to the proper pointer type. */ +/* Prevent warnings from -Wmissing-prototypes. */ #ifdef YYPARSE_PARAM -#ifdef __cplusplus -#define YYPARSE_PARAM_ARG void *YYPARSE_PARAM -#define YYPARSE_PARAM_DECL -#else /* not __cplusplus */ -#define YYPARSE_PARAM_ARG YYPARSE_PARAM -#define YYPARSE_PARAM_DECL void *YYPARSE_PARAM; -#endif /* not __cplusplus */ -#else /* not YYPARSE_PARAM */ -#define YYPARSE_PARAM_ARG -#define YYPARSE_PARAM_DECL -#endif /* not YYPARSE_PARAM */ +# if defined (__STDC__) || defined (__cplusplus) +int yyparse (void *YYPARSE_PARAM); +# else +int yyparse (); +# endif +#else /* ! YYPARSE_PARAM */ +#if defined (__STDC__) || defined (__cplusplus) +int yyparse (void); +#else +int yyparse (); +#endif +#endif /* ! YYPARSE_PARAM */ + + +/* The look-ahead symbol. */ +int yychar; + +/* The semantic value of the look-ahead symbol. */ +YYSTYPE yylval; + +/* Number of syntax errors so far. */ +int yynerrs; + + + +/*----------. +| yyparse. | +`----------*/ + +#ifdef YYPARSE_PARAM +# if defined (__STDC__) || defined (__cplusplus) +int yyparse (void *YYPARSE_PARAM) +# else +int yyparse (YYPARSE_PARAM) + void *YYPARSE_PARAM; +# endif +#else /* ! YYPARSE_PARAM */ +#if defined (__STDC__) || defined (__cplusplus) +int +yyparse (void) +#else int -yyparse(YYPARSE_PARAM_ARG) - YYPARSE_PARAM_DECL +yyparse () + +#endif +#endif { + register int yystate; register int yyn; - register short *yyssp; + int yyresult; + /* Number of tokens to shift before error messages enabled. */ + int yyerrstatus; + /* Look-ahead token as an internal (translated) token number. */ + int yytoken = 0; + + /* Three stacks and their tools: + `yyss': related to states, + `yyvs': related to semantic values, + `yyls': related to locations. + + Refer to the stacks thru separate pointers, to allow yyoverflow + to reallocate them elsewhere. */ + + /* The state stack. */ + short int yyssa[YYINITDEPTH]; + short int *yyss = yyssa; + register short int *yyssp; + + /* The semantic value stack. */ + YYSTYPE yyvsa[YYINITDEPTH]; + YYSTYPE *yyvs = yyvsa; register YYSTYPE *yyvsp; - int yyerrstatus; /* number of tokens to shift before error messages enabled */ - int yychar1 = 0; /* lookahead token as an internal (translated) token number */ - - short yyssa[YYINITDEPTH]; /* the state stack */ - YYSTYPE yyvsa[YYINITDEPTH]; /* the semantic value stack */ - short *yyss = yyssa; /* refer to the stacks thru separate pointers */ - YYSTYPE *yyvs = yyvsa; /* to allow yyoverflow to reallocate them elsewhere */ -#ifdef YYLSP_NEEDED - YYLTYPE yylsa[YYINITDEPTH]; /* the location stack */ - YYLTYPE *yyls = yylsa; - YYLTYPE *yylsp; -#define YYPOPSTACK (yyvsp--, yyssp--, yylsp--) -#else #define YYPOPSTACK (yyvsp--, yyssp--) -#endif - int yystacksize = YYINITDEPTH; + YYSIZE_T yystacksize = YYINITDEPTH; -#ifdef YYPURE - int yychar; - YYSTYPE yylval; - int yynerrs; -#ifdef YYLSP_NEEDED - YYLTYPE yylloc; -#endif -#endif + /* The variables used to return semantic value and location from the + action routines. */ + YYSTYPE yyval; - YYSTYPE yyval; /* the variable used to return */ - /* semantic values from the action */ - /* routines */ + /* When reducing, the number of symbols on the RHS of the reduced + rule. */ int yylen; -#if YYDEBUG != 0 - if (yydebug) - fprintf(stderr, "Starting parse\n"); -#endif + YYDPRINTF ((stderr, "Starting parse\n")); yystate = 0; yyerrstatus = 0; @@ -647,792 +1070,836 @@ so that they stay on the same level as the state stack. The wasted elements are never initialized. */ - yyssp = yyss - 1; + yyssp = yyss; yyvsp = yyvs; -#ifdef YYLSP_NEEDED - yylsp = yyls; -#endif -/* Push a new state, which is found in yystate . */ -/* In all cases, when you get here, the value and location stacks - have just been pushed. so pushing a state here evens the stacks. */ -yynewstate: - *++yyssp = yystate; + yyvsp[0] = yylval; - if (yyssp >= yyss + yystacksize - 1) - { - /* Give user a chance to reallocate the stack */ - /* Use copies of these so that the &'s don't force the real ones into memory. */ - YYSTYPE *yyvs1 = yyvs; - short *yyss1 = yyss; -#ifdef YYLSP_NEEDED - YYLTYPE *yyls1 = yyls; -#endif + goto yysetstate; +/*------------------------------------------------------------. +| yynewstate -- Push a new state, which is found in yystate. | +`------------------------------------------------------------*/ + yynewstate: + /* In all cases, when you get here, the value and location stacks + have just been pushed. so pushing a state here evens the stacks. + */ + yyssp++; + + yysetstate: + *yyssp = yystate; + + if (yyss + yystacksize - 1 <= yyssp) + { /* Get the current used size of the three stacks, in elements. */ - int size = yyssp - yyss + 1; + YYSIZE_T yysize = yyssp - yyss + 1; #ifdef yyoverflow - /* Each stack pointer address is followed by the size of - the data in use in that stack, in bytes. */ -#ifdef YYLSP_NEEDED - /* This used to be a conditional around just the two extra args, - but that might be undefined if yyoverflow is a macro. */ - yyoverflow("parser stack overflow", - &yyss1, size * sizeof (*yyssp), - &yyvs1, size * sizeof (*yyvsp), - &yyls1, size * sizeof (*yylsp), - &yystacksize); -#else - yyoverflow("parser stack overflow", - &yyss1, size * sizeof (*yyssp), - &yyvs1, size * sizeof (*yyvsp), - &yystacksize); -#endif + { + /* Give user a chance to reallocate the stack. Use copies of + these so that the &'s don't force the real ones into + memory. */ + YYSTYPE *yyvs1 = yyvs; + short int *yyss1 = yyss; + + + /* Each stack pointer address is followed by the size of the + data in use in that stack, in bytes. This used to be a + conditional around just the two extra args, but that might + be undefined if yyoverflow is a macro. */ + yyoverflow ("parser stack overflow", + &yyss1, yysize * sizeof (*yyssp), + &yyvs1, yysize * sizeof (*yyvsp), - yyss = yyss1; yyvs = yyvs1; -#ifdef YYLSP_NEEDED - yyls = yyls1; -#endif + &yystacksize); + + yyss = yyss1; + yyvs = yyvs1; + } #else /* no yyoverflow */ +# ifndef YYSTACK_RELOCATE + goto yyoverflowlab; +# else /* Extend the stack our own way. */ - if (yystacksize >= YYMAXDEPTH) - { - yyerror("parser stack overflow"); - return 2; - } + if (YYMAXDEPTH <= yystacksize) + goto yyoverflowlab; yystacksize *= 2; - if (yystacksize > YYMAXDEPTH) + if (YYMAXDEPTH < yystacksize) yystacksize = YYMAXDEPTH; - yyss = (short *) alloca (yystacksize * sizeof (*yyssp)); - __yy_memcpy ((char *)yyss, (char *)yyss1, - (unsigned int) size * sizeof (*yyssp)); - yyvs = (YYSTYPE *) alloca (yystacksize * sizeof (*yyvsp)); - __yy_memcpy ((char *)yyvs, (char *)yyvs1, - (unsigned int) size * sizeof (*yyvsp)); -#ifdef YYLSP_NEEDED - yyls = (YYLTYPE *) alloca (yystacksize * sizeof (*yylsp)); - __yy_memcpy ((char *)yyls, (char *)yyls1, - (unsigned int) size * sizeof (*yylsp)); -#endif + + { + short int *yyss1 = yyss; + union yyalloc *yyptr = + (union yyalloc *) YYSTACK_ALLOC (YYSTACK_BYTES (yystacksize)); + if (! yyptr) + goto yyoverflowlab; + YYSTACK_RELOCATE (yyss); + YYSTACK_RELOCATE (yyvs); + +# undef YYSTACK_RELOCATE + if (yyss1 != yyssa) + YYSTACK_FREE (yyss1); + } +# endif #endif /* no yyoverflow */ - yyssp = yyss + size - 1; - yyvsp = yyvs + size - 1; -#ifdef YYLSP_NEEDED - yylsp = yyls + size - 1; -#endif + yyssp = yyss + yysize - 1; + yyvsp = yyvs + yysize - 1; -#if YYDEBUG != 0 - if (yydebug) - fprintf(stderr, "Stack size increased to %d\n", yystacksize); -#endif - if (yyssp >= yyss + yystacksize - 1) + YYDPRINTF ((stderr, "Stack size increased to %lu\n", + (unsigned long int) yystacksize)); + + if (yyss + yystacksize - 1 <= yyssp) YYABORT; } -#if YYDEBUG != 0 - if (yydebug) - fprintf(stderr, "Entering state %d\n", yystate); -#endif + YYDPRINTF ((stderr, "Entering state %d\n", yystate)); goto yybackup; - yybackup: + +/*-----------. +| yybackup. | +`-----------*/ +yybackup: /* Do appropriate processing given the current state. */ -/* Read a lookahead token if we need one and don't already have one. */ +/* Read a look-ahead token if we need one and don't already have one. */ /* yyresume: */ - /* First try to decide what to do without reference to lookahead token. */ + /* First try to decide what to do without reference to look-ahead token. */ yyn = yypact[yystate]; - if (yyn == YYFLAG) + if (yyn == YYPACT_NINF) goto yydefault; - /* Not known => get a lookahead token if don't already have one. */ - - /* yychar is either YYEMPTY or YYEOF - or a valid token in external form. */ + /* Not known => get a look-ahead token if don't already have one. */ + /* YYCHAR is either YYEMPTY or YYEOF or a valid look-ahead symbol. */ if (yychar == YYEMPTY) { -#if YYDEBUG != 0 - if (yydebug) - fprintf(stderr, "Reading a token: "); -#endif + YYDPRINTF ((stderr, "Reading a token: ")); yychar = YYLEX; } - /* Convert token to internal form (in yychar1) for indexing tables with */ - - if (yychar <= 0) /* This means end of input. */ + if (yychar <= YYEOF) { - yychar1 = 0; - yychar = YYEOF; /* Don't call YYLEX any more */ - -#if YYDEBUG != 0 - if (yydebug) - fprintf(stderr, "Now at end of input.\n"); -#endif + yychar = yytoken = YYEOF; + YYDPRINTF ((stderr, "Now at end of input.\n")); } else { - yychar1 = YYTRANSLATE(yychar); - -#if YYDEBUG != 0 - if (yydebug) - { - fprintf (stderr, "Next token is %d (%s", yychar, yytname[yychar1]); - /* Give the individual parser a way to print the precise meaning - of a token, for further debugging info. */ -#ifdef YYPRINT - YYPRINT (stderr, yychar, yylval); -#endif - fprintf (stderr, ")\n"); - } -#endif + yytoken = YYTRANSLATE (yychar); + YY_SYMBOL_PRINT ("Next token is", yytoken, &yylval, &yylloc); } - yyn += yychar1; - if (yyn < 0 || yyn > YYLAST || yycheck[yyn] != yychar1) + /* If the proper action on seeing token YYTOKEN is to reduce or to + detect an error, take that action. */ + yyn += yytoken; + if (yyn < 0 || YYLAST < yyn || yycheck[yyn] != yytoken) goto yydefault; - yyn = yytable[yyn]; - - /* yyn is what to do for this token type in this state. - Negative => reduce, -yyn is rule number. - Positive => shift, yyn is new state. - New state is final state => don't bother to shift, - just return success. - 0, or most negative number => error. */ - - if (yyn < 0) + if (yyn <= 0) { - if (yyn == YYFLAG) + if (yyn == 0 || yyn == YYTABLE_NINF) goto yyerrlab; yyn = -yyn; goto yyreduce; } - else if (yyn == 0) - goto yyerrlab; if (yyn == YYFINAL) YYACCEPT; - /* Shift the lookahead token. */ - -#if YYDEBUG != 0 - if (yydebug) - fprintf(stderr, "Shifting token %d (%s), ", yychar, yytname[yychar1]); -#endif + /* Shift the look-ahead token. */ + YY_SYMBOL_PRINT ("Shifting", yytoken, &yylval, &yylloc); /* Discard the token being shifted unless it is eof. */ if (yychar != YYEOF) yychar = YYEMPTY; *++yyvsp = yylval; -#ifdef YYLSP_NEEDED - *++yylsp = yylloc; -#endif - /* count tokens shifted since error; after three, turn off error status. */ - if (yyerrstatus) yyerrstatus--; + + /* Count tokens shifted since error; after three, turn off error + status. */ + if (yyerrstatus) + yyerrstatus--; yystate = yyn; goto yynewstate; -/* Do the default action for the current state. */ -yydefault: +/*-----------------------------------------------------------. +| yydefault -- do the default action for the current state. | +`-----------------------------------------------------------*/ +yydefault: yyn = yydefact[yystate]; if (yyn == 0) goto yyerrlab; + goto yyreduce; + -/* Do a reduction. yyn is the number of a rule to reduce with. */ +/*-----------------------------. +| yyreduce -- Do a reduction. | +`-----------------------------*/ yyreduce: + /* yyn is the number of a rule to reduce with. */ yylen = yyr2[yyn]; - if (yylen > 0) - yyval = yyvsp[1-yylen]; /* implement default value of the action */ -#if YYDEBUG != 0 - if (yydebug) - { - int i; - - fprintf (stderr, "Reducing via rule %d (line %d), ", - yyn, yyrline[yyn]); + /* If YYLEN is nonzero, implement the default value of the action: + `$$ = $1'. - /* Print the symbols being reduced, and their result. */ - for (i = yyprhs[yyn]; yyrhs[i] > 0; i++) - fprintf (stderr, "%s ", yytname[yyrhs[i]]); - fprintf (stderr, " -> %s\n", yytname[yyr1[yyn]]); - } -#endif + Otherwise, the following line sets YYVAL to garbage. + This behavior is undocumented and Bison + users should not rely upon it. Assigning to YYVAL + unconditionally makes the parser a bit smaller, and it avoids a + GCC warning that YYVAL may be used uninitialized. */ + yyval = yyvsp[1-yylen]; - switch (yyn) { - -case 3: + YY_REDUCE_PRINT (yyn); + switch (yyn) + { + case 4: #line 195 "getdate.y" -{ + { yyHaveTime++; - ; - break;} -case 4: + } + break; + + case 5: #line 198 "getdate.y" -{ + { yyHaveZone++; - ; - break;} -case 5: + } + break; + + case 6: #line 201 "getdate.y" -{ + { yyHaveDate++; - ; - break;} -case 6: + } + break; + + case 7: #line 204 "getdate.y" -{ + { yyHaveDay++; - ; - break;} -case 7: + } + break; + + case 8: #line 207 "getdate.y" -{ + { yyHaveRel++; - ; - break;} -case 9: + } + break; + + case 10: #line 213 "getdate.y" -{ - yyHour = yyvsp[-1].Number; + { + yyHour = (yyvsp[-1].Number); yyMinutes = 0; yySeconds = 0; - yyMeridian = yyvsp[0].Meridian; - ; - break;} -case 10: + yyMeridian = (yyvsp[0].Meridian); + } + break; + + case 11: #line 219 "getdate.y" -{ - yyHour = yyvsp[-3].Number; - yyMinutes = yyvsp[-1].Number; + { + yyHour = (yyvsp[-3].Number); + yyMinutes = (yyvsp[-1].Number); yySeconds = 0; - yyMeridian = yyvsp[0].Meridian; - ; - break;} -case 11: + yyMeridian = (yyvsp[0].Meridian); + } + break; + + case 12: #line 225 "getdate.y" -{ - yyHour = yyvsp[-3].Number; - yyMinutes = yyvsp[-1].Number; + { + yyHour = (yyvsp[-3].Number); + yyMinutes = (yyvsp[-1].Number); yyMeridian = MER24; yyHaveZone++; - yyTimezone = (yyvsp[0].Number < 0 - ? -yyvsp[0].Number % 100 + (-yyvsp[0].Number / 100) * 60 - : - (yyvsp[0].Number % 100 + (yyvsp[0].Number / 100) * 60)); - ; - break;} -case 12: + yyTimezone = ((yyvsp[0].Number) < 0 + ? -(yyvsp[0].Number) % 100 + (-(yyvsp[0].Number) / 100) * 60 + : - ((yyvsp[0].Number) % 100 + ((yyvsp[0].Number) / 100) * 60)); + } + break; + + case 13: #line 234 "getdate.y" -{ - yyHour = yyvsp[-5].Number; - yyMinutes = yyvsp[-3].Number; - yySeconds = yyvsp[-1].Number; - yyMeridian = yyvsp[0].Meridian; - ; - break;} -case 13: + { + yyHour = (yyvsp[-5].Number); + yyMinutes = (yyvsp[-3].Number); + yySeconds = (yyvsp[-1].Number); + yyMeridian = (yyvsp[0].Meridian); + } + break; + + case 14: #line 240 "getdate.y" -{ - yyHour = yyvsp[-5].Number; - yyMinutes = yyvsp[-3].Number; - yySeconds = yyvsp[-1].Number; + { + yyHour = (yyvsp[-5].Number); + yyMinutes = (yyvsp[-3].Number); + yySeconds = (yyvsp[-1].Number); yyMeridian = MER24; yyHaveZone++; - yyTimezone = (yyvsp[0].Number < 0 - ? -yyvsp[0].Number % 100 + (-yyvsp[0].Number / 100) * 60 - : - (yyvsp[0].Number % 100 + (yyvsp[0].Number / 100) * 60)); - ; - break;} -case 14: + yyTimezone = ((yyvsp[0].Number) < 0 + ? -(yyvsp[0].Number) % 100 + (-(yyvsp[0].Number) / 100) * 60 + : - ((yyvsp[0].Number) % 100 + ((yyvsp[0].Number) / 100) * 60)); + } + break; + + case 15: #line 252 "getdate.y" -{ - yyTimezone = yyvsp[0].Number; - ; - break;} -case 15: + { + yyTimezone = (yyvsp[0].Number); + } + break; + + case 16: #line 255 "getdate.y" -{ - yyTimezone = yyvsp[0].Number - 60; - ; - break;} -case 16: + { + yyTimezone = (yyvsp[0].Number) - 60; + } + break; + + case 17: #line 259 "getdate.y" -{ - yyTimezone = yyvsp[-1].Number - 60; - ; - break;} -case 17: + { + yyTimezone = (yyvsp[-1].Number) - 60; + } + break; + + case 18: #line 264 "getdate.y" -{ + { yyDayOrdinal = 1; - yyDayNumber = yyvsp[0].Number; - ; - break;} -case 18: + yyDayNumber = (yyvsp[0].Number); + } + break; + + case 19: #line 268 "getdate.y" -{ + { yyDayOrdinal = 1; - yyDayNumber = yyvsp[-1].Number; - ; - break;} -case 19: + yyDayNumber = (yyvsp[-1].Number); + } + break; + + case 20: #line 272 "getdate.y" -{ - yyDayOrdinal = yyvsp[-1].Number; - yyDayNumber = yyvsp[0].Number; - ; - break;} -case 20: + { + yyDayOrdinal = (yyvsp[-1].Number); + yyDayNumber = (yyvsp[0].Number); + } + break; + + case 21: #line 278 "getdate.y" -{ - yyMonth = yyvsp[-2].Number; - yyDay = yyvsp[0].Number; - ; - break;} -case 21: + { + yyMonth = (yyvsp[-2].Number); + yyDay = (yyvsp[0].Number); + } + break; + + case 22: #line 282 "getdate.y" -{ + { /* Interpret as YYYY/MM/DD if $1 >= 1000, otherwise as MM/DD/YY. The goal in recognizing YYYY/MM/DD is solely to support legacy machine-generated dates like those in an RCS log listing. If you want portability, use the ISO 8601 format. */ - if (yyvsp[-4].Number >= 1000) + if ((yyvsp[-4].Number) >= 1000) { - yyYear = yyvsp[-4].Number; - yyMonth = yyvsp[-2].Number; - yyDay = yyvsp[0].Number; + yyYear = (yyvsp[-4].Number); + yyMonth = (yyvsp[-2].Number); + yyDay = (yyvsp[0].Number); } else { - yyMonth = yyvsp[-4].Number; - yyDay = yyvsp[-2].Number; - yyYear = yyvsp[0].Number; + yyMonth = (yyvsp[-4].Number); + yyDay = (yyvsp[-2].Number); + yyYear = (yyvsp[0].Number); } - ; - break;} -case 22: + } + break; + + case 23: #line 300 "getdate.y" -{ + { /* ISO 8601 format. yyyy-mm-dd. */ - yyYear = yyvsp[-2].Number; - yyMonth = -yyvsp[-1].Number; - yyDay = -yyvsp[0].Number; - ; - break;} -case 23: + yyYear = (yyvsp[-2].Number); + yyMonth = -(yyvsp[-1].Number); + yyDay = -(yyvsp[0].Number); + } + break; + + case 24: #line 306 "getdate.y" -{ + { /* e.g. 17-JUN-1992. */ - yyDay = yyvsp[-2].Number; - yyMonth = yyvsp[-1].Number; - yyYear = -yyvsp[0].Number; - ; - break;} -case 24: + yyDay = (yyvsp[-2].Number); + yyMonth = (yyvsp[-1].Number); + yyYear = -(yyvsp[0].Number); + } + break; + + case 25: #line 312 "getdate.y" -{ - yyMonth = yyvsp[-1].Number; - yyDay = yyvsp[0].Number; - ; - break;} -case 25: + { + yyMonth = (yyvsp[-1].Number); + yyDay = (yyvsp[0].Number); + } + break; + + case 26: #line 316 "getdate.y" -{ - yyMonth = yyvsp[-3].Number; - yyDay = yyvsp[-2].Number; - yyYear = yyvsp[0].Number; - ; - break;} -case 26: + { + yyMonth = (yyvsp[-3].Number); + yyDay = (yyvsp[-2].Number); + yyYear = (yyvsp[0].Number); + } + break; + + case 27: #line 321 "getdate.y" -{ - yyMonth = yyvsp[0].Number; - yyDay = yyvsp[-1].Number; - ; - break;} -case 27: + { + yyMonth = (yyvsp[0].Number); + yyDay = (yyvsp[-1].Number); + } + break; + + case 28: #line 325 "getdate.y" -{ - yyMonth = yyvsp[-1].Number; - yyDay = yyvsp[-2].Number; - yyYear = yyvsp[0].Number; - ; - break;} -case 28: + { + yyMonth = (yyvsp[-1].Number); + yyDay = (yyvsp[-2].Number); + yyYear = (yyvsp[0].Number); + } + break; + + case 29: #line 332 "getdate.y" -{ + { yyRelSeconds = -yyRelSeconds; yyRelMinutes = -yyRelMinutes; yyRelHour = -yyRelHour; yyRelDay = -yyRelDay; yyRelMonth = -yyRelMonth; yyRelYear = -yyRelYear; - ; - break;} -case 30: + } + break; + + case 31: #line 343 "getdate.y" -{ - yyRelYear += yyvsp[-1].Number * yyvsp[0].Number; - ; - break;} -case 31: + { + yyRelYear += (yyvsp[-1].Number) * (yyvsp[0].Number); + } + break; + + case 32: #line 346 "getdate.y" -{ - yyRelYear += yyvsp[-1].Number * yyvsp[0].Number; - ; - break;} -case 32: + { + yyRelYear += (yyvsp[-1].Number) * (yyvsp[0].Number); + } + break; + + case 33: #line 349 "getdate.y" -{ - yyRelYear += yyvsp[0].Number; - ; - break;} -case 33: + { + yyRelYear += (yyvsp[0].Number); + } + break; + + case 34: #line 352 "getdate.y" -{ - yyRelMonth += yyvsp[-1].Number * yyvsp[0].Number; - ; - break;} -case 34: + { + yyRelMonth += (yyvsp[-1].Number) * (yyvsp[0].Number); + } + break; + + case 35: #line 355 "getdate.y" -{ - yyRelMonth += yyvsp[-1].Number * yyvsp[0].Number; - ; - break;} -case 35: + { + yyRelMonth += (yyvsp[-1].Number) * (yyvsp[0].Number); + } + break; + + case 36: #line 358 "getdate.y" -{ - yyRelMonth += yyvsp[0].Number; - ; - break;} -case 36: + { + yyRelMonth += (yyvsp[0].Number); + } + break; + + case 37: #line 361 "getdate.y" -{ - yyRelDay += yyvsp[-1].Number * yyvsp[0].Number; - ; - break;} -case 37: + { + yyRelDay += (yyvsp[-1].Number) * (yyvsp[0].Number); + } + break; + + case 38: #line 364 "getdate.y" -{ - yyRelDay += yyvsp[-1].Number * yyvsp[0].Number; - ; - break;} -case 38: + { + yyRelDay += (yyvsp[-1].Number) * (yyvsp[0].Number); + } + break; + + case 39: #line 367 "getdate.y" -{ - yyRelDay += yyvsp[0].Number; - ; - break;} -case 39: + { + yyRelDay += (yyvsp[0].Number); + } + break; + + case 40: #line 370 "getdate.y" -{ - yyRelHour += yyvsp[-1].Number * yyvsp[0].Number; - ; - break;} -case 40: + { + yyRelHour += (yyvsp[-1].Number) * (yyvsp[0].Number); + } + break; + + case 41: #line 373 "getdate.y" -{ - yyRelHour += yyvsp[-1].Number * yyvsp[0].Number; - ; - break;} -case 41: + { + yyRelHour += (yyvsp[-1].Number) * (yyvsp[0].Number); + } + break; + + case 42: #line 376 "getdate.y" -{ - yyRelHour += yyvsp[0].Number; - ; - break;} -case 42: + { + yyRelHour += (yyvsp[0].Number); + } + break; + + case 43: #line 379 "getdate.y" -{ - yyRelMinutes += yyvsp[-1].Number * yyvsp[0].Number; - ; - break;} -case 43: + { + yyRelMinutes += (yyvsp[-1].Number) * (yyvsp[0].Number); + } + break; + + case 44: #line 382 "getdate.y" -{ - yyRelMinutes += yyvsp[-1].Number * yyvsp[0].Number; - ; - break;} -case 44: + { + yyRelMinutes += (yyvsp[-1].Number) * (yyvsp[0].Number); + } + break; + + case 45: #line 385 "getdate.y" -{ - yyRelMinutes += yyvsp[0].Number; - ; - break;} -case 45: + { + yyRelMinutes += (yyvsp[0].Number); + } + break; + + case 46: #line 388 "getdate.y" -{ - yyRelSeconds += yyvsp[-1].Number * yyvsp[0].Number; - ; - break;} -case 46: + { + yyRelSeconds += (yyvsp[-1].Number) * (yyvsp[0].Number); + } + break; + + case 47: #line 391 "getdate.y" -{ - yyRelSeconds += yyvsp[-1].Number * yyvsp[0].Number; - ; - break;} -case 47: + { + yyRelSeconds += (yyvsp[-1].Number) * (yyvsp[0].Number); + } + break; + + case 48: #line 394 "getdate.y" -{ - yyRelSeconds += yyvsp[0].Number; - ; - break;} -case 48: + { + yyRelSeconds += (yyvsp[0].Number); + } + break; + + case 49: #line 400 "getdate.y" -{ + { if (yyHaveTime && yyHaveDate && !yyHaveRel) - yyYear = yyvsp[0].Number; + yyYear = (yyvsp[0].Number); else { - if (yyvsp[0].Number>10000) + if ((yyvsp[0].Number)>10000) { yyHaveDate++; - yyDay= (yyvsp[0].Number)%100; - yyMonth= (yyvsp[0].Number/100)%100; - yyYear = yyvsp[0].Number/10000; + yyDay= ((yyvsp[0].Number))%100; + yyMonth= ((yyvsp[0].Number)/100)%100; + yyYear = (yyvsp[0].Number)/10000; } else { yyHaveTime++; - if (yyvsp[0].Number < 100) + if ((yyvsp[0].Number) < 100) { - yyHour = yyvsp[0].Number; + yyHour = (yyvsp[0].Number); yyMinutes = 0; } else { - yyHour = yyvsp[0].Number / 100; - yyMinutes = yyvsp[0].Number % 100; + yyHour = (yyvsp[0].Number) / 100; + yyMinutes = (yyvsp[0].Number) % 100; } yySeconds = 0; yyMeridian = MER24; } } - ; - break;} -case 49: + } + break; + + case 50: #line 433 "getdate.y" -{ - yyval.Meridian = MER24; - ; - break;} -case 50: + { + (yyval.Meridian) = MER24; + } + break; + + case 51: #line 437 "getdate.y" -{ - yyval.Meridian = yyvsp[0].Meridian; - ; - break;} -} - /* the action file gets copied in in place of this dollarsign */ -#line 498 "/usr/local/share/bison.simple" + { + (yyval.Meridian) = (yyvsp[0].Meridian); + } + break; + + + } + +/* Line 1037 of yacc.c. */ +#line 1676 "y.tab.c" yyvsp -= yylen; yyssp -= yylen; -#ifdef YYLSP_NEEDED - yylsp -= yylen; -#endif -#if YYDEBUG != 0 - if (yydebug) - { - short *ssp1 = yyss - 1; - fprintf (stderr, "state stack now"); - while (ssp1 != yyssp) - fprintf (stderr, " %d", *++ssp1); - fprintf (stderr, "\n"); - } -#endif + + YY_STACK_PRINT (yyss, yyssp); *++yyvsp = yyval; -#ifdef YYLSP_NEEDED - yylsp++; - if (yylen == 0) - { - yylsp->first_line = yylloc.first_line; - yylsp->first_column = yylloc.first_column; - yylsp->last_line = (yylsp-1)->last_line; - yylsp->last_column = (yylsp-1)->last_column; - yylsp->text = 0; - } - else - { - yylsp->last_line = (yylsp+yylen-1)->last_line; - yylsp->last_column = (yylsp+yylen-1)->last_column; - } -#endif - /* Now "shift" the result of the reduction. - Determine what state that goes to, - based on the state we popped back to - and the rule number reduced by. */ + /* Now `shift' the result of the reduction. Determine what state + that goes to, based on the state we popped back to and the rule + number reduced by. */ yyn = yyr1[yyn]; - yystate = yypgoto[yyn - YYNTBASE] + *yyssp; - if (yystate >= 0 && yystate <= YYLAST && yycheck[yystate] == *yyssp) + yystate = yypgoto[yyn - YYNTOKENS] + *yyssp; + if (0 <= yystate && yystate <= YYLAST && yycheck[yystate] == *yyssp) yystate = yytable[yystate]; else - yystate = yydefgoto[yyn - YYNTBASE]; + yystate = yydefgoto[yyn - YYNTOKENS]; goto yynewstate; -yyerrlab: /* here on detecting error */ - if (! yyerrstatus) - /* If not already recovering from an error, report this error. */ +/*------------------------------------. +| yyerrlab -- here on detecting error | +`------------------------------------*/ +yyerrlab: + /* If not already recovering from an error, report this error. */ + if (!yyerrstatus) { ++yynerrs; - -#ifdef YYERROR_VERBOSE +#if YYERROR_VERBOSE yyn = yypact[yystate]; - if (yyn > YYFLAG && yyn < YYLAST) + if (YYPACT_NINF < yyn && yyn < YYLAST) { - int size = 0; - char *msg; - int x, count; - - count = 0; - /* Start X at -yyn if nec to avoid negative indexes in yycheck. */ - for (x = (yyn < 0 ? -yyn : 0); - x < (sizeof(yytname) / sizeof(char *)); x++) - if (yycheck[x + yyn] == x) - size += strlen(yytname[x]) + 15, count++; - msg = (char *) malloc(size + 15); - if (msg != 0) + YYSIZE_T yysize = 0; + int yytype = YYTRANSLATE (yychar); + const char* yyprefix; + char *yymsg; + int yyx; + + /* Start YYX at -YYN if negative to avoid negative indexes in + YYCHECK. */ + int yyxbegin = yyn < 0 ? -yyn : 0; + + /* Stay within bounds of both yycheck and yytname. */ + int yychecklim = YYLAST - yyn; + int yyxend = yychecklim < YYNTOKENS ? yychecklim : YYNTOKENS; + int yycount = 0; + + yyprefix = ", expecting "; + for (yyx = yyxbegin; yyx < yyxend; ++yyx) + if (yycheck[yyx + yyn] == yyx && yyx != YYTERROR) + { + yysize += yystrlen (yyprefix) + yystrlen (yytname [yyx]); + yycount += 1; + if (yycount == 5) + { + yysize = 0; + break; + } + } + yysize += (sizeof ("syntax error, unexpected ") + + yystrlen (yytname[yytype])); + yymsg = (char *) YYSTACK_ALLOC (yysize); + if (yymsg != 0) { - strcpy(msg, "parse error"); + char *yyp = yystpcpy (yymsg, "syntax error, unexpected "); + yyp = yystpcpy (yyp, yytname[yytype]); - if (count < 5) + if (yycount < 5) { - count = 0; - for (x = (yyn < 0 ? -yyn : 0); - x < (sizeof(yytname) / sizeof(char *)); x++) - if (yycheck[x + yyn] == x) + yyprefix = ", expecting "; + for (yyx = yyxbegin; yyx < yyxend; ++yyx) + if (yycheck[yyx + yyn] == yyx && yyx != YYTERROR) { - strcat(msg, count == 0 ? ", expecting `" : " or `"); - strcat(msg, yytname[x]); - strcat(msg, "'"); - count++; + yyp = yystpcpy (yyp, yyprefix); + yyp = yystpcpy (yyp, yytname[yyx]); + yyprefix = " or "; } } - yyerror(msg); - free(msg); + yyerror (yymsg); + YYSTACK_FREE (yymsg); } else - yyerror ("parse error; also virtual memory exceeded"); + yyerror ("syntax error; also virtual memory exhausted"); } else #endif /* YYERROR_VERBOSE */ - yyerror("parse error"); + yyerror ("syntax error"); } - goto yyerrlab1; -yyerrlab1: /* here on error raised explicitly by an action */ + if (yyerrstatus == 3) { - /* if just tried and failed to reuse lookahead token after an error, discard it. */ - - /* return failure if at end of input */ - if (yychar == YYEOF) - YYABORT; - -#if YYDEBUG != 0 - if (yydebug) - fprintf(stderr, "Discarding token %d (%s).\n", yychar, yytname[yychar1]); -#endif + /* If just tried and failed to reuse look-ahead token after an + error, discard it. */ - yychar = YYEMPTY; + if (yychar <= YYEOF) + { + /* If at end of input, pop the error token, + then the rest of the stack, then return failure. */ + if (yychar == YYEOF) + for (;;) + { + + YYPOPSTACK; + if (yyssp == yyss) + YYABORT; + yydestruct ("Error: popping", + yystos[*yyssp], yyvsp); + } + } + else + { + yydestruct ("Error: discarding", yytoken, &yylval); + yychar = YYEMPTY; + } } - /* Else will try to reuse lookahead token - after shifting the error token. */ - - yyerrstatus = 3; /* Each real token shifted decrements this */ + /* Else will try to reuse look-ahead token after shifting the error + token. */ + goto yyerrlab1; - goto yyerrhandle; -yyerrdefault: /* current state does not do anything special for the error token. */ +/*---------------------------------------------------. +| yyerrorlab -- error raised explicitly by YYERROR. | +`---------------------------------------------------*/ +yyerrorlab: -#if 0 - /* This is wrong; only states that explicitly want error tokens - should shift them. */ - yyn = yydefact[yystate]; /* If its default is to accept any token, ok. Otherwise pop it.*/ - if (yyn) goto yydefault; +#ifdef __GNUC__ + /* Pacify GCC when the user code never invokes YYERROR and the label + yyerrorlab therefore never appears in user code. */ + if (0) + goto yyerrorlab; #endif -yyerrpop: /* pop the current state because it cannot handle the error token */ +yyvsp -= yylen; + yyssp -= yylen; + yystate = *yyssp; + goto yyerrlab1; + - if (yyssp == yyss) YYABORT; - yyvsp--; - yystate = *--yyssp; -#ifdef YYLSP_NEEDED - yylsp--; -#endif +/*-------------------------------------------------------------. +| yyerrlab1 -- common code for both syntax error and YYERROR. | +`-------------------------------------------------------------*/ +yyerrlab1: + yyerrstatus = 3; /* Each real token shifted decrements this. */ -#if YYDEBUG != 0 - if (yydebug) + for (;;) { - short *ssp1 = yyss - 1; - fprintf (stderr, "Error: state stack now"); - while (ssp1 != yyssp) - fprintf (stderr, " %d", *++ssp1); - fprintf (stderr, "\n"); - } -#endif - -yyerrhandle: + yyn = yypact[yystate]; + if (yyn != YYPACT_NINF) + { + yyn += YYTERROR; + if (0 <= yyn && yyn <= YYLAST && yycheck[yyn] == YYTERROR) + { + yyn = yytable[yyn]; + if (0 < yyn) + break; + } + } - yyn = yypact[yystate]; - if (yyn == YYFLAG) - goto yyerrdefault; + /* Pop the current state because it cannot handle the error token. */ + if (yyssp == yyss) + YYABORT; - yyn += YYTERROR; - if (yyn < 0 || yyn > YYLAST || yycheck[yyn] != YYTERROR) - goto yyerrdefault; - yyn = yytable[yyn]; - if (yyn < 0) - { - if (yyn == YYFLAG) - goto yyerrpop; - yyn = -yyn; - goto yyreduce; + yydestruct ("Error: popping", yystos[yystate], yyvsp); + YYPOPSTACK; + yystate = *yyssp; + YY_STACK_PRINT (yyss, yyssp); } - else if (yyn == 0) - goto yyerrpop; if (yyn == YYFINAL) YYACCEPT; -#if YYDEBUG != 0 - if (yydebug) - fprintf(stderr, "Shifting error token, "); -#endif - *++yyvsp = yylval; -#ifdef YYLSP_NEEDED - *++yylsp = yylloc; -#endif + + + /* Shift the error token. */ + YY_SYMBOL_PRINT ("Shifting", yystos[yyn], yyvsp, yylsp); yystate = yyn; goto yynewstate; + + +/*-------------------------------------. +| yyacceptlab -- YYACCEPT comes here. | +`-------------------------------------*/ +yyacceptlab: + yyresult = 0; + goto yyreturn; + +/*-----------------------------------. +| yyabortlab -- YYABORT comes here. | +`-----------------------------------*/ +yyabortlab: + yydestruct ("Error: discarding lookahead", + yytoken, &yylval); + yychar = YYEMPTY; + yyresult = 1; + goto yyreturn; + +#ifndef yyoverflow +/*----------------------------------------------. +| yyoverflowlab -- parser overflow comes here. | +`----------------------------------------------*/ +yyoverflowlab: + yyerror ("parser stack overflow"); + yyresult = 2; + /* Fall through. */ +#endif + +yyreturn: +#ifndef yyoverflow + if (yyss != yyssa) + YYSTACK_FREE (yyss); +#endif + return yyresult; } + + #line 442 "getdate.y" @@ -1544,6 +2011,8 @@ { "nt", tZONE, HOUR (11) }, /* Nome */ { "idlw", tZONE, HOUR (12) }, /* International Date Line West */ { "cet", tZONE, -HOUR (1) }, /* Central European */ + { "cewt", tZONE, -HOUR (1) }, /* Central European Winter */ + { "cest", tZONE, -HOUR (1) }, /* Central European Summer */ { "met", tZONE, -HOUR (1) }, /* Middle European */ { "mewt", tZONE, -HOUR (1) }, /* Middle European Winter */ { "mest", tDAYZONE, -HOUR (1) }, /* Middle European Summer */ @@ -2017,3 +2486,5 @@ /* NOTREACHED */ } #endif /* defined (TEST) */ + + --- chrony-1.21z.orig/io_linux.h +++ chrony-1.21z/io_linux.h @@ -6,26 +6,24 @@ /* Hmm. These constants vary a bit between systems. */ /* (__sh__ includes both sh and sh64) */ -#if defined(__i386__) || defined(__sh__) +#if defined(__alpha__) || defined(__sparc__) || defined(__mips__) || defined(__ppc__) || defined(__ppc64__) || defined(__sparc64__) #define CHRONY_IOC_NRBITS 8 #define CHRONY_IOC_TYPEBITS 8 -#define CHRONY_IOC_SIZEBITS 14 +#define CHRONY_IOC_SIZEBITS 13 #define CHRONY_IOC_DIRBITS 2 -#define CHRONY_IOC_NONE 0U -#define CHRONY_IOC_WRITE 1U -#define CHRONY_IOC_READ 2U -#elif defined(__alpha__) || defined(__sparc__) +#define CHRONY_IOC_NONE 1U +#define CHRONY_IOC_READ 2U +#define CHRONY_IOC_WRITE 4U +#else #define CHRONY_IOC_NRBITS 8 #define CHRONY_IOC_TYPEBITS 8 -#define CHRONY_IOC_SIZEBITS 13 +#define CHRONY_IOC_SIZEBITS 14 #define CHRONY_IOC_DIRBITS 2 -#define CHRONY_IOC_NONE 1U -#define CHRONY_IOC_READ 2U -#define CHRONY_IOC_WRITE 4U -#else -#error "I don't know the values of the _IOC_* constants for your architecture" +#define CHRONY_IOC_NONE 0U +#define CHRONY_IOC_WRITE 1U +#define CHRONY_IOC_READ 2U #endif #define CHRONY_IOC_NRMASK ((1 << CHRONY_IOC_NRBITS)-1) --- chrony-1.21z.orig/chrony.txt +++ chrony-1.21z/chrony.txt @@ -353,8 +353,10 @@ Now that the software is successfully installed, the next step is to set up a configuration file. The contents of this depend on the -network environment in which the computer operates. Typical scenarios -are described in the following section of the document. +network environment in which the computer operates. The Debian package +installs a simple configuration file suitable for a dial-up pc. You +should edit it to suit your situation. Typical scenarios are described +in the following section of the document. 2.1 Support for the readline library ==================================== @@ -443,9 +445,10 @@ Assuming that you have found some servers, you need to set up a configuration file to run chrony. The (compiled-in) default location -for this file is `/etc/chrony.conf'. Assuming that your ntp servers -are called `a.b.c' and `d.e.f', your `chrony.conf' file could contain -as a minimum +for this file is `/etc/chrony.conf'. In the Debian package the +configuration files are in the directory `/etc/chrony'. Assuming that +your ntp servers are called `a.b.c' and `d.e.f', your `chrony.conf' +file could contain as a minimum server a.b.c server d.e.f @@ -516,9 +519,11 @@ In order to notify `chronyd' of the presence of the link, you will need to be able to log in to it with the program chronyc. To do this, -`chronyd' needs to be configured with an administrator password. To -set up an administrator password, you can create a file -`/etc/chrony.keys' containing a single line +`chronyd' needs to be configured with an administrator password. The +Debian package puts a randomly generated key in +`/etc/chrony/chrony.keys'. You should change it. To set up an +administrator password, you can create a file `/etc/chrony.keys' +containing a single line 1 xyzzy @@ -567,6 +572,9 @@ offline EOF + The Debian package puts scripts similar to those above in the +directories `/etc/ppp/ip-up.d' and `/etc/ppp/ip-down.d'. + `chronyd's' polling of the servers will now only occur whilst the machine is actually connected to the Internet. @@ -791,6 +799,9 @@ echo "Start chronyd" fi + The Debian package puts a script which handles this and shutdown in +`/etc/init.d/chrony'. + The placement of this command may be important on some systems. In particular, `chronyd' may need to be started several seconds (about 10 as a minimum) before any software that depends on the system clock not @@ -853,6 +864,8 @@ /usr/local/sbin/chronyd + The Debian package uses `/usr/sbin/chronyd'. + Information messages and warnings will be logged to syslog. The command line options supported are as follows: --- chrony-1.21z.orig/debian/changelog +++ chrony-1.21z/debian/changelog @@ -0,0 +1,512 @@ +chrony (1.21z-5) unstable; urgency=high + + * Applied postinst patch from Lionel Elie Mamane to test for the + existence of old .keys and .conf files before renaming them. + Closes: #397759: fails to configure: mv: cannot stat `/etc/chrony/chrony.keys.1.21-2': + No such file or directory + + * Added burst command to /etc/ppp/ip-up.d/chrony to give chronyd a kick in the butt. + Shouldn't need that, though. + Initscript now calls /etc/ppp/ip-up.d/chrony if a default route exists. + Closes: #397739: Not connecting to sources after reboot - dialup + + -- John Hasler Sun, 26 Nov 2006 08:07:20 -0600 + +chrony (1.21z-4) unstable; urgency=low + + * Added test for /usr/bin/mail to postinst. + Closes: #386651: chrony: Requires /usr/bin/mail but doesn't depend on it + Closes: #390280: chrony: missing dependency on mail + + * Added LSB headers to initscript + + * Corrected erroneous use of 'dpkg --compare-version' in preinst and postinst. + Closes: #386733: fails to configure (bad upgrade check) + + * Added rm to postinst to remove keyfile possibly left by a failed install. + Closes: #390278: usage of tempfile /etc/chrony/chrony.keys is doubtful + + -- John Hasler Sat, 7 Oct 2006 13:39:49 -0500 + +chrony (1.21z-3) unstable; urgency=low + + * Changed upstream version number from 1.21 to 1.21z to satisfy Debian + archive software. + + * Replaced impure chrony_1.21.orig.tar.gz. + Closes: #340030: chrony: Tarball is impure + + * Now Provides, Conflicts, Replaces time-daemon + Closes: #330839: time-daemon pseudopackage + + * Corrected typos. + Closes: #321121: chrony: typo in 'Conflicts:' field: s/ntpsimple/ntp-simple/ and s/ntprefclock/ntp-refclock/ + + * Rewrote postinst and postrm to use ucf. Wrote preinst to protect chrony.conf from dpkg. + Closes: #351332: chrony: conffile change prompt prevents smooth upgrade from sarge to etch + + * Deleted last few lines of chrony.conf as they no longer apply. + + * Deleted .arch-ids from contrib and examples. + + * Fixed typo in chronyc.1 + Closes: #349871: chrony: typo in chrnoyc.1 results in missing word + + * Corrected references in man pages. + Closes: #345034: chrony: man pages refer to wrong sections + + * Added "allow 172.16/12" to chrony.conf. + Closes: #252952: chrony: default allow should also have 172.16/12 + + * Channged server lines in chrony.conf to follow ntp.org current recommendation. + Closes: #243534: chrony: new pool.ntp.org setup doesn't work well + + * Fixed FSF address in debian/copyright. + + -- John Hasler Fri, 1 Sep 2006 10:52:52 -0500 + +chrony (1.21-2) unstable; urgency=high + + * Patched io_linux.h to add missing architectures. + Closes: #339764: chrony - FTBFS: #error "I don't know the values of the + _IOC_* constants for your architecture" + + * Fixed brown-bag error in rules. + Closes: #339853: /usr/sbin/chronyd is missing + + -- John Hasler Sat, 19 Nov 2005 10:12:49 -0600 + +chrony (1.21-1) unstable; urgency=low + + * New upstream release + Closes: #328292: New version of chrony avalaible + Closes: #301592: Fails to read RTC and floods logfiles + + * Enabled RTC as upstream has installed a work-around for the HPET bug. + + * Switched to libreadline5. + Closes: #326379: please rebuild with libreadline5-dev as build dependency + + * Patched addrfilt.c to fix gcc 4.0 build problem. + Closes: #298709: chrony: FTBFS (amd64/gcc-4.0): array type has incomplete element type + + * There are lots more minor things to fix but I'm uploading now to close + the serious bugs. I'll upload another version with some improvements + in a few weeks. + + -- John Hasler Tue, 15 Nov 2005 18:39:49 -0600 + +chrony (1.20-8) unstable; urgency=high + + * Added test for /usr/bin/mail in postinst. + Closes: #307061: Install failure: Cannot configure on system without mailx + I consider this bug serious because it can cause installation to fail + and so I want to get the fix into Sarge. + + * Fixed typo in chrony.conf, replaced '/etc/init.d/chrony restart' + with 'invoke-rc.d chrony restart'. + Closes: #305090: Typo in chrony.conf, should mention invoke-rc.d + + * Added README.Debian explaining that rtc is off by default. + + -- John Hasler Sat, 30 Apr 2005 18:47:30 -0500 + +chrony (1.20-7) unstable; urgency=low + + * Added info-4 to debian/rules. + Closes: #287142: chrony: Can't find chrony.info-4 + + * Corrected "See Also" section in chrony man page. Now mentions + chronyc(1), chronyd(8), and chrony.conf(5). + Closes: #287444: chrony.1.gz: SEE ALSO on man page has wrong section. + + * Edited chrony.conf to disable rtc by default and explain why: + on some systems that use genrtc or the HPET real-time clock it + fails and causes chronyd to fill up the log. The failure is + probably due to a kernel bug, bug the logging should be + throttled. + + * Added more explanatory comments at the servers directive in + chrony.conf. + + * The postinst script now sends a message to root saying where the + password is, whether Chrony is assuming UTC or local time, + that rtc updating is disabled, why, and how to change it. + + * Added missing '#' to + "Can't tell how your clock is set: assuming local time." + in postinst. + + -- John Hasler Tue, 12 Apr 2005 17:59:13 -0500 + +chrony (1.20-6) unstable; urgency=low + + * Fixed error in chrony.conf where the non-existent 'online' directive + was mentioned. + Closes: #257235 misleading instructions in chrony.conf + + * Patched Makefile.in to generate faq.html. + Closes: #265936 /usr/share/doc/chrony/faq.txt.gz: how to read? + + -- John Hasler Sat, 4 Dec 2004 17:47:31 -0600 + +chrony (1.20-5) unstable; urgency=low + + * Put pool.ntp.org servers in chrony.conf as defaults. + + * Fixed erroneous references to chronyd(1) in some man pages. + Closes: #241746 SEE ALSO chronyd(1) should be (8) + + * I got a new motherboard and can no longer reproduce this. + If you can please reopen the bug. + Closes: #223518 Rtc stuff is broken + + * Edited chrony.conf(5). + Closes: #241745 many more features have been added + + * Edited chrony.conf to add logchange and mailonchange and to + enable rtc by default. + Closes: #226644 /etc/chrony/chrony.conf: rtc; not all options are noted in conf file + + * Fixed upstream: see NEWS. + Closes: #124089 mistake in the chrony manual + Closes: #177366: trailing blank on log lines + Closes: #195618 failure to use /dev/misc/rtc floods logfiles + Closes: #53066 "acquisitionport" directive and doc fixes [patch] + Closes: #100880 RFE: don't use /proc when uname(2) will do + Closes: #163470: different bindaddresses for ntp port and control port + Closes: #200174: Chrony breaks under Kernel 2.5 (two bugs) + + -- John Hasler Sat, 10 Apr 2004 22:00:00 -0500 + +chrony (1.20-4) unstable; urgency=low + + * Added '#include ' to rtc_linux.c to fix Alpha build problem. + Also removed spinlock stuff from configure. + + -- John Hasler Fri, 26 Dec 2003 21:00:00 -0600 + +chrony (1.20-3) unstable; urgency=low + + * Removed all inclusions of kernel headers. + Hopefully Chrony will now build on m68k. + + -- John Hasler Tue, 23 Dec 2003 19:00:00 -0600 + +chrony (1.20-2) unstable; urgency=low + + * Removed spinlock.h and mc146818.h from rtc_linux.c. linux/rtc.h and + RTC_UIE=0x10 provide everything needed now. + Closes: #223134 FTBFS: Errors in kernel headers + + * However, rtc is now broken (and appears to have been broken for some time) + on 440BX chipsets with 2.4 kernels. + + -- John Hasler Fri, 12 Dec 2003 13:00:00 -0600 + +chrony (1.20-1) unstable; urgency=low + + * New upstream release. + + * Frank Otto's patch to sys_linux.c, function guess_hz_and_shift_hz now + incorporated upstream. + Closes: #198557 Fatal error: chronyd can't determine hz for kernel with HZ=200 + + * Security and 64 bit patches are now incorporated upstream + along with most non-i386 architecture patches. + + * Put correct links in /usr/share/doc/chrony/timeservers. + Closes: #189686 /usr/share/doc/timeservers links are broken + + * Put correct links in chrony.conf. + Closes: #210886 bad link in chrony.conf + + * Put missing newlines in apm and chrony.keys. + Closes: #211604 Build-warning: some files misses final newline + + * Removed conflict with ntpdate. + + -- John Hasler Tue, 7 Oct 2003 22:00:00 -0500 + +chrony (1.19-10) unstable; urgency=low + + * Put linux/linkage.h ahead of linux/spinlock.h as I meant to in + the first place. + + -- John Hasler Sun, 13 Jul 2003 7:00:00 -0500 + +chrony (1.19-9) unstable; urgency=low + + * Added "#include " to rtc_linux.c to fix mips + build failure. + Closes: #200165 chrony doesn't build on mips and mipsel + + -- John Hasler Sat, 12 Jul 2003 10:00:00 -0500 + +chrony (1.19-8) unstable; urgency=low + + * Added bison to build-depends because of addition of getdate.y + + -- John Hasler Tue, 3 Jun 2003 10:00:00 -0500 + +chrony (1.19-7) unstable; urgency=high + + * Closes: #186498 chronyc hangs if no chronyd is running + Added test for running daemon to ip-{up|down} scripts. + Disabled trimrtc for ALPHA + Closes: #195615 GPL violation - generated file without source + * Added a copy of getdate.y to source. + + -- John Hasler Sun, 1 Jun 2003 7:00:00 -0500 + +chrony (1.19-6) unstable; urgency=low + + * Closes: #179842 "CROAK" redefined + Added '#undef CROAK' before CROAK redefiniton in pktlength.h, + added '-DALPHA' to 'alpha' condition in configure, added + 'ifdef ALPHA' around CROAK redefinition. + * Replaced many signed and unsigned longs as well as some ints, + shorts, and chars with stdint.h types in candm.h, md5.h, ntp.h, + clientlog.h, and ntp_io.c. This should fix all 64-bit problems. + + -- John Hasler Fri, 14 Mar 2003 19:00:00 -0600 + +chrony (1.19-5) unstable; urgency=high + + * Closes: #184065 Assertion `sizeof(NTP_int32) == 4' failed on alpha + Fixed several spots where the author assumed that a long is 32 bits. + There are many more misuses of long as well as several of short and + char but I think I got the only ones likely to cause trouble. + + -- John Hasler Fri, 14 Mar 2003 11:00:00 -0600 + +chrony (1.19-4) unstable; urgency=low + + * Closes: #179538 FTBFS: missing build-depends on makeinfo + Added texinfo to build-depends. + * CLoses: #179508: chrony(c|d) show wrong version numbers + Removed spurious version.h. + + -- John Hasler Sun, 2 Feb 2003 19:00:00 -0600 + +chrony (1.19-3) unstable; urgency=low + + * Updated author's address in copyright file. + * Closes: #163446 patch, that scripts can handle all commandkeys + Applied debugged patch. + * Closes: #107863 doesn't know about APM + Put apm script in debian/ and added rules to copy it to + etc/apm/event.d as instructed by the apmd maintainer. + + -- John Hasler Fri, 31 Jan 2003 18:00:00 -0600 + +chrony (1.19-2) unstable; urgency=low + + * Closes: #100879 unnecessary dependency on libm + Applied patch from Zack Weinberg + * Closes: #124091 the force-reload command of /etc/init.d/chrony should + use the -r option. + Added -r option. + + -- John Hasler Wed, 29 Jan 2003 10:00:00 -0600 + +chrony (1.19-1) unstable; urgency=low + + * New upstream release. + * Closes: #178338 New upstream version fixes crashes caused by adjtimex + failure + * Closes: #178101 /etc/ppp/ip-{up,down}.d/chrony installed with + incorrect permissions + This bug was previously reported and fixed in 18-1 + * Closes: #176130 got an error when I use ppp_on_boot + Changed 'update-rc.d chrony defaults 83' to + 'update-rc.d chrony defaults 14' in init.d so that chrony + will come up before ppp. + * Added code to postinst to read /etc/default/rcS and + set rtconutc appropriately in chrony.conf. + * Rewrote password generator in postinst. + * Closes: #100879 unnecessary dependency on libm + I don't know why this wasn't closed months ago. + * Closes: #103447 typo in "/etc/init.d/chrony" + * Closes: #124087 problems with /etc/init.d/chrony + Fixed script. + * Closes: #161350 /etc/ppp/ip-down.d/chrony cat unnecessary + Fixed scripts. + * Closes: #113840 ntp has been split - add conflicts? + Added ntp-simple and ntp-refclock to conflicts. + + -- John Hasler Sun, 26 Jan 2003 15:00:00 -0600 + +chrony (1.18-2) unstable; urgency=low + + * Corrects error in changelog which resulted + in uploads being erroneously classified as NMUs. + * Closes: #138142, #104774, #142670, #105344, #101039 + * Closes: #162427, #56756, #98951, #99799, #139633 + * Closes: #163469, #163408, #167416 + + -- John Hasler Sun, 3 Nov 2002 20:00:00 -0600 + +chrony (1.18-1) unstable; urgency=low + + * New upstream release. + * Closes: #138142 new upstream release + * Added Mark Brown's Alpha and PowerPC patch. + * Closes: #104774 hppa build failure + Applied patch. + * Closes: #142670 compilation errors on sparc + Applied patch. + * Closes: #105344 ip-{up, down}.d/chrony not executable + Fixed debian/rules. + * Closes: #101039 does not run on Alpha + Fixed by above mentioned Mark Brown patch. + * Closes: #162427 description should mention NTP + Fixed description. + * Closes: #56756 README.debian should caution about hwclock + Fixed README.debian. + * Closes: #98951 no chrony.keys file installed + Not reproducible, probable user error. + * Closes: #99799 logs world readable + Added umask 022 to log script. + * Closes: #139633 documentation error + Added rtconutc to chrony.conf. + * Closes: #163469 no default case in init.d script + Corrected typo. + * Closes: #163408 PIDFILE wrongly defined in ip-{up,down} + No chrony script uses any such variable. + * Closes: #167416 needs Build-Depends: libreadline4-dev + + -- Sun, 3 Nov 2002 10:00:00 -0600 + +chrony (1.14-7) unstable; urgency=medium + + * Changed rtc_linux.c to not include linux/mc146818rtc.h + when building for sparc, because Moshe Zadka says this + will allow chrony to build there. + * Closes: #142670 + + -- Wed, 17 Apr 2002 17:00:00 -0500 + +chrony (1.14-6) unstable; urgency=low + + * Changed architecture back to 'any'. + * Applied portability patch from LaMont Jones. + * Closes: #104774 + + -- Mon, 1 Apr 2002 21:00:00 -0600 + +chrony (1.14-5) unstable; urgency=low + + * Changed architecture from 'any' to 'i386 sparc'. + Neither I nor the author can test on anything but i386. If + you want chrony on anything else send me a tested patch. + * Closes: #101039 + * Closes: #104774 + + -- Fri, 28 Dec 2001 20:10:00 -0600 + +chrony (1.14-4) unstable; urgency=low + + * Fixed bug in man pages. + * Closes: #95134 + + -- Tue, 24 Apr 2001 20:10:00 -0500 + +chrony (1.14-3) unstable; urgency=low + + * Replaced in rtc_linux.c with + typedef int spinlock_t as suggested by Paul Slootman. + * Put #define CROAK(message) assert(0) in pktlength.h + to fix Alpha build problem. + * Closes: #86991 + + -- Sat, 24 Feb 2001 22:45:00 -0600 + +chrony (1.14-2) unstable; urgency=low + + * Closes: #84597 + + -- Sat, 3 Feb 2001 21:25:00 -0600 + +chrony (1.14-1) unstable; urgency=low + + * New upstream release. + * Fixed more sprintfs. + * Closes: #50793, #52570, #48216, #65209, #62924, #70377, #61485, #76661 + + -- Mon, 20 Nov 2000 20:25:00 -0600 + +chrony (1.10-3) unstable; urgency=low + + * Patched cron,weekly script with (corrected) patch + from Rene H. Larsen . + * Updated author address in copyright file. + * Compiled with egcs. + * Closes: #41885, #41551 + + -- Sun, 25 July 1999 12:14:00 -0500 + +chrony (1.10-2) unstable; urgency=low + + * Patched rtc_linux.c with patch for SPARC from + bmc@visi.net. + + -- Mon, 17 May 1999 22:30:00 -0500 + +chrony (1.10-1) unstable; urgency=low + + * New upstream release. + * Upstream version number is 1.1. Debian version + number is 1.10 because previous upstream number + was 1.02. + + -- Wed, 12 May 1999 20:30:00 -0500 + +chrony (1.02-7) unstable; urgency=low + + * Changed configure to permit building on non-Intel. + + -- Wed, 5 May 1999 18:00:00 -0500 + +chrony (1.02-6) unstable; urgency=low + + * Fixed postrm bug. + + -- Thur, 29 Apr 1999 18:00:00 -0500 + +chrony (1.02-5) unstable; urgency=low + + * Fixed bugs 34954 and 36921. + * Moved to priority extra. + * Added README.debian text about rtc. + + -- Thur, 15 Apr 1999 21:30:00 -0500 + +chrony (1.02-4) unstable; urgency=low + + * Replaced sprintf's with snprintf's. + + -- Sun, 28 Feb 1999 16:53:00 -0600 + +chrony (1.02-3) unstable; urgency=low + + * Fixed bugs in cron.weekly, ip-up.d, and ip-down.d. + * Bug 29981 is also fixed. + + -- Sun, 6 Dec 1998 9:53:00 -0600 + +chrony (1.02-2) unstable; urgency=low + + * Added cron.weekly. + * Changed ip-up.d, ip-down.d, and cron.weekly to read the + password from chrony.keys. + * Added code to postinst to generate a random password and + put it in chrony.keys. + + -- Thur, 3 Dec 1998 19:00:08 -0600 + +chrony (1.02-1) unstable; urgency=low + + * Initial Release. + + -- Fri, 6 Nov 1998 23:00:08 -0600 --- chrony-1.21z.orig/debian/docs +++ chrony-1.21z/debian/docs @@ -0,0 +1 @@ +NEWS README debian/NEWS.Debian chrony.lsm chrony.texi chrony.txt chrony.html faq.txt faq.html examples --- chrony-1.21z.orig/debian/chrony.cron.weekly +++ chrony-1.21z/debian/chrony.cron.weekly @@ -0,0 +1,21 @@ +#!/bin/sh +# Log rotation script for chrony John Hasler +# This script is published under the same license as chrony. + +set -e + +[ -d /var/log/chrony/. ] || exit 0 +[ -x /usr/sbin/chronyd ] || exit 0 +umask 022 +cd /var/log/chrony +[ "`ls -1A *.log 2>/dev/null`" ] || exit 0 +for FILE in *.log + do + savelog -c 7 $FILE > /dev/null +done +PASSWORD=`awk '$1 ~ /^1$/ {print $2; exit}' /etc/chrony/chrony.keys` +cat << EOF | /usr/bin/chronyc | sed '/^200 OK$/d' +password $PASSWORD +cyclelogs +EOF +exit 0 --- chrony-1.21z.orig/debian/README.Debian +++ chrony-1.21z/debian/README.Debian @@ -0,0 +1,44 @@ +chrony for DEBIAN +---------------------- + + I made the following changes to the chrony distribution to package it for + Debian: + + Added /etc/chrony and moved the config files there from /etc. This the + only change to the source code. + + Added a few lines to the info files explaining how the Debian installation + differs from the standard one. I also used texi2html to generate html + docs. + + Created default /etc/chrony/chrony.conf, /etc/chrony/chrony.keys, + /etc/init.d/chrony, /etc/ppp/ip-up.d/chrony, /etc/cron.weekly/chrony, and + /etc/ppp/ip-down.d/chrony files and arranged for them to be installed + automatically. + + Arranged for a random password to be generated at installation time and + installed in chrony.keys as key 1 (unless chrony.keys already has + something in it). You may change this password if you wish. + + The standard Debian chrony installation is designed for systems with an + intermittent dial-up connection. If you have such a system the most you + should need to do is edit /etc/chrony/chrony.conf a bit. If you do not + you should read the documentation and create an appropriate configuration + (you should read the documentation anyway). + + The scripts /etc/ppp/ip-up.d/chrony, /etc/ppp/ip-down.d/chrony, and + /etc/cron.weekly/chrony read key 1 from /etc/chrony/chrony.keys and use it + as the password to send chronyc commands. Thus you can change the + password by changing this key, but if you make the command key anything + but 1 these scripts won't work without editing. + + As installed, chronyd will be started on bootup and will attempt to + contact the default server whenever you connect to your ISP. + + Use 'info chrony' to read the complete documentation. + + + John Hasler , 5 Oct 2003 + + + -- John Hasler , Sun Oct 9 12:57:57 2005 --- chrony-1.21z.orig/debian/control +++ chrony-1.21z/debian/control @@ -0,0 +1,25 @@ +Source: chrony +Section: admin +Priority: extra +Maintainer: John Hasler +Standards-Version: 3.7.2.1 +Build-Depends: debhelper (>= 4), libreadline5-dev | libreadline-dev, texinfo, bison + +Package: chrony +Architecture: any +Depends: ${shlibs:Depends}, ucf +Conflicts: ntp, ntp-simple, ntp-refclock, time-daemon +Provides: time-daemon +Replaces: time-daemon +Description: Sets your computer's clock from time servers on the Net + It consists of a pair of programs : + `chronyd'. This is a daemon which runs in background on the system. It + obtains measurements (e.g. via the network) of the system's offset + relative to other systems, and adjusts the system time accordingly. For + isolated systems, the user can periodically enter the correct time by hand + (using `chronyc'). In either case, `chronyd' determines the rate at which + the computer gains or loses time, and compensates for this. Chronyd + implements the NTP protocol and can act as either a client or a server. + `chronyc'. This is a command-line driven control and monitoring program. + An administrator can use this to fine-tune various parameters within the + daemon, add or delete servers etc whilst the daemon is running. --- chrony-1.21z.orig/debian/copyright +++ chrony-1.21z/debian/copyright @@ -0,0 +1,28 @@ +This is the Debian GNU/Linux packaged version of Chrony. + +Downloaded from: + +Author(s): Richard Curnow + +License: GNU General Public License (GPL) + +Program Copyright (C) 1998-2003 Richard Curnow +Modifications for Debian Copyright (C) 2000-2003 John Hasler +Debian scripts and files licensed under the GPL except where otherwise +noted. + +This program is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2, or (at your option) +any later version. + +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 with your +Debian GNU/Linux system, in /usr/share/common-licenses/GPL, and with the +Debian GNU/Linux chrony package as the file COPYING. If not, write to the +Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA +02110-1301, USA. --- chrony-1.21z.orig/debian/dirs +++ chrony-1.21z/debian/dirs @@ -0,0 +1,11 @@ +usr/bin +usr/sbin +usr/share/info +usr/share/chrony +etc/chrony +etc/ppp/ip-up.d +etc/ppp/ip-down.d +etc/cron.weekly +etc/apm/event.d +var/log/chrony +var/lib/chrony --- chrony-1.21z.orig/debian/apm +++ chrony-1.21z/debian/apm @@ -0,0 +1,17 @@ +#!/bin/sh + +# Placed in /etc/apm/event.d by the chrony package at the instruction of +# the apmd maintainer. If you don't have apm and don't intend to install +# apmd you may remove it. It needs to run after 00hwclock but before any +# other scripts. + + +[ -x /usr/sbin/chronyd ] || exit 0 + +if [ "$1" = suspend ]; then + /etc/init.d/chrony stop +elif [ "$1" = standby ]; then + /etc/init.d/chrony stop +elif [ "$1" = resume ]; then + /etc/init.d/chrony start +fi --- chrony-1.21z.orig/debian/info +++ chrony-1.21z/debian/info @@ -0,0 +1,15 @@ +# This is a configuration files for installing a .info menu +# The Description to be placed into the directory +DESCR="Set your clock from the Net" + +# The section this info file should be placed in (Regexp) followed by +# the new section name to be created if the Regexp does not match +# (Optional. If not given the .info will be appended to the directory) +SECTION_MATCH="General Commamds" +#SECTION_NAME="New Section Name" + +# The file referred to from the Info directory +FILE=chrony.info + +# Optional. The files to be copied to /usr/share/info +FILES=chrony.info-* --- chrony-1.21z.orig/debian/init.d +++ chrony-1.21z/debian/init.d @@ -0,0 +1,59 @@ +#! /bin/sh +# +# This file was automatically customized by debmake on Fri, 6 Nov 1998 23:00:08 -0600 +# +# Written by Miquel van Smoorenburg . +# Modified for Debian GNU/Linux by Ian Murdock . +# Modified for Debian by Christoph Lameter +# Modified for chrony by John Hasler 1998-2006 + +### BEGIN INIT INFO +# Provides: time-daemon +# Required-Start: $local_fs +# Required-Stop: $local_fs +# Default-Start: 2 3 4 5 +# Default-Stop: 0 1 6 +# Short-Decription: Controls chronyd NTP time daemon +# Description: Chronyd is the NTP time daemon in the Chrony package +# +### END INIT INFO + + +PATH=/bin:/usr/bin:/sbin:/usr/sbin +DAEMON=/usr/sbin/chronyd +FLAGS="defaults" +NAME="chronyd" +DESC="time daemon" + +test -f $DAEMON || exit 0 + +case "$1" in + start) + start-stop-daemon --start --verbose --exec $DAEMON + sleep 1 + route 2>/dev/null | grep -q default && /etc/ppp/ip-up.d/chrony > /dev/null || true + ;; + stop) + start-stop-daemon --stop --verbose --oknodo --exec $DAEMON + ;; + restart|force-reload) + # + # If the "reload" option is implemented, move the "force-reload" + # option to the "reload" entry above. If not, "force-reload" is + # just the same as "restart". + # + echo -n "Restarting $DESC: " + start-stop-daemon --stop --quiet --exec $DAEMON + sleep 1 + start-stop-daemon --start --quiet --exec $DAEMON -- -r + sleep 1 + route 2>/dev/null | grep -q default && /etc/ppp/ip-up.d/chrony > /dev/null || true + echo "$NAME." + ;; + *) + echo "Usage: /etc/init.d/chrony {start|stop|restart|force-reload}" + exit 1 + ;; +esac + +exit 0 --- chrony-1.21z.orig/debian/ip-down +++ chrony-1.21z/debian/ip-down @@ -0,0 +1,18 @@ +#!/bin/sh +# This script tells chronyd that the connection is down +# so that it won't try to contact the server. +# John Hasler 1998-2003 +# Any possessor of a copy of this program may treat it as if it +# were in the public domain. I waive all rights. + +/bin/pidof chronyd > /dev/null || exit 0 +# Don't mark the connection offline unless we know ppp brought it up. +test -e /var/run/chrony-ppp-up || exit 0 +KEY=$(awk '$1 ~ /^commandkey$/ { print $2; exit}' /etc/chrony/chrony.conf) +PASSWORD=`awk '$1 ~ /^'$KEY'$/ {print $2; exit}' /etc/chrony/chrony.keys` +/usr/bin/chronyc << EOF +password $PASSWORD +offline +EOF +rm -f /var/run/chrony-ppp-up +exit 0 --- chrony-1.21z.orig/debian/postinst +++ chrony-1.21z/debian/postinst @@ -0,0 +1,93 @@ +#!/bin/sh +set -e +# postinst for Chrony John Hasler jhasler@debian.org 2000-2006 +# Any possessor of a copy of this program may treat it as if it +# were in the public domain. I waive all rights. + +install-info --quiet --description="Set your clock from the Net" \ + --section General "General Commands" \ + /usr/share/info/chrony.info + +if [ -x /usr/bin/update-menus ] ; then + /usr/bin/update-menus +fi + +update-rc.d chrony defaults 83 >/dev/null + +cp /usr/share/chrony/chrony.conf /etc/chrony/chrony.conf.new + +# Fix up chrony.conf.new. +. /etc/default/rcS + +case "$UTC" in + no|"") echo "# rtconutc" >> /etc/chrony/chrony.conf.new + MAILUTC="Chrony has been configured to assume that your real-time clock is on local time. +If this is not correct edit /etc/chrony/chrony.conf. The comments explain +what to do." + ;; + yes) echo "rtconutc" >> /etc/chrony/chrony.conf.new + MAILUTC="Chrony has been configured to assume that your real-time clock is on UTC time. +If this is not correct edit /etc/chrony/chrony.conf. The comments explain +what to do." + ;; + *) echo "# Can't tell how your clock is set: assuming local time." >> /etc/chrony/chrony.conf.new + MAILUTC="Can't tell how your clock is set: assuming local time. +If this is not correct edit /etc/chrony/chrony.conf. The comments explain +what to do." + ;; +esac + +if [ -z "$2" ] ; then + +# As this a new install generate a key. Remove any keyfile left by a failed install. + rm -rf /etc/chrony/chrony.keys + KEYFILE=`tempfile -m 640 -n /etc/chrony/chrony.keys` + PASSWORD=`head -c 8 /dev/urandom | tr '\0-\377' 'a-zA-Z0-9a-zA-Z0-9a-zA-Z0-9a-zA-Z0-9@@@@####'` + echo "1 $PASSWORD" > $KEYFILE + MAILPASSWORD="The password for chronyc is in $KEYFILE." + +# And tell root about the key and the rtc setting. + if `which /usr/bin/mail > /dev/null`; then + /usr/bin/mail -s "Chrony" root < 1998-2003 +# Any possessor of a copy of this program may treat it as if it +# were in the public domain. I waive all rights. + +/bin/pidof chronyd > /dev/null || exit 0 +KEY=$(awk '$1 ~ /^commandkey$/ { print $2; exit}' /etc/chrony/chrony.conf) +PASSWORD=`awk '$1 ~ /^'$KEY'$/ {print $2; exit}' /etc/chrony/chrony.keys` +/usr/bin/chronyc << EOF +password $PASSWORD +online +burst 5/10 +quit +EOF +touch /var/run/chrony-ppp-up +exit 0 --- chrony-1.21z.orig/debian/menu +++ chrony-1.21z/debian/menu @@ -0,0 +1,7 @@ +?package(chrony):needs="text" section="Apps/System"\ + title="chronyc"\ + command="/usr/bin/chronyc" + +?package(chrony):needs="dwww" section="Apps/System"\ + title="chrony"\ + command="/usr/share/doc/chrony/chrony.html" --- chrony-1.21z.orig/debian/rules +++ chrony-1.21z/debian/rules @@ -0,0 +1,85 @@ +#!/usr/bin/make -f +# Made with the aid of dh_make, by Craig Small +# Sample debian/rules that uses debhelper. GNU copyright 1997 by Joey Hess. +# Some lines taken from debmake, by Cristoph Lameter. + +# Uncomment this to turn on verbose mode. +#export DH_VERBOSE=1 + +build: build-stamp +build-stamp: + dh_testdir + + ./configure --prefix='' + # Add here commands to compile the package. + $(MAKE) + $(MAKE) docs + + touch build-stamp + +clean: + dh_testdir + dh_testroot + rm -f build-stamp install-stamp debian/substvars + + # Add here commands to clean up after the build process. + -$(MAKE) distclean + + dh_clean + +install: install-stamp +install-stamp: build-stamp + dh_testdir + dh_testroot + dh_clean -k + dh_installdirs + + # Add here commands to install the package into debian/tmp. + $(MAKE) install DESTDIR=`pwd`/debian/chrony/usr MANDIR=/share/man + + touch install-stamp + +# Build architecture-independent files here. +binary-indep: build install + chmod 755 faqgen.pl + ./faqgen.pl < faq.txt > faq.html + +# Build architecture-dependent files here. +binary-arch: build install + dh_testdir + dh_testroot + dh_installdocs + dh_installexamples + dh_installmenu -n + dh_installinit -n + dh_installcron + dh_installmanpages + dh_installchangelogs + cp chrony.conf debian/chrony/usr/share/chrony + cp debian/chrony.conf.md5sum debian/chrony/usr/share/chrony +# cp chrony.keys debian/chrony/etc/chrony + cp chrony.info debian/chrony/usr/share/info +# cp chrony.info-1 debian/chrony/usr/share/info +# cp chrony.info-2 debian/chrony/usr/share/info +# cp chrony.info-3 debian/chrony/usr/share/info +# cp chrony.info-4 debian/chrony/usr/share/info + cp debian/ip-up debian/chrony/etc/ppp/ip-up.d/chrony + cp debian/ip-down debian/chrony/etc/ppp/ip-down.d/chrony + cp debian/apm debian/chrony/etc/apm/event.d/01chrony + chmod 755 debian/chrony/etc/apm/event.d/01chrony + dh_strip + dh_compress + dh_fixperms +# chmod 640 debian/chrony/etc/chrony/chrony.keys + chmod 755 debian/chrony/etc/ppp/ip-up.d/chrony debian/chrony/etc/ppp/ip-down.d/chrony + dh_installdeb + dh_shlibdeps + dh_gencontrol + dh_md5sums + dh_builddeb + +source diff: + @echo >&2 'source and diff are obsolete - use dpkg-source -b'; false + +binary: binary-indep binary-arch +.PHONY: build clean binary-indep binary-arch binary --- chrony-1.21z.orig/debian/postrm +++ chrony-1.21z/debian/postrm @@ -0,0 +1,27 @@ +#!/bin/sh +set -e +# postrm for chrony John Hasler 1998-2006 +# Any possessor of a copy of this program may treat it as if it +# were in the public domain. I waive all rights. +rm -f /var/lib/chrony/* +if [ -x /usr/bin/update-menus ] ; then + /usr/bin/update-menus +fi + +if [ "$1" = "purge" ] ; then + rm -rf /etc/chrony/chrony.conf + if which ucf >/dev/null; then + ucf --purge /etc/chrony/chrony.conf + fi + if which ucfr >/dev/null; then + ucfr --purge chrony /etc/chrony/chrony.conf + fi + rm -rf /var/lib/chrony + rm -rf /usr/share/chrony + rm -rf /var/log/chrony + rm -rf /etc/cron.weekly/chrony + rm -rf /etc/ppp/ip-up.d/chrony + rm -rf /etc/ppp/ip-down.d/chrony + rm -rf /etc/chrony + update-rc.d chrony remove >/dev/null +fi --- chrony-1.21z.orig/debian/NEWS.Debian +++ chrony-1.21z/debian/NEWS.Debian @@ -0,0 +1,7 @@ +Upstream has fixed the HPET error message problem so updating of the +real-time clock has been enabled. However, RTC may still not work on +systems with HPET: it just won't flood the log. + +The 'z' in the version number did not originate upstream. I had to add +it to satisfy the Debian archive software after I corrected my error of +uploading an impure tarball. --- chrony-1.21z.orig/debian/prerm +++ chrony-1.21z/debian/prerm @@ -0,0 +1,9 @@ +#!/bin/sh +set -e +# Automatically added by dh_installinit +install-info --quiet --remove /usr/share/info/chrony.info.gz +invoke-rc.d chrony stop +if [ \( "$1" = "upgrade" -o "$1" = "remove" \) -a -L /usr/doc/chrony ]; then + rm -f /usr/doc/chrony +fi +# End automatically added section --- chrony-1.21z.orig/debian/compat +++ chrony-1.21z/debian/compat @@ -0,0 +1,2 @@ +4 + --- chrony-1.21z.orig/debian/chrony.conf.md5sum +++ chrony-1.21z/debian/chrony.conf.md5sum @@ -0,0 +1,13 @@ +12c80f691647404d2d2d1b5968e17c9e 1.02 1.1 1.11 +fb9535a2ea2d2e37982bd9b2f88e250f 1.14 +a4eebb09b3b64eb2a70d10ce8dca6355 1.18 +06982a6408a9a1f11527b85be4ec0fa5 1.18utc +c1f02986969a96b703c6186bad4e6bf2 1.18local +9ae8f1387d735443d2b92b31e5a00ef9 1.19utc +8fa54f1a30ef49a264e1698509e6cf8e 1.19local +173025a98967b787dfde8fa392a9a7d8 1.20utc +8c84bf44d4e2f33a1b4489492c7c6b8b 1.20local +2a3cae322728b3ccd6b6ac55a27c9a0a 1.20-7utc +48afe34ec356273025a4fe923da0edff 1.20-7local +05719ae54c6ce3b9cf8b5ccb91ee75e3 1.21utc +e2136bc1890f7dac747f605f7cb61af1 1.21local --- chrony-1.21z.orig/debian/preinst +++ chrony-1.21z/debian/preinst @@ -0,0 +1,23 @@ +#!/bin/sh +set -e +# preinst for Chrony John G. Hasler jhasler@debian.org 2006 +# Any possessor of a copy of this program may treat it as if it +# were in the public domain. I waive all rights. + +case "$1" in + install|upgrade) + +# If we are upgrading from an old version protect the keys and +# conf files from dpkg. + + if dpkg --compare-versions "$2" lt-nl 1.21-3 ; then + mv /etc/chrony/chrony.keys /etc/chrony/chrony.keys."$2" + mv /etc/chrony/chrony.conf /etc/chrony/chrony.conf."$2" + fi + ;; + + *) + exit 0 + ;; +esac +exit 0 --- chrony-1.21z.orig/chrony.conf +++ chrony-1.21z/chrony.conf @@ -0,0 +1,87 @@ +# This the default chrony.conf file for the Debian chrony package. It is +# suitable for a system with an intermittent dial-up connection. After +# editing this file use the command 'invoke-rc.d chrony restart' to make +# your changes take effect. +# John Hasler 3 Dec. 1998 + +# See www.pool.ntp.org for an explanation of these servers. Please +# consider joining the project if possible. If you can't or don't want to +# use these servers I suggest that you try your ISP's nameservers. We mark +# the servers 'offline' so that chronyd won't try to connect when the link +# is down. Scripts in /etc/ppp/ip-up.d and /etc/ppp/ip-down.d use chronyc +# commands to switch it on when the link comes up and off when it goes +# down. If you have an always-on connection such as cable omit the +# 'offline' directive and chronyd will default to online. + +server 0.pool.ntp.org offline minpoll 8 +server 1.pool.ntp.org offline minpoll 8 +server 2.pool.ntp.org offline minpoll 8 + +# Look here for the admin password needed for chronyc. The initial +# password is generated by a random process at install time. You may +# change it if you wish. + +keyfile /etc/chrony/chrony.keys + +# Set runtime command key. Note that if you change the key (not the +# password) to anything other than 1 you will need to edit +# /etc/ppp/ip-up.d/chrony, /etc/ppp/ip-down.d/chrony, and +# /etc/cron.weekly/chrony as these scripts use it to get the password. + +commandkey 1 + +# I moved the driftfile to /var/lib/chrony to comply with the Debian +# filesystem standard. + +driftfile /var/lib/chrony/chrony.drift + +# Comment this line out to turn off logging. + +log tracking measurements statistics +logdir /var/log/chrony + +# Stop bad estimates upsetting machine clock. + +maxupdateskew 100.0 + +# Dump measurements when daemon exits. + +dumponexit + +# Specify directory for dumping measurements. + +dumpdir /var/lib/chrony + +# Let computer be a server when it is unsynchronised. + +local stratum 10 + +# Allow computers on the unrouted nets 10 and 192.168 to use the server. + +allow 10/8 +allow 192.168/16 +allow 172.16/12 + +# This directive forces `chronyd' to send a message to syslog if it +# makes a system clock adjustment larger than a threshold value in seconds. + +logchange 0.5 + +# This directive defines an email address to which mail should be sent +# if chronyd applies a correction exceeding a particular threshold to the +# system clock. + +# mailonchange root@localhost 0.5 + +# This directive tells chrony to regulate the real-time clock and tells it +# Where to store related data. It may not work on some newer motherboards +# that use the HPET real-time clock. It requires enhanced real-time +# support in the kernel. + +rtcfile /var/lib/chrony/chrony.rtc + +# If the last line of this file reads 'rtconutc' chrony will assume that +# the CMOS clock is on UTC (GMT). If it reads '# rtconutc' or is absent +# chrony will assume local time. The line (if any) was written by the +# chrony postinst based on what it found in /etc/default/rcS. You may +# change it if necessary. --- chrony-1.21z.orig/version.h +++ chrony-1.21z/version.h @@ -0,0 +1,4 @@ +#ifndef VERSION_H +#define VERSION_H 1 +#define PROGRAM_VERSION_STRING "1.21" +#endif /* VERSION_H */ --- chrony-1.21z.orig/getdate.y +++ chrony-1.21z/getdate.y @@ -0,0 +1,1026 @@ +%{ +/* +** Originally written by Steven M. Bellovin while +** at the University of North Carolina at Chapel Hill. Later tweaked by +** a couple of people on Usenet. Completely overhauled by Rich $alz +** and Jim Berets in August, 1990; +** +** This grammar has 13 shift/reduce conflicts. +** +** This code is in the public domain and has no copyright. +*/ + +#ifdef HAVE_CONFIG_H +# include +# ifdef FORCE_ALLOCA_H +# include +# endif +#endif + +/* Since the code of getdate.y is not included in the Emacs executable + itself, there is no need to #define static in this file. Even if + the code were included in the Emacs executable, it probably + wouldn't do any harm to #undef it here; this will only cause + problems if we try to write to a static variable, which I don't + think this code needs to do. */ +#ifdef emacs +# undef static +#endif + +#include +#include + +#if defined (STDC_HEADERS) || (!defined (isascii) && !defined (HAVE_ISASCII)) +# define IN_CTYPE_DOMAIN(c) 1 +#else +# define IN_CTYPE_DOMAIN(c) isascii(c) +#endif + +#define ISSPACE(c) (IN_CTYPE_DOMAIN (c) && isspace (c)) +#define ISALPHA(c) (IN_CTYPE_DOMAIN (c) && isalpha (c)) +#define ISUPPER(c) (IN_CTYPE_DOMAIN (c) && isupper (c)) +#define ISDIGIT_LOCALE(c) (IN_CTYPE_DOMAIN (c) && isdigit (c)) + +/* ISDIGIT differs from ISDIGIT_LOCALE, as follows: + - Its arg may be any int or unsigned int; it need not be an unsigned char. + - It's guaranteed to evaluate its argument exactly once. + - It's typically faster. + Posix 1003.2-1992 section 2.5.2.1 page 50 lines 1556-1558 says that + only '0' through '9' are digits. Prefer ISDIGIT to ISDIGIT_LOCALE unless + it's important to use the locale's definition of `digit' even when the + host does not conform to Posix. */ +#define ISDIGIT(c) ((unsigned) (c) - '0' <= 9) + +#include "getdate.h" + +#if defined (STDC_HEADERS) || defined (USG) +# include +#endif + +/* Some old versions of bison generate parsers that use bcopy. + That loses on systems that don't provide the function, so we have + to redefine it here. */ +#if !defined (HAVE_BCOPY) && defined (HAVE_MEMCPY) && !defined (bcopy) +# define bcopy(from, to, len) memcpy ((to), (from), (len)) +#endif + +extern struct tm *gmtime (); +extern struct tm *localtime (); +extern time_t mktime (); + +/* Remap normal yacc parser interface names (yyparse, yylex, yyerror, etc), + as well as gratuitiously global symbol names, so we can have multiple + yacc generated parsers in the same program. Note that these are only + the variables produced by yacc. If other parser generators (bison, + byacc, etc) produce additional global names that conflict at link time, + then those parser generators need to be fixed instead of adding those + names to this list. */ + +#define yymaxdepth gd_maxdepth +#define yyparse gd_parse +#define yylex gd_lex +#define yyerror gd_error +#define yylval gd_lval +#define yychar gd_char +#define yydebug gd_debug +#define yypact gd_pact +#define yyr1 gd_r1 +#define yyr2 gd_r2 +#define yydef gd_def +#define yychk gd_chk +#define yypgo gd_pgo +#define yyact gd_act +#define yyexca gd_exca +#define yyerrflag gd_errflag +#define yynerrs gd_nerrs +#define yyps gd_ps +#define yypv gd_pv +#define yys gd_s +#define yy_yys gd_yys +#define yystate gd_state +#define yytmp gd_tmp +#define yyv gd_v +#define yy_yyv gd_yyv +#define yyval gd_val +#define yylloc gd_lloc +#define yyreds gd_reds /* With YYDEBUG defined */ +#define yytoks gd_toks /* With YYDEBUG defined */ +#define yylhs gd_yylhs +#define yylen gd_yylen +#define yydefred gd_yydefred +#define yydgoto gd_yydgoto +#define yysindex gd_yysindex +#define yyrindex gd_yyrindex +#define yygindex gd_yygindex +#define yytable gd_yytable +#define yycheck gd_yycheck + +static int yylex (); +static int yyerror (); + +#define EPOCH 1970 +#define HOUR(x) ((x) * 60) + +#define MAX_BUFF_LEN 128 /* size of buffer to read the date into */ + +/* +** An entry in the lexical lookup table. +*/ +typedef struct _TABLE { + const char *name; + int type; + int value; +} TABLE; + + +/* +** Meridian: am, pm, or 24-hour style. +*/ +typedef enum _MERIDIAN { + MERam, MERpm, MER24 +} MERIDIAN; + + +/* +** Global variables. We could get rid of most of these by using a good +** union as the yacc stack. (This routine was originally written before +** yacc had the %union construct.) Maybe someday; right now we only use +** the %union very rarely. +*/ +static const char *yyInput; +static int yyDayOrdinal; +static int yyDayNumber; +static int yyHaveDate; +static int yyHaveDay; +static int yyHaveRel; +static int yyHaveTime; +static int yyHaveZone; +static int yyTimezone; +static int yyDay; +static int yyHour; +static int yyMinutes; +static int yyMonth; +static int yySeconds; +static int yyYear; +static MERIDIAN yyMeridian; +static int yyRelDay; +static int yyRelHour; +static int yyRelMinutes; +static int yyRelMonth; +static int yyRelSeconds; +static int yyRelYear; + +%} + +%union { + int Number; + enum _MERIDIAN Meridian; +} + +%token tAGO tDAY tDAY_UNIT tDAYZONE tDST tHOUR_UNIT tID +%token tMERIDIAN tMINUTE_UNIT tMONTH tMONTH_UNIT +%token tSEC_UNIT tSNUMBER tUNUMBER tYEAR_UNIT tZONE + +%type tDAY tDAY_UNIT tDAYZONE tHOUR_UNIT tMINUTE_UNIT +%type tMONTH tMONTH_UNIT +%type tSEC_UNIT tSNUMBER tUNUMBER tYEAR_UNIT tZONE +%type tMERIDIAN o_merid + +%% + +spec : /* NULL */ + | spec item + ; + +item : time { + yyHaveTime++; + } + | zone { + yyHaveZone++; + } + | date { + yyHaveDate++; + } + | day { + yyHaveDay++; + } + | rel { + yyHaveRel++; + } + | number + ; + +time : tUNUMBER tMERIDIAN { + yyHour = $1; + yyMinutes = 0; + yySeconds = 0; + yyMeridian = $2; + } + | tUNUMBER ':' tUNUMBER o_merid { + yyHour = $1; + yyMinutes = $3; + yySeconds = 0; + yyMeridian = $4; + } + | tUNUMBER ':' tUNUMBER tSNUMBER { + yyHour = $1; + yyMinutes = $3; + yyMeridian = MER24; + yyHaveZone++; + yyTimezone = ($4 < 0 + ? -$4 % 100 + (-$4 / 100) * 60 + : - ($4 % 100 + ($4 / 100) * 60)); + } + | tUNUMBER ':' tUNUMBER ':' tUNUMBER o_merid { + yyHour = $1; + yyMinutes = $3; + yySeconds = $5; + yyMeridian = $6; + } + | tUNUMBER ':' tUNUMBER ':' tUNUMBER tSNUMBER { + yyHour = $1; + yyMinutes = $3; + yySeconds = $5; + yyMeridian = MER24; + yyHaveZone++; + yyTimezone = ($6 < 0 + ? -$6 % 100 + (-$6 / 100) * 60 + : - ($6 % 100 + ($6 / 100) * 60)); + } + ; + +zone : tZONE { + yyTimezone = $1; + } + | tDAYZONE { + yyTimezone = $1 - 60; + } + | + tZONE tDST { + yyTimezone = $1 - 60; + } + ; + +day : tDAY { + yyDayOrdinal = 1; + yyDayNumber = $1; + } + | tDAY ',' { + yyDayOrdinal = 1; + yyDayNumber = $1; + } + | tUNUMBER tDAY { + yyDayOrdinal = $1; + yyDayNumber = $2; + } + ; + +date : tUNUMBER '/' tUNUMBER { + yyMonth = $1; + yyDay = $3; + } + | tUNUMBER '/' tUNUMBER '/' tUNUMBER { + /* Interpret as YYYY/MM/DD if $1 >= 1000, otherwise as MM/DD/YY. + The goal in recognizing YYYY/MM/DD is solely to support legacy + machine-generated dates like those in an RCS log listing. If + you want portability, use the ISO 8601 format. */ + if ($1 >= 1000) + { + yyYear = $1; + yyMonth = $3; + yyDay = $5; + } + else + { + yyMonth = $1; + yyDay = $3; + yyYear = $5; + } + } + | tUNUMBER tSNUMBER tSNUMBER { + /* ISO 8601 format. yyyy-mm-dd. */ + yyYear = $1; + yyMonth = -$2; + yyDay = -$3; + } + | tUNUMBER tMONTH tSNUMBER { + /* e.g. 17-JUN-1992. */ + yyDay = $1; + yyMonth = $2; + yyYear = -$3; + } + | tMONTH tUNUMBER { + yyMonth = $1; + yyDay = $2; + } + | tMONTH tUNUMBER ',' tUNUMBER { + yyMonth = $1; + yyDay = $2; + yyYear = $4; + } + | tUNUMBER tMONTH { + yyMonth = $2; + yyDay = $1; + } + | tUNUMBER tMONTH tUNUMBER { + yyMonth = $2; + yyDay = $1; + yyYear = $3; + } + ; + +rel : relunit tAGO { + yyRelSeconds = -yyRelSeconds; + yyRelMinutes = -yyRelMinutes; + yyRelHour = -yyRelHour; + yyRelDay = -yyRelDay; + yyRelMonth = -yyRelMonth; + yyRelYear = -yyRelYear; + } + | relunit + ; + +relunit : tUNUMBER tYEAR_UNIT { + yyRelYear += $1 * $2; + } + | tSNUMBER tYEAR_UNIT { + yyRelYear += $1 * $2; + } + | tYEAR_UNIT { + yyRelYear += $1; + } + | tUNUMBER tMONTH_UNIT { + yyRelMonth += $1 * $2; + } + | tSNUMBER tMONTH_UNIT { + yyRelMonth += $1 * $2; + } + | tMONTH_UNIT { + yyRelMonth += $1; + } + | tUNUMBER tDAY_UNIT { + yyRelDay += $1 * $2; + } + | tSNUMBER tDAY_UNIT { + yyRelDay += $1 * $2; + } + | tDAY_UNIT { + yyRelDay += $1; + } + | tUNUMBER tHOUR_UNIT { + yyRelHour += $1 * $2; + } + | tSNUMBER tHOUR_UNIT { + yyRelHour += $1 * $2; + } + | tHOUR_UNIT { + yyRelHour += $1; + } + | tUNUMBER tMINUTE_UNIT { + yyRelMinutes += $1 * $2; + } + | tSNUMBER tMINUTE_UNIT { + yyRelMinutes += $1 * $2; + } + | tMINUTE_UNIT { + yyRelMinutes += $1; + } + | tUNUMBER tSEC_UNIT { + yyRelSeconds += $1 * $2; + } + | tSNUMBER tSEC_UNIT { + yyRelSeconds += $1 * $2; + } + | tSEC_UNIT { + yyRelSeconds += $1; + } + ; + +number : tUNUMBER + { + if (yyHaveTime && yyHaveDate && !yyHaveRel) + yyYear = $1; + else + { + if ($1>10000) + { + yyHaveDate++; + yyDay= ($1)%100; + yyMonth= ($1/100)%100; + yyYear = $1/10000; + } + else + { + yyHaveTime++; + if ($1 < 100) + { + yyHour = $1; + yyMinutes = 0; + } + else + { + yyHour = $1 / 100; + yyMinutes = $1 % 100; + } + yySeconds = 0; + yyMeridian = MER24; + } + } + } + ; + +o_merid : /* NULL */ + { + $$ = MER24; + } + | tMERIDIAN + { + $$ = $1; + } + ; + +%% + +/* Month and day table. */ +static TABLE const MonthDayTable[] = { + { "january", tMONTH, 1 }, + { "february", tMONTH, 2 }, + { "march", tMONTH, 3 }, + { "april", tMONTH, 4 }, + { "may", tMONTH, 5 }, + { "june", tMONTH, 6 }, + { "july", tMONTH, 7 }, + { "august", tMONTH, 8 }, + { "september", tMONTH, 9 }, + { "sept", tMONTH, 9 }, + { "october", tMONTH, 10 }, + { "november", tMONTH, 11 }, + { "december", tMONTH, 12 }, + { "sunday", tDAY, 0 }, + { "monday", tDAY, 1 }, + { "tuesday", tDAY, 2 }, + { "tues", tDAY, 2 }, + { "wednesday", tDAY, 3 }, + { "wednes", tDAY, 3 }, + { "thursday", tDAY, 4 }, + { "thur", tDAY, 4 }, + { "thurs", tDAY, 4 }, + { "friday", tDAY, 5 }, + { "saturday", tDAY, 6 }, + { NULL } +}; + +/* Time units table. */ +static TABLE const UnitsTable[] = { + { "year", tYEAR_UNIT, 1 }, + { "month", tMONTH_UNIT, 1 }, + { "fortnight", tDAY_UNIT, 14 }, + { "week", tDAY_UNIT, 7 }, + { "day", tDAY_UNIT, 1 }, + { "hour", tHOUR_UNIT, 1 }, + { "minute", tMINUTE_UNIT, 1 }, + { "min", tMINUTE_UNIT, 1 }, + { "second", tSEC_UNIT, 1 }, + { "sec", tSEC_UNIT, 1 }, + { NULL } +}; + +/* Assorted relative-time words. */ +static TABLE const OtherTable[] = { + { "tomorrow", tMINUTE_UNIT, 1 * 24 * 60 }, + { "yesterday", tMINUTE_UNIT, -1 * 24 * 60 }, + { "today", tMINUTE_UNIT, 0 }, + { "now", tMINUTE_UNIT, 0 }, + { "last", tUNUMBER, -1 }, + { "this", tMINUTE_UNIT, 0 }, + { "next", tUNUMBER, 2 }, + { "first", tUNUMBER, 1 }, +/* { "second", tUNUMBER, 2 }, */ + { "third", tUNUMBER, 3 }, + { "fourth", tUNUMBER, 4 }, + { "fifth", tUNUMBER, 5 }, + { "sixth", tUNUMBER, 6 }, + { "seventh", tUNUMBER, 7 }, + { "eighth", tUNUMBER, 8 }, + { "ninth", tUNUMBER, 9 }, + { "tenth", tUNUMBER, 10 }, + { "eleventh", tUNUMBER, 11 }, + { "twelfth", tUNUMBER, 12 }, + { "ago", tAGO, 1 }, + { NULL } +}; + +/* The timezone table. */ +static TABLE const TimezoneTable[] = { + { "gmt", tZONE, HOUR ( 0) }, /* Greenwich Mean */ + { "ut", tZONE, HOUR ( 0) }, /* Universal (Coordinated) */ + { "utc", tZONE, HOUR ( 0) }, + { "wet", tZONE, HOUR ( 0) }, /* Western European */ + { "bst", tDAYZONE, HOUR ( 0) }, /* British Summer */ + { "wat", tZONE, HOUR ( 1) }, /* West Africa */ + { "at", tZONE, HOUR ( 2) }, /* Azores */ +#if 0 + /* For completeness. BST is also British Summer, and GST is + * also Guam Standard. */ + { "bst", tZONE, HOUR ( 3) }, /* Brazil Standard */ + { "gst", tZONE, HOUR ( 3) }, /* Greenland Standard */ +#endif +#if 0 + { "nft", tZONE, HOUR (3.5) }, /* Newfoundland */ + { "nst", tZONE, HOUR (3.5) }, /* Newfoundland Standard */ + { "ndt", tDAYZONE, HOUR (3.5) }, /* Newfoundland Daylight */ +#endif + { "ast", tZONE, HOUR ( 4) }, /* Atlantic Standard */ + { "adt", tDAYZONE, HOUR ( 4) }, /* Atlantic Daylight */ + { "est", tZONE, HOUR ( 5) }, /* Eastern Standard */ + { "edt", tDAYZONE, HOUR ( 5) }, /* Eastern Daylight */ + { "cst", tZONE, HOUR ( 6) }, /* Central Standard */ + { "cdt", tDAYZONE, HOUR ( 6) }, /* Central Daylight */ + { "mst", tZONE, HOUR ( 7) }, /* Mountain Standard */ + { "mdt", tDAYZONE, HOUR ( 7) }, /* Mountain Daylight */ + { "pst", tZONE, HOUR ( 8) }, /* Pacific Standard */ + { "pdt", tDAYZONE, HOUR ( 8) }, /* Pacific Daylight */ + { "yst", tZONE, HOUR ( 9) }, /* Yukon Standard */ + { "ydt", tDAYZONE, HOUR ( 9) }, /* Yukon Daylight */ + { "hst", tZONE, HOUR (10) }, /* Hawaii Standard */ + { "hdt", tDAYZONE, HOUR (10) }, /* Hawaii Daylight */ + { "cat", tZONE, HOUR (10) }, /* Central Alaska */ + { "ahst", tZONE, HOUR (10) }, /* Alaska-Hawaii Standard */ + { "nt", tZONE, HOUR (11) }, /* Nome */ + { "idlw", tZONE, HOUR (12) }, /* International Date Line West */ + { "cet", tZONE, -HOUR (1) }, /* Central European */ + { "cewt", tZONE, -HOUR (1) }, /* Central European Winter */ + { "cest", tZONE, -HOUR (1) }, /* Central European Summer */ + { "met", tZONE, -HOUR (1) }, /* Middle European */ + { "mewt", tZONE, -HOUR (1) }, /* Middle European Winter */ + { "mest", tDAYZONE, -HOUR (1) }, /* Middle European Summer */ + { "mesz", tDAYZONE, -HOUR (1) }, /* Middle European Summer */ + { "swt", tZONE, -HOUR (1) }, /* Swedish Winter */ + { "sst", tDAYZONE, -HOUR (1) }, /* Swedish Summer */ + { "fwt", tZONE, -HOUR (1) }, /* French Winter */ + { "fst", tDAYZONE, -HOUR (1) }, /* French Summer */ + { "eet", tZONE, -HOUR (2) }, /* Eastern Europe, USSR Zone 1 */ + { "bt", tZONE, -HOUR (3) }, /* Baghdad, USSR Zone 2 */ +#if 0 + { "it", tZONE, -HOUR (3.5) },/* Iran */ +#endif + { "zp4", tZONE, -HOUR (4) }, /* USSR Zone 3 */ + { "zp5", tZONE, -HOUR (5) }, /* USSR Zone 4 */ +#if 0 + { "ist", tZONE, -HOUR (5.5) },/* Indian Standard */ +#endif + { "zp6", tZONE, -HOUR (6) }, /* USSR Zone 5 */ +#if 0 + /* For completeness. NST is also Newfoundland Standard, and SST is + * also Swedish Summer. */ + { "nst", tZONE, -HOUR (6.5) },/* North Sumatra */ + { "sst", tZONE, -HOUR (7) }, /* South Sumatra, USSR Zone 6 */ +#endif /* 0 */ + { "wast", tZONE, -HOUR (7) }, /* West Australian Standard */ + { "wadt", tDAYZONE, -HOUR (7) }, /* West Australian Daylight */ +#if 0 + { "jt", tZONE, -HOUR (7.5) },/* Java (3pm in Cronusland!) */ +#endif + { "cct", tZONE, -HOUR (8) }, /* China Coast, USSR Zone 7 */ + { "jst", tZONE, -HOUR (9) }, /* Japan Standard, USSR Zone 8 */ +#if 0 + { "cast", tZONE, -HOUR (9.5) },/* Central Australian Standard */ + { "cadt", tDAYZONE, -HOUR (9.5) },/* Central Australian Daylight */ +#endif + { "east", tZONE, -HOUR (10) }, /* Eastern Australian Standard */ + { "eadt", tDAYZONE, -HOUR (10) }, /* Eastern Australian Daylight */ + { "gst", tZONE, -HOUR (10) }, /* Guam Standard, USSR Zone 9 */ + { "nzt", tZONE, -HOUR (12) }, /* New Zealand */ + { "nzst", tZONE, -HOUR (12) }, /* New Zealand Standard */ + { "nzdt", tDAYZONE, -HOUR (12) }, /* New Zealand Daylight */ + { "idle", tZONE, -HOUR (12) }, /* International Date Line East */ + { NULL } +}; + +/* Military timezone table. */ +static TABLE const MilitaryTable[] = { + { "a", tZONE, HOUR ( 1) }, + { "b", tZONE, HOUR ( 2) }, + { "c", tZONE, HOUR ( 3) }, + { "d", tZONE, HOUR ( 4) }, + { "e", tZONE, HOUR ( 5) }, + { "f", tZONE, HOUR ( 6) }, + { "g", tZONE, HOUR ( 7) }, + { "h", tZONE, HOUR ( 8) }, + { "i", tZONE, HOUR ( 9) }, + { "k", tZONE, HOUR ( 10) }, + { "l", tZONE, HOUR ( 11) }, + { "m", tZONE, HOUR ( 12) }, + { "n", tZONE, HOUR (- 1) }, + { "o", tZONE, HOUR (- 2) }, + { "p", tZONE, HOUR (- 3) }, + { "q", tZONE, HOUR (- 4) }, + { "r", tZONE, HOUR (- 5) }, + { "s", tZONE, HOUR (- 6) }, + { "t", tZONE, HOUR (- 7) }, + { "u", tZONE, HOUR (- 8) }, + { "v", tZONE, HOUR (- 9) }, + { "w", tZONE, HOUR (-10) }, + { "x", tZONE, HOUR (-11) }, + { "y", tZONE, HOUR (-12) }, + { "z", tZONE, HOUR ( 0) }, + { NULL } +}; + + + + +/* ARGSUSED */ +static int +yyerror (s) + char *s; +{ + return 0; +} + +static int +ToHour (Hours, Meridian) + int Hours; + MERIDIAN Meridian; +{ + switch (Meridian) + { + case MER24: + if (Hours < 0 || Hours > 23) + return -1; + return Hours; + case MERam: + if (Hours < 1 || Hours > 12) + return -1; + if (Hours == 12) + Hours = 0; + return Hours; + case MERpm: + if (Hours < 1 || Hours > 12) + return -1; + if (Hours == 12) + Hours = 0; + return Hours + 12; + default: + abort (); + } + /* NOTREACHED */ +} + +static int +ToYear (Year) + int Year; +{ + if (Year < 0) + Year = -Year; + + /* XPG4 suggests that years 00-68 map to 2000-2068, and + years 69-99 map to 1969-1999. */ + if (Year < 69) + Year += 2000; + else if (Year < 100) + Year += 1900; + + return Year; +} + +static int +LookupWord (buff) + char *buff; +{ + register char *p; + register char *q; + register const TABLE *tp; + int i; + int abbrev; + + /* Make it lowercase. */ + for (p = buff; *p; p++) + if (ISUPPER (*p)) + *p = tolower (*p); + + if (strcmp (buff, "am") == 0 || strcmp (buff, "a.m.") == 0) + { + yylval.Meridian = MERam; + return tMERIDIAN; + } + if (strcmp (buff, "pm") == 0 || strcmp (buff, "p.m.") == 0) + { + yylval.Meridian = MERpm; + return tMERIDIAN; + } + + /* See if we have an abbreviation for a month. */ + if (strlen (buff) == 3) + abbrev = 1; + else if (strlen (buff) == 4 && buff[3] == '.') + { + abbrev = 1; + buff[3] = '\0'; + } + else + abbrev = 0; + + for (tp = MonthDayTable; tp->name; tp++) + { + if (abbrev) + { + if (strncmp (buff, tp->name, 3) == 0) + { + yylval.Number = tp->value; + return tp->type; + } + } + else if (strcmp (buff, tp->name) == 0) + { + yylval.Number = tp->value; + return tp->type; + } + } + + for (tp = TimezoneTable; tp->name; tp++) + if (strcmp (buff, tp->name) == 0) + { + yylval.Number = tp->value; + return tp->type; + } + + if (strcmp (buff, "dst") == 0) + return tDST; + + for (tp = UnitsTable; tp->name; tp++) + if (strcmp (buff, tp->name) == 0) + { + yylval.Number = tp->value; + return tp->type; + } + + /* Strip off any plural and try the units table again. */ + i = strlen (buff) - 1; + if (buff[i] == 's') + { + buff[i] = '\0'; + for (tp = UnitsTable; tp->name; tp++) + if (strcmp (buff, tp->name) == 0) + { + yylval.Number = tp->value; + return tp->type; + } + buff[i] = 's'; /* Put back for "this" in OtherTable. */ + } + + for (tp = OtherTable; tp->name; tp++) + if (strcmp (buff, tp->name) == 0) + { + yylval.Number = tp->value; + return tp->type; + } + + /* Military timezones. */ + if (buff[1] == '\0' && ISALPHA (*buff)) + { + for (tp = MilitaryTable; tp->name; tp++) + if (strcmp (buff, tp->name) == 0) + { + yylval.Number = tp->value; + return tp->type; + } + } + + /* Drop out any periods and try the timezone table again. */ + for (i = 0, p = q = buff; *q; q++) + if (*q != '.') + *p++ = *q; + else + i++; + *p = '\0'; + if (i) + for (tp = TimezoneTable; tp->name; tp++) + if (strcmp (buff, tp->name) == 0) + { + yylval.Number = tp->value; + return tp->type; + } + + return tID; +} + +static int +yylex () +{ + register char c; + register char *p; + char buff[20]; + int Count; + int sign; + + for (;;) + { + while (ISSPACE (*yyInput)) + yyInput++; + + if (ISDIGIT (c = *yyInput) || c == '-' || c == '+') + { + if (c == '-' || c == '+') + { + sign = c == '-' ? -1 : 1; + if (!ISDIGIT (*++yyInput)) + /* skip the '-' sign */ + continue; + } + else + sign = 0; + for (yylval.Number = 0; ISDIGIT (c = *yyInput++);) + yylval.Number = 10 * yylval.Number + c - '0'; + yyInput--; + if (sign < 0) + yylval.Number = -yylval.Number; + return sign ? tSNUMBER : tUNUMBER; + } + if (ISALPHA (c)) + { + for (p = buff; (c = *yyInput++, ISALPHA (c)) || c == '.';) + if (p < &buff[sizeof buff - 1]) + *p++ = c; + *p = '\0'; + yyInput--; + return LookupWord (buff); + } + if (c != '(') + return *yyInput++; + Count = 0; + do + { + c = *yyInput++; + if (c == '\0') + return c; + if (c == '(') + Count++; + else if (c == ')') + Count--; + } + while (Count > 0); + } +} + +#define TM_YEAR_ORIGIN 1900 + +/* Yield A - B, measured in seconds. */ +static long +difftm (a, b) + struct tm *a, *b; +{ + int ay = a->tm_year + (TM_YEAR_ORIGIN - 1); + int by = b->tm_year + (TM_YEAR_ORIGIN - 1); + long days = ( + /* difference in day of year */ + a->tm_yday - b->tm_yday + /* + intervening leap days */ + + ((ay >> 2) - (by >> 2)) + - (ay / 100 - by / 100) + + ((ay / 100 >> 2) - (by / 100 >> 2)) + /* + difference in years * 365 */ + + (long) (ay - by) * 365 + ); + return (60 * (60 * (24 * days + (a->tm_hour - b->tm_hour)) + + (a->tm_min - b->tm_min)) + + (a->tm_sec - b->tm_sec)); +} + +time_t +get_date (p, now) + const char *p; + const time_t *now; +{ + struct tm tm, tm0, *tmp; + time_t Start; + + yyInput = p; + Start = now ? *now : time ((time_t *) NULL); + tmp = localtime (&Start); + yyYear = tmp->tm_year + TM_YEAR_ORIGIN; + yyMonth = tmp->tm_mon + 1; + yyDay = tmp->tm_mday; + yyHour = tmp->tm_hour; + yyMinutes = tmp->tm_min; + yySeconds = tmp->tm_sec; + yyMeridian = MER24; + yyRelSeconds = 0; + yyRelMinutes = 0; + yyRelHour = 0; + yyRelDay = 0; + yyRelMonth = 0; + yyRelYear = 0; + yyHaveDate = 0; + yyHaveDay = 0; + yyHaveRel = 0; + yyHaveTime = 0; + yyHaveZone = 0; + + if (yyparse () + || yyHaveTime > 1 || yyHaveZone > 1 || yyHaveDate > 1 || yyHaveDay > 1) + return -1; + + tm.tm_year = ToYear (yyYear) - TM_YEAR_ORIGIN + yyRelYear; + tm.tm_mon = yyMonth - 1 + yyRelMonth; + tm.tm_mday = yyDay + yyRelDay; + if (yyHaveTime || (yyHaveRel && !yyHaveDate && !yyHaveDay)) + { + tm.tm_hour = ToHour (yyHour, yyMeridian); + if (tm.tm_hour < 0) + return -1; + tm.tm_min = yyMinutes; + tm.tm_sec = yySeconds; + } + else + { + tm.tm_hour = tm.tm_min = tm.tm_sec = 0; + } + tm.tm_hour += yyRelHour; + tm.tm_min += yyRelMinutes; + tm.tm_sec += yyRelSeconds; + tm.tm_isdst = -1; + tm0 = tm; + + Start = mktime (&tm); + + if (Start == (time_t) -1) + { + + /* Guard against falsely reporting errors near the time_t boundaries + when parsing times in other time zones. For example, if the min + time_t value is 1970-01-01 00:00:00 UTC and we are 8 hours ahead + of UTC, then the min localtime value is 1970-01-01 08:00:00; if + we apply mktime to 1970-01-01 00:00:00 we will get an error, so + we apply mktime to 1970-01-02 08:00:00 instead and adjust the time + zone by 24 hours to compensate. This algorithm assumes that + there is no DST transition within a day of the time_t boundaries. */ + if (yyHaveZone) + { + tm = tm0; + if (tm.tm_year <= EPOCH - TM_YEAR_ORIGIN) + { + tm.tm_mday++; + yyTimezone -= 24 * 60; + } + else + { + tm.tm_mday--; + yyTimezone += 24 * 60; + } + Start = mktime (&tm); + } + + if (Start == (time_t) -1) + return Start; + } + + if (yyHaveDay && !yyHaveDate) + { + tm.tm_mday += ((yyDayNumber - tm.tm_wday + 7) % 7 + + 7 * (yyDayOrdinal - (0 < yyDayOrdinal))); + Start = mktime (&tm); + if (Start == (time_t) -1) + return Start; + } + + if (yyHaveZone) + { + long delta = yyTimezone * 60L + difftm (&tm, gmtime (&Start)); + if ((Start + delta < Start) != (delta < 0)) + return -1; /* time_t overflow */ + Start += delta; + } + + return Start; +} + +#if defined (TEST) + +/* ARGSUSED */ +int +main (ac, av) + int ac; + char *av[]; +{ + char buff[MAX_BUFF_LEN + 1]; + time_t d; + + (void) printf ("Enter date, or blank line to exit.\n\t> "); + (void) fflush (stdout); + + buff[MAX_BUFF_LEN] = 0; + while (fgets (buff, MAX_BUFF_LEN, stdin) && buff[0]) + { + d = get_date (buff, (time_t *) NULL); + if (d == -1) + (void) printf ("Bad format - couldn't convert.\n"); + else + (void) printf ("%s", ctime (&d)); + (void) printf ("\t> "); + (void) fflush (stdout); + } + exit (0); + /* NOTREACHED */ +} +#endif /* defined (TEST) */ --- chrony-1.21z.orig/timeservers +++ chrony-1.21z/timeservers @@ -0,0 +1,4 @@ +Lists of public timeservers: +http://www.eecis.udel.edu/~mills/ntp/clock1a.html +http://www.eecis.udel.edu/~mills/ntp/clock2a.html + --- chrony-1.21z.orig/chrony.html +++ chrony-1.21z/chrony.html @@ -0,0 +1,4672 @@ + + +User guide for the chrony suite + + + + + + + + + +

User guide for the chrony suite

+
+

+Next: , +Up: (dir) +
+
+ +

User guide for the chrony suite

+ + + + + +
+

+Next: , +Previous: Top, +Up: Top +
+
+ +

1 Introduction

+ + + + +
+

+Next: , +Up: Introduction +
+
+ +

1.1 Overview

+ +

Chrony is a software package for maintaining the accuracy of computer +system clocks. It consists of a pair of programs : + +

    +
  • chronyd. This is a daemon which runs in background on the +system. It obtains measurements (e.g. via the network) of the system's +offset relative to other systems, and adjusts the system time +accordingly. For isolated systems, the user can periodically enter the +correct time by hand (using chronyc). In either case, +chronyd determines the rate at which the computer gains or loses +time, and compensates for this. + +

    chronyd can also act as an NTP server, and provide a time-of-day service +to other computers. A typical set-up is to run chronyd on a gateway +computer that has a dial-up link to the Internet, and use it to serve time to +computers on a private LAN sitting behind the gateway. The IP addresses that +can act as clients of chronyd can be tightly controlled. The default is +no client access. + +

  • chronyc. This is a command-line driven control and +monitoring program. An administrator can use this to fine-tune various +parameters within the daemon, add or delete servers etc whilst the +daemon is running. + +

    The IP addresses from which chronyc clients may connect can be tightly +controlled. The default is just the computer that chronyd itself is +running on. +

+ + +
+

+Next: , +Previous: Overview, +Up: Introduction +
+
+ +

1.2 Acknowledgements

+ +

The chrony suite makes use of the algorithm known as RSA +Data Security, Inc. MD5 Message-Digest Algorithm for authenticating +messages between different machines on the network. + +

In writing the chronyd program, extensive use has been made of +RFC1305, written by David Mills. I have occasionally referred to the +xntp suite's source code to check details of the protocol that +the RFC did not make absolutely clear. The core algorithms in +chronyd are all completely distinct from xntp, however. + + +

+

+Next: , +Previous: Acknowledgements, +Up: Introduction +
+
+ +

1.3 Availability

+ + + +
+

+Next: , +Up: Availability +
+
+ +

1.3.1 Getting the software

+ +

Links on the chrony home page describe how to obtain the software. + +

+

+Previous: Getting the software, +Up: Availability +
+
+ +

1.3.2 Platforms

+ +

Although most of the program is portable between +Unix-like systems, there are parts that have to be tailored to each +specific vendor's system. These are the parts that interface with the +operating system's facilities for adjusting the system clock; +different operating systems may provide different function calls to +achieve this, and even where the same function is used it may have +different quirks in its behaviour. + +

The software is known to work in the following environments: +

    +
  • Linux/i386 and Linux/ppc. The software is known to work on Linux 2.0.x, +2.2.x and 2.4.x. Prior to 2.0.31, the real time clock can't be used. + +
  • NetBSD +
  • BSD/386 + +
  • Solaris 2.3/2.5/2.5.1/2.6/2.7/2.8 on Sparc (Sparc 20, Ultrasparc) and +i386 + +
  • SunOS 4.1.4 on Sparc 2 and Sparc20. +
+ +

Closely related systems may work too, but they have not been tested. + +

Porting the software to other system (particularly to those supporting +an adjtime system call) should not be difficult, however it +requires access to such systems to test out the driver. + + +

+

+Next: , +Previous: Availability, +Up: Introduction +
+
+ +

1.4 Relationship to other software packages

+ + + +
+

+Next: , +Up: Other time synchronisation packages +
+
+ +

1.4.1 xntpd

+ +

The `reference' implementation of the Network Time Protocol is the +program xntpd, available via +The NTP home page. + +

xntpd is designed to support all the operating modes defined by +RFC1305, and has driver support for a large number of reference clocks +(such as GPS receivers) that can be connected directly to a computer, +thereby providing a so-called 'stratum 1' server. + +

Things chronyd can do that xntpd can't: + +

    +
  • chronyd can perform usefully in an environment where access to +the time reference is intermittent. chronyd estimates +both the current time offset and the rate at which the +computer's clock gains or loses time, and can use that rate estimate to +trim the clock after the reference disappears. xntpd corrects +any time offset by speeding up and slowing down the computer clock, and +so could be left with a significant rate error if the reference +disappears whilst it is trying to correct a big offset. + +
  • chronyd provides support for isolated networks whether the only +method of time correction is manual entry (e.g. by the administrator +looking at a clock). chronyd can look at the errors corrected at +different updates to work out the rate at which the computer gains or +loses time, and use this estimate to trim the computer clock +subsequently. + +
  • chronyd provides support to work out the gain or loss rate of the +`real-time clock', i.e. the clock that maintains the time when the +computer is turned off. It can use this data when the system boots to +set the system time from a corrected version of the real-time clock. +These real-time clock facilities are only available on certain releases +of Linux, so far. + +
  • The xntpd program is supported by other programs to carry out +certain functions. ntpdate is used to provide an initial +correction to the system clock based on a `one-shot' sampling of other +NTP servers. tickadj is used to adjust certain operating system +parameters to make xntpd work better. All this functionality is +integrated into chronyd. +
+ +

Things xntpd can do that chronyd can't: + +

    +
  • xntpd supports a range of different hardware reference clocks +(GPS, atomic etc) that can be connected to a computer to provide a +`stratum-1' server. chronyd does not support any such hardware +yet; I don't have access to any to do any development work. +However, the software architecture should allow such equipment to be +interfaced at a later date. + +
  • xntpd supports effectively all of RFC1305, including broadcast / +multicast clients, leap seconds, and extra encryption schemes for +authenticating data packets. + +
  • xntpd has been ported to more types of computer / operating +system (so far). + +
  • xntpd is designed to work solely with integer arithmetic (i.e. does not +require floating point support from its host). +
+ +
+

+Previous: Comparison with xntpd, +Up: Other time synchronisation packages +
+
+ +

1.4.2 timed

+ +

timed is a program that is part of the BSD networking suite. It +uses broadcast packets to find all machines running the daemon within a +subnet. The machines elect a master which periodically measures the +system clock offsets of the other computers using ICMP timestamps. +Corrections are sent to each member as a result of this process. + +

Problems that may arise with timed are : + +

    +
  • Because it uses broadcasts, it is not possible to isolate its +functionality to a particular group of computers; there is a risk of +upsetting other computers on the same network (e.g. where a whole +company is on the same subnet but different departments are independent +from the point of view of administering their computers.) +
  • The update period appears to be 10 minutes. Computers can build up +significant offsets relative to each other in that time. If a +computer can estimate its rate of drift it can keep itself closer to +the other computers between updates by adjusting its clock every few +seconds. timed does not seem to do this. +
  • timed does not have any integrated capability for feeding +real-time into its estimates, or for estimating the average rate of time +loss/gain of the machines relative to real-time (unless one of the +computers in the group has access to an external reference and is always +appointed as the `master'). +
+ +

timed does have the benefit over chronyd that for isolated +networks of computers, they will track the `majority vote' time. For +such isolated networks, chronyd requires one computer to be the +`master' with the others slaved to it. If the master has a particular +defective clock, the whole set of computers will tend to slip relative +to real time (but they will stay accurate relative to one +another). + + +

+

+Next: , +Previous: Other time synchronisation packages, +Up: Introduction +
+
+ +

1.5 Distribution rights and (lack of) warranty

+ +

Chrony may be distributed in accordance with the GNU General Public License +version 2, reproduced in See GPL. + + + +

+

+Next: , +Previous: Distribution and warranty, +Up: Introduction +
+
+ +

1.6 Bug reporting and suggestions

+ +

If you think you've found a bug in chrony, or have a suggestion, please let me +know. My primary current email address is rc@rc0.org.uk. If that +fails, you could try finding me through one of the chrony mailing lists, or by +looking up my name on a search engine. + +

I can't promise a timescale to fix a bug; it depends a lot on the how complex +the bug is to track down, as I have a lot of other calls on my time : 2 young +children, my job, and indeed other free/open source software projects. +However, I do intend to look into problems when time allows. + +

Another source of information to try is the chrony users mailing list. You can +join this by sending an empty message to +chrony-users-subscribe@sunsite.dk. Only subscribers can post to +the list. + +

When you are reporting a bug, please send me all the information you can. +Unfortunately, chrony has proven to be one of those programs where it is very +difficult to reproduce bugs in a different environment. So I may have to +interact with you quite a lot to obtain enough extra logging and tracing to +pin-point the problem in some cases. Please be patient and plan for this! + +

Of course, if you can debug the problem yourself and send me a source code +patch to fix it, I will be very grateful! + + + +

+

+Previous: Bug reporting, +Up: Introduction +
+
+ +

1.7 Contributions

+ +

Although chrony is now a fairly mature and established project, there are still +areas that could be improved. If you can program in C and have some expertise +in these areas, you might be able to fill the gaps. + +

Particular areas I know need addressing are : + +

    +
  1. Porting to other Unices + +

    This involves creating equivalents of sys_solaris.c, sys_linux.c etc for the +new system. Note, the Linux driver has been reported as working on a range of +different architectures (Alpha, Sparc, MIPS as well as x86 of course). + +

  2. Porting to Windows NT + +

    I did a small amount of work on this under Cygwin. Only the sorting out of the +include files has really been achieved so far. The two main areas still to +address are + +

      +
    1. The system clock driver. +
    2. How to make chronyd into an NT service (i.e. what to replace fork(), +setsid() etc with so that chronyd can be automatically started in the system +bootstrap. +
    + +
  3. Hardware clock support + +
  4. Automation of the trimrtc and writertc mechanisms + +

    Currently, the RTC trimming mechanism is a manual operation, because there has +to be a reasonable guarantee that the system will stay up for a reasonable +length of time afterwards. (If it is shut down too soon, a poor +characterisation of the RTC drift rate will be stored on disc, giving a bad +system clock error when the system is next booted.) + +

    To make chrony more automated for the non-expert user, it would be useful if +this problem could be avoided so that trimrtc could be done automatically (e.g. +in a crontab, or as part of the ip-up or ip-down scripts.) + +

+ + + +
+

+Next: , +Previous: Introduction, +Up: Top +
+
+ +

2 Installation

+ + +

The software is distributed as source code which has to be compiled. +The source code is supplied in the form of a gzipped tar file, which +unpacks to a subdirectory identifying the name and version of the +program. + +

After unpacking the source code, change directory into it, and type + +

     ./configure
+
+

This is a shell script that automatically determines the system type. +There is a single optional parameter, --prefix which indicates +the directory tree where the software should be installed. For example, + +

     ./configure --prefix=/opt/free
+
+

will install the chronyd daemon into /opt/free/sbin and the +chronyc control program into /opt/free/bin. The default value for the +prefix is /usr/local. + +

The configure script assumes you want to use gcc as your compiler. +If you want to use a different compiler, you can configure this way: + +

     CC=cc CFLAGS=-O ./configure --prefix=/opt/free
+
+

for Bourne-family shells, or + +

     setenv CC cc
+     setenv CFLAGS -O
+     ./configure --prefix=/opt/free
+
+

for C-family shells. + +

If the software cannot (yet) be built on your system, an error message +will be shown. Otherwise, the files options.h and +Makefile will be generated. + +

By default, chronyc will be built to make use of the readline library. If you +don't want this, specify the –disable-readline flag to configure. If you have +readline and/or ncurses installed in a non-standard location, please refer to +see readline support for information. + +

Now type + +

     make
+
+

to build the programs. + +

If you want to build the manual in plain text, HTML and info versions, type + +

     make docs
+
+

Once the programs have been successfully compiled, they need to be +installed in their target locations. This step normally needs to be +performed by the superuser, and requires the following command to be +entered. + +

     make install
+
+

This will install the binaries, plain text manual and manpages. + +

To install the HTML and info versions of the manual as well, enter the command + +

     make install-docs
+
+

If you want chrony to appear in the top level info directory listing, you need +to run the install-info command manually after this step. +install-info takes 2 arguments. The first is the path to the +chrony.info file you have just installed. This will be the argument you +gave to –prefix when you configured (/usr/local by default), with +/info/chrony.info on the end. The second argument is the location of +the file called dir. This will typically be /usr/info/dir. So +the typical command line would be + +

     install-info /usr/local/info/chrony.info /usr/info/dir
+
+

Now that the software is successfully installed, the next step is to +set up a configuration file. The contents of this depend on the +network environment in which the computer operates. The Debian +package installs a simple configuration file suitable for a dial-up +pc. You should edit it to suit your situation. Typical scenarios are +described in the following section of the document. + + +

+ +
+

+Next: , +Up: Installation +
+
+ +

2.1 Support for the readline library

+ +

By default, chronyc is built to make use of the readline library. This allows +you to use the cursor keys to replay and edit old commands. If you don't want +to use readline (in which case chronyc will use a minimal command line +interface), invoke configure like this: + +

     ./configure --disable-readline other-options...
+
+

If you have readline and/or ncurses installed in locations that aren't normally searched by the compiler and linker, you need extra options if you want readline to be used: + +

+
--with-readline-includes=directory_name
This defines the name of the directory above the one where readline.h +is. readline.h is assumed to be in a readline subdirectory of +the named directory. + +
--with-readline-library=directory_name
This defines the directory containing the libreadline.a or +libreadline.so file. + +
--with-ncurses-library=directory_name
This defines the directory containing the libncurses.a or +libncurses.so file. +
+ + + +
+

+Previous: readline support, +Up: Installation +
+
+ +

2.2 Extra options for package builders

+ +

The configure and make procedures have some extra options that may be useful if +you are building a distribution package for chrony. + +

The –infodir=DIR option to configure specifies a different install directory +for the info files. This overrides the info subdirectory of the +argument to the –prefix option. For example, you might use + +

     ./configure --prefix=/usr --infodir=/usr/share/info
+
+

The –mandir=DIR option to configure specifies a different install directory +for the man pages. This overrides the man subdirectory of the +argument to the –prefix option. + +

     ./configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man
+
+

to set both options together. + +

The final option is the DESTDIR option to the make command. For example, you +could use the commands + +

     ./configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man
+     make all docs
+     make install DESTDIR=./tmp
+     cd tmp
+     tar cvf - . | gzip -9 > chrony.tar.gz
+
+

to build a package. When untarred within the root directory, this will install +the files to the intended final locations. + + + + + +

+

+Next: , +Previous: Installation, +Up: Top +
+
+ +

3 Typical operating scenarios

+ + + + +
+

+Next: , +Up: Typical scenarios +
+
+ +

3.1 Computers connected to the internet

+ +

In this section we discuss how to configure chrony for computers that +have permanent connections to the internet (or to any network +containing true NTP servers which ultimately derive their time from a +reference clock). + +

To operate in this mode, you will need to know the names of the NTP +server machines you wish to use. You may be able to find names of +suitable servers by one of the following methods: + +

    +
  • Your institution may already operate servers on its network. +Contact your system administrator to find out. + +
  • Your ISP probably has one or more NTP servers available for its +customers. + +
  • Somewhere under the NTP homepage there is a list of public +stratum 1 and stratum 2 servers. You should find one or more servers +that are near to you — check that their access policy allows you to +use their facilities. +
+ +

Assuming that you have found some servers, you need to set up a +configuration file to run chrony. The (compiled-in) default location +for this file is /etc/chrony.conf. In the Debian package the +configuration files are in the directory /etc/chrony. Assuming +that your ntp servers are called a.b.c and d.e.f, your +chrony.conf file could contain as a minimum + +

     server a.b.c
+     server d.e.f
+     server g.h.i
+
+

However, you will probably want to include some of the other directives +described later. The following directives will be particularly useful : +driftfile, commandkey, keyfile. The smallest +useful configuration file would look something like + +

     server a.b.c
+     server d.e.f
+     server g.h.i
+     keyfile /etc/chrony.keys
+     commandkey 1
+     driftfile /etc/chrony.drift
+
+ + +
+

+Next: , +Previous: Computers on the net, +Up: Typical scenarios +
+
+ +

3.2 Infrequent connection to true NTP servers

+ +

In this section we discuss how to configure chrony for computers that +have occasional connections to the internet. + +

+ +
+

+Next: , +Up: Infrequent connection +
+
+ +

3.2.1 Setting up the configuration file for infrequent connections

+ +

As in the previous section, you will need access to NTP servers on the +internet. The same remarks apply for how to find them. + +

In this case, you will need some additional configuration to tell +chronyd when the connection to the internet goes up and down. +This saves the program from continuously trying to poll the servers when +they are inaccessible. + +

Again, assuming that your ntp servers are called a.b.c and +d.e.f, your chrony.conf file would need to contain +something like + +

     server a.b.c
+     server d.e.f
+     server g.h.i
+
+

However, the following issues need to be addressed: + +

    +
  1. Your computer probably doesn't have DNS access whilst offline to turn +the machine names into IP addresses. +
  2. Your computer will keep trying to contact the servers to obtain +timestamps, even whilst offline. If you operate a dial-on-demand +system, things are even worse, because the link to the internet will +keep getting established. +
+ +

For this reason, it would be better to specify this part of your +configuration file in the following way: + +

     server 1.2.3.4 offline
+     server 5.6.7.8 offline
+     server 9.10.11.12 offline
+
+

Because numeric IP addresses have been used, the first problem is +overcome. The offline keyword indicates that the servers start +in an offline state, and that they should not be contacted until chronyd +receives notification that the link to the internet is present. + +

An alternative is to use the names of the NTP servers, and put entries for them +into your /etc/hosts file. This will be OK as long as files +comes before dns in the hosts line of the +/etc/nsswitch.conf file. + +

In order to notify chronyd of the presence of the link, you +will need to be able to log in to it with the program chronyc. To do +this, chronyd needs to be configured with an administrator +password. The Debian package puts a randomly generated key in +/etc/chrony/chrony.keys. You should change it. To set up an +administrator password, you can create a file /etc/chrony.keys +containing a single line + +

     1 xyzzy
+
+

and add the following line to /etc/chrony.conf (the order of the +lines does not matter) + +

     commandkey 1
+
+

The smallest useful configuration file would look something like + +

     server 1.2.3.4 offline
+     server 5.6.7.8 offline
+     server 9.10.11.12 offline
+     keyfile /etc/chrony.keys
+     commandkey 1
+     driftfile /etc/chrony.drift
+
+

The next section describes how to tell chronyd when the internet link +goes up and down. + +

+

+Previous: Configuration for infrequent connections, +Up: Infrequent connection +
+
+ +

3.2.2 How to tell chronyd when the internet link is available.

+ +

To use this option, you will need to configure a command key in +chronyd's configuration file /etc/chrony.conf, as described in +the previous section. + +

To tell chronyd when to start and finish sampling the servers, the +online and offline commands of chronyc need to be used. +To give an example of their use, we assume that pppd is the +program being used to connect to the internet, and that chronyc has been +installed at its default location /usr/local/bin/chronyc. We +also assume that the command key has been set up as described in the +previous section. + +

In the file /etc/ppp/ip-up we add the command sequence + +

     /usr/local/bin/chronyc <<EOF
+     password xyzzy
+     online
+     EOF
+
+

and in the file /etc/ppp/ip-down we add the sequence + +

     /usr/local/bin/chronyc <<EOF
+     password xyzzy
+     offline
+     EOF
+
+

The Debian package puts scripts similar to those above in the +directories /etc/ppp/ip-up.d and /etc/ppp/ip-down.d. + +

chronyd's polling of the servers will now only occur whilst the +machine is actually connected to the Internet. + + +

+

+Next: , +Previous: Infrequent connection, +Up: Typical scenarios +
+
+ +

3.3 Isolated networks

+ +

In this section we discuss how to configure chrony for computers that +never have network conectivity to any computer which ultimately derives +its time from a reference clock. + +

In this situation, one computer is selected to be the master timeserver. +The other computers are either direct clients of the master, or clients +of clients. + +

The rate value in the master's drift file needs to be set to the average +rate at which the master gains or loses time. chronyd includes +support for this, in the form of the manual directive in the +configuration file and the settime command in the chronyc +program. + +

If the master is rebooted, chronyd can re-read the drift rate +from the drift file. However, the master has no accurate estimate of +the current time. To get around this, the system can be configured so +that the master can initially set itself to a `majority-vote' of +selected clients' times; this allows the clients to `flywheel' the +master across its outage. + +

A typical configuration file for the master (called master) might +be (assuming the clients are in the 192.168.165.x subnet and that the +master's address is 192.168.169.170) + +

     driftfile /etc/chrony.drift
+     commandkey 25
+     keyfile /etc/chrony.keys
+     initstepslew 10 client1 client3 client6
+     local stratum 8
+     manual
+     allow 192.168.165
+
+

For the clients that have to resynchronise the master when it restarts, +the configuration file might be + +

     server master
+     driftfile /etc/chrony.drift
+     logdir /var/log/chrony
+     log measurements statistics tracking
+     keyfile /etc/chrony.keys
+     commandkey 24
+     local stratum 10
+     initstepslew 20 master
+     allow 192.168.169.170
+
+

The rest of the clients would be the same, except that the local +and allow directives are not required. + + +

+

+Next: , +Previous: Isolated networks, +Up: Typical scenarios +
+
+ +

3.4 The home PC with a dial-up connection

+ + + +
+

+Next: , +Up: Dial-up home PCs +
+
+ +

3.4.1 Assumptions/how the software works

+ +

This section considers the home computer which has a dial-up connection. +It assumes that Linux is run exclusively on the computer. Dual-boot +systems may work; it depends what (if anything) the other system does to +the system's real-time clock. + +

Much of the configuration for this case is discussed earlier +(see Infrequent connection). This section addresses specifically +the case of a computer which is turned off between 'sessions'. + +

In this case, chronyd relies on the computer's real-time clock +(RTC) to maintain the time between the periods when it is powered up. +The arrangement is shown in the figure below. + +

                 trim if required                          PSTN
+           +---------------------------+               +----------+
+           |                           |               |          |
+           v                           |               |          |
+     +---------+                    +-------+       +-----+     +---+
+     | System's|  measure error/    |chronyd|       |modem|     |ISP|
+     |real-time|------------------->|       |-------|     |     |   |
+     |  clock  |   drift rate       +-------+       +-----+     +---+
+     +---------+                       ^                          |
+           |                           |                          |
+           +---------------------------+                  --o-----o---
+              set time at boot up                           |
+                                                       +----------+
+                                                       |NTP server|
+                                                       +----------+
+
+

When the computer is connected to the Internet (via the modem), +chronyd has access to external NTP servers which it makes +measurements from. These measurements are saved, and straight-line fits +are performed on them to provide an estimate of the computer's time +error and rate of gaining/losing time. + +

When the computer is taken offline from the Internet, the best estimate +of the gain/loss rate is used to free-run the computer until it next +goes online. + +

Whilst the computer is running, chronyd makes measurements of the +real-time clock (RTC) (via the /dev/rtc interface, which must be +compiled into the kernel). An estimate is made of the RTC error at a +particular RTC second, and the rate at which the RTC gains or loses time +relative to true time. + +

The RTC is fully supported in 2.2, 2.4 and 2.6 kernels. + +

On 2.6 kernels, if your motherboard has a HPET, you need to enable the +HPET_EMULATE_RTC option in your kernel configuration. Otherwise, chrony +will not be able to interact with the RTC device and will give up using it. + +

For kernels in the 2.0 series prior to 2.0.32, the kernel was set up to +trim the RTC every 11 minutes. This would be disasterous for +chronyd – there is no reliable way of synchronising with this +trimming. For this reason, chronyd only supports the RTC in 2.0 +kernels from v2.0.32 onwards. + +

When the computer is powered down, the measurement histories for all the +NTP servers are saved to files (if the dumponexit directive is +specified in the configuration file), and the RTC tracking information +is also saved to a file (if the rtcfile directive has been +specified). These pieces of information are also saved if the +dump and writertc commands respectively are issued through +chronyc. + +

When the computer is rebooted, chronyd reads the current RTC time +and the RTC information saved at the last shutdown. This information is +used to set the system clock to the best estimate of what its time would +have been now, had it been left running continuously. The measurement +histories for the servers are then reloaded. + +

The next time the computer goes online, the previous sessions' +measurements can contribute to the line-fitting process, which gives a +much better estimate of the computer's gain/loss rate. + +

One problem with saving the measurements and RTC data when the machine +is shut down is what happens if there is a power failure; the most +recent data will not be saved. Although chronyd is robust enough +to cope with this, some performance may be lost. (The main danger +arises if the RTC has been changed during the session, with the +trimrtc command in chronyc. Because of this, +trimrtc will make sure that a meaningful RTC file is saved out +after the change is completed). + +

The easiest protection against power failure is to put the dump +and writertc commands in the same place as the offline +command is issued to take chronyd offline; because chronyd +free-runs between online sessions, no parameters will change +significantly between going offline from the Internet and any power +failure. + +

A final point regards home computers which are left running for extended +periods and where it is desired to spin down the hard disc when it is +not in use (e.g. when not accessed for 15 minutes). chronyd has +been planned so it supports such operation; this is the reason why the +RTC tracking parameters are not saved to disc after every update, but +only when the user requests such a write, or during the shutdown +sequence. The only other facility that will generate periodic writes to +the disc is the log rtc facility in the configuration file; this +option should not be used if you want your disc to spin down. + +

+

+Previous: Dial-up overview, +Up: Dial-up home PCs +
+
+ +

3.4.2 Typical configuration files.

+ +

To illustrate how a dial-up home computer might be configured, example +configuration files are shown in this section. + +

For the /etc/chrony.conf file, the following can be used as an +example. NOTE : The server directives are only applicable +to customers of Demon Internet; users of other ISPs will need to use +their own ISP's NTP servers or public NTP servers. + +

     server 158.152.1.65 minpoll 5 maxpoll 10 maxdelay 0.4 offline
+     server 158.152.1.76 minpoll 5 maxpoll 10 maxdelay 0.4 offline
+     server 194.159.253.2 minpoll 5 maxpoll 10 maxdelay 0.4 offline
+     logdir /var/log/chrony
+     log statistics measurements tracking
+     driftfile /etc/chrony.drift
+     keyfile /etc/chrony.keys
+     commandkey 25
+     maxupdateskew 100.0
+     dumponexit
+     dumpdir /var/log/chrony
+     rtcfile /etc/chrony.rtc
+
+

With Freeserve as the ISP, I use the following server lines : + +

     server 194.152.64.68 minpoll 5 maxpoll 10 maxdelay 0.4 offline
+     server 194.152.64.35 minpoll 5 maxpoll 10 maxdelay 0.4 offline
+     server 194.152.64.34 minpoll 5 maxpoll 10 maxdelay 0.4 offline
+
+

I use pppd for connecting to my ISP. This runs two scripts +/etc/ppp/ip-up and /etc/ppp/ip-down when the link goes +online and offline respectively. + +

The relevant part of the /etc/ppp/ip-up file is (with a dummy +password) + +

     /usr/local/bin/chronyc <<EOF
+     password xxxxxxxx
+     online
+     EOF
+
+

and the relevant part of the /etc/ppp/ip-down script is + +

     /usr/local/bin/chronyc <<EOF
+     password xxxxxxxx
+     offline
+     dump
+     writertc
+     EOF
+
+

(Because they have to contain the administrator password, it would be +desirable to make the files readable only by root on a multiuser +machine). + +

To start chronyd during the boot sequence, I have the following +in /etc/rc.d/rc.local (this is a Slackware system) + +

     if [ -f /usr/local/sbin/chronyd -a -f /etc/chrony.conf ]; then
+       /usr/local/sbin/chronyd -r -s
+       echo "Start chronyd"
+     fi
+
+

The Debian package puts a script which handles this and shutdown in +/etc/init.d/chrony. + +

The placement of this command may be important on some systems. In +particular, chronyd may need to be started several seconds (about +10 as a minimum) before any software that depends on the system clock +not jumping or moving backwards, depending on the directives in +chronyd's configuration file. + +

For the system shutdown, chronyd should receive a SIGTERM several +seconds before the final SIGKILL; the SIGTERM causes the measurement +histories and RTC information to be saved out. There should be no need +to add anything to the shutdown sequence, unless (as my system had) +there is no pause between the SIGTERM and SIGKILL being delivered to the +remaining processes. So if you find something like + +

     killall5 -15
+     killall5 -9
+
+

in your /etc/rc.d/rc.0 script, you will need to insert a sleep, e.g. + +

     killall5 -15
+     sleep 5
+     killall5 -9
+
+

Otherwise, chronyd will not always save information on shutdown, +which could be a problem if you don't use dump and +writertc when you go offline. + + +

+

+Previous: Dial-up home PCs, +Up: Typical scenarios +
+
+ +

3.5 Other important configuration options

+ +

The most common option to include in the configuration file is the +driftfile option. One of the major tasks of chronyd is to +work out how fast or how slow the system clock runs relative to real +time - e.g. in terms of seconds gained or lost per day. Measurements +over a long period are usually required to refine this estimate to an +acceptable degree of accuracy. Therefore, it would be bad if +chronyd had to work the value out each time it is restarted, +because the system clock would not run so accurately whilst the +determination is taking place. + +

To avoid this problem, chronyd allows the gain or loss rate to be +stored in a file, which can be read back in when the program is +restarted. This file is called the drift file, and might typically be +stored in /etc/chrony.drift. By specifying an option like the +following + +

     driftfile /etc/chrony.drift
+
+

in the configuration file (/etc/chrony.conf), the drift file +facility will be activated. + + + +

+

+Next: , +Previous: Typical scenarios, +Up: Top +
+
+ +

4 Usage reference

+ + + + + +
+

+Next: , +Up: Usage reference +
+
+ +

4.1 Starting chronyd

+ +

If chronyd has been installed to its default location +/usr/local/sbin/chronyd, starting it is simply a matter of +entering the command + +

     /usr/local/sbin/chronyd
+
+

The Debian package uses /usr/sbin/chronyd. + +

Information messages and warnings will be logged to syslog. + +

The command line options supported are as follows: + +

+
-d
When run in this mode, the program will not detach itself from the +terminal, and all messages will be sent to the terminal instead of to +syslog. +
-f <conf-file>
This option can be used to specify an alternate location for the +configuration file (default /etc/chrony.conf). +
-r
This option will reload sample histories for each of the servers being +used. These histories are created by using the dump command in +chronyc, or by setting the dumponexit directive in the +configuration file. This option is useful if you want to stop and +restart chronyd briefly for any reason, e.g. to install a new +version. However, it only makes sense on systems where the kernel can +maintain clock compensation whilst not under chronyd's control. +The only version where this happens so far is Linux. On systems where +this is not the case, e.g. Solaris and SunOS the option should not be +used. +
-s
This option will set the system clock from the computer's real-time +clock. This is analogous to supplying the `-s' flag to the +/sbin/clock program during the Linux boot sequence. + +

Support for real-time clocks is limited at present - the criteria are +described in the section on the rtcfile directive (see rtcfile directive). + +

If chronyd cannot support the real time clock on your computer, +this option cannot be used and a warning message will be logged to the +syslog. + +

If used in conjunction with the `-r' flag, chronyd will attempt +to preserve the old samples after setting the system clock from the real +time clock. This can be used to allow chronyd to perform long +term averaging of the gain or loss rate across system reboots, and is +useful for dial-up systems that are shut down when not in use. For this +to work well, it relies on chronyd having been able to determine +accurate statistics for the difference between the real time clock and +system clock last time the computer was on. + +

-v
This option displays chronyd's version number to the terminal and +exits. +
+ +

On systems that support an /etc/rc.local file for starting +programs at boot time, chronyd can be started from there. + +

On systems with a System V style initialisation (e.g. Solaris), a +suitable start/stop script might be as shown below. This might be +placed in the file /etc/rc2.d/S83chrony. + +

     #!/bin/sh
+     # This file should have uid root, gid sys and chmod 744
+     #
+     
+     killproc() {            # kill the named process(es)
+             pid=`/usr/bin/ps -e |
+                  /usr/bin/grep -w $1 |
+                  /usr/bin/sed -e 's/^  *//' -e 's/ .*//'`
+             [ "$pid" != "" ] && kill $pid
+     }
+     
+     case "$1" in
+     
+     'start')
+        if [ -f /opt/free/sbin/chronyd -a -f /etc/chrony.conf ]; then
+          /opt/free/sbin/chronyd
+        fi
+        ;;
+     'stop')
+        killproc chronyd
+        ;;
+     *)
+        echo "Usage: /etc/rc2.d/S83chrony { start | stop }"
+        ;;
+     esac
+
+

(In both cases, you may want to bear in mind that chronyd can +step the time when it starts. There may be other programs started at +boot time that could be upset by this, so you may need to consider the +ordering carefully. However, chronyd will need to start after +daemons providing services that it may require, e.g. the domain name +service.) + + +

+

+Next: , +Previous: Starting chronyd, +Up: Usage reference +
+
+ +

4.2 The chronyd configuration file

+ + +

The configuration file is normally called /etc/chrony.conf; in +fact, this is the compiled-in default. However, other locations can be +specified with a command line option. + +

Each command in the configuration file is placed on a separate line. +The following sections describe each of the commands in turn. The +directives can occur in any order in the file. + +

+ + +
+

+Next: , +Up: Configuration file +
+
+ +

4.2.1 Comments in the configuration file

+ +

The configuration file may contain comment lines. A comment line is any line +that starts with zero or more spaces followed by any one of the following +characters: +

    +
  • ! +
  • ; +
  • # +
  • % +
+ Any line with this format will be ignored. + + +
+

+Next: , +Previous: comments in config file, +Up: Configuration file +
+
+ +

4.2.2 acquisitionport

+ +

chronyd uses a separate client-side port for the rapid-fire +measurements requested with the initstepslew directive +(see initstepslew directive). Normally, that port is chosen +arbitrarily by the operating system. However, you can use +acquisitionport to explicitly specify a port. This may be useful +for getting through firewalls. + +

Do not make acquisition and regular NTP service (see port directive) +use the same port. + +

An example of the acquisitionport command is + +

     acquisitionport 1123
+
+

This would change the port used for rapid queries to udp/1123. You +could then persuade the firewall administrator to let that port through. + + +

+

+Next: , +Previous: acquisitionport directive, +Up: Configuration file +
+
+ +

4.2.3 allow

+ +

The allow command is used to designate a particular subnet from +which NTP clients are allowed to access the computer as an NTP server. + +

The default is that no clients are allowed access, i.e. chronyd +operates purely as an NTP client. If the allow directive is +used, chronyd will be both a client of its servers, and a server +to other clients. + +

Examples of use of the command are as follows: + +

     allow foo.bar.com
+     allow 1.2
+     allow 3.4.5
+     allow 6.7.8/22
+     allow 6.7.8.9/22
+     allow
+
+

The first command allows the named node to be an NTP client of this computer. +The second command allows any node with an IP address of the form 1.2.x.y (with +x and y arbitrary) to be an NTP client of this computer. Likewise, the third +command allows any node with an IP address of the form 3.4.5.x to have client +NTP access. The fourth and fifth forms allow access from any node with an IP +address of the form 6.7.8.x, 6.7.9.x, 6.7.10.x or 6.7.11.x (with x arbitrary), +i.e. the value 22 is the number of bits defining the specified subnet. (In the +fifth form, the final byte is ignored). The sixth form allows access by any +node on the entire Internet. + +

A second form of the directive, allow all, has a greater effect, +depending on the ordering of directives in the configuration file. To +illustrate the effect, consider the two examples + +

     allow 1.2.3.4
+     deny 1.2.3
+     allow 1.2
+
+

and + +

     allow 1.2.3.4
+     deny 1.2.3
+     allow all 1.2
+
+

In the first example, the effect is the same regardles of what order the +three directives are given in. So the 1.2.x.y subnet is allowed access, +except for the 1.2.3.x subnet, which is denied access, however the host +1.2.3.4 is allowed access. + +

In the second example, the allow all 1.2 directives overrides the +effect of any previous directive relating to a subnet within the +specified subnet. Within a configuration file this capability is +probably rather moot; however, it is of greater use for reconfiguration +at run-time via chronyc (see allow all command). + +

Note, if the initstepslew directive (see initstepslew directive) is used in the configuration file, each of the computers +listed in that directive must allow client access by this computer for +it to work. + + +

+

+Next: , +Previous: allow directive, +Up: Configuration file +
+
+ +

4.2.4 bindaddress

+ +

The bindaddress allows you to restrict the network interface to which +chronyd will listen for NTP packets. This provides an additional level of +access restriction above that available through the 'deny' mechanism. + +

Suppose you have a local ethernet with addresses in the 192.168.1.0 +subnet together with a dial-up connection. The ethernet interface's IP +address is 192.168.1.1. Suppose (for some reason) you want to block all +access through the dialup connection (note, this will even block replies +from servers on the dialup side, so you will not be able to synchronise +to an external source). You could add the line + +

     bindaddress 192.168.1.1
+
+

to the configuration file. + +

This directive affects NTP (UDP port 123) packets. If no bindcmdaddress +directive is present, the address supplied by bindaddress will be used +to control binding of the command socket (UDP port 323) as well. + +

The bindaddress directive has been found to cause problems when used on +computers that need to pass NTP traffic over multiple network interfaces (e.g. +firewalls). It is, therefore, not particularly useful. Use of the +allow and deny directives together with a network firewall is +more likely to be successful. + + + +

+

+Next: , +Previous: bindaddress directive, +Up: Configuration file +
+
+ +

4.2.5 bindcmdaddress

+ +

The bindcmdaddress allows you to restrict the network interface to which +chronyd will listen for command packets (issued by chronyc). + +

Suppose you have a local ethernet with addresses in the 192.168.1.0 subnet +together with a dial-up connection. The ethernet interface's IP address is +192.168.1.1. Suppose you want to block all access through the dialup +connection. You could add the line + +

     bindcmdaddress 192.168.1.1
+
+

to the configuration file. + +

The bindcmdaddress directive has been found to cause problems when used +on computers that need to pass command traffic over multiple network +interfaces. It is, therefore, not particularly useful. Use of the +cmdallow and cmddeny directives together with a network firewall +is more likely to be successful. + + + +

+

+Next: , +Previous: bindcmdaddress directive, +Up: Configuration file +
+
+ +

4.2.6 broadcast

+ +

The broadcast directive is used to declare a broadcast address to which +chronyd should send packets in NTP broadcast mode (i.e. make chronyd act as a +broadcast server). Broadcast clients on that subnet will be able to +synchronise. + +

The syntax is as follows + +

     broadcast 30 192.168.1.255
+     broadcast 60 192.168.2.255 12123
+
+

In the first example, the destination port defaults to 123/udp (the normal NTP +port). In the second example, the destionation port is specified as 12123. +The first parameter in each case (30 or 60 respectively) is the interval in +seconds between broadcast packets being sent. The second parameter in each +case is the broadcast address to send the packet to. This should correspond to +the broadcast address of one of the network interfaces on the computer where +chronyd is running. + +

You can have more than 1 broadcast directive if you have more than 1 +network interface onto which you wish to send NTP broadcast packets. + +

Chronyd itself cannot currently act as a broadcast client; it must always be +configured as a point-to-point client by defining specific NTP servers and +peers. This broadcast server feature is intended for providing a time source +to other NTP software (e.g. various MS Windows clients). + +

If xntpd is used as the broadcast client, it will try to use a point-to-point +client/server NTP access to measure the round-trip delay. Thus, the broadcast +subnet should also be the subject of an allow directive (see allow directive). + + +

+

+Next: , +Previous: broadcast directive, +Up: Configuration file +
+
+ +

4.2.7 cmdallow

+ +

This is similar to the allow directive (see allow directive), except +that it allows control access (rather than NTP client access) to a particular +subnet or host. (By 'control access' is meant that chronyc can be run on those +hosts and successfully connect to chronyd on this computer.) + +

The syntax is identical to the allow directive. + +

There is also a cmdallow all directive with similar behaviour to the +allow all directive (but applying to control access in this case, of +course). + + +

+

+Next: , +Previous: cmdallow directive, +Up: Configuration file +
+
+ +

4.2.8 cmddeny

+ +

This is similar to the cmdallow directive (see cmdallow directive), +except that it denies control access to a particular subnet or host, +rather than allowing it. + +

The syntax is identical. + +

There is also a cmddeny all directive with similar behaviour to the +cmdallow all directive. + + +

+

+Next: , +Previous: cmddeny directive, +Up: Configuration file +
+
+ +

4.2.9 commandkey

+ +

The commandkey command is used to set the key number used for +authenticating user commands via the chronyc program at run time. +This allows certain actions of the chronyc program to be restricted to +administrators. + +

An example of the commandkey command is + +

     commandkey 20
+
+

In the key file (see the keyfile command) there should be a line of +the form + +

     20 foobar
+
+

When running the chronyc program to perform run-time configuration, +the command + +

     password foobar
+
+

must be entered before any commands affecting the operation of the +daemon can be entered. + + +

+

+Next: , +Previous: commandkey directive, +Up: Configuration file +
+
+ +

4.2.10 cmdport

+ +

The cmdport directive allows the port that is used for run-time +command and monitoring (via the program chronyc) to be altered +from its default (323/udp). + +

An example shows the syntax + +

     cmdport 257
+
+

This would make chronyd use 257/udp as its command port. +(chronyc would need to be run with the -p 257 switch to +inter-operate correctly). + + +

+

+Next: , +Previous: cmdport directive, +Up: Configuration file +
+
+ +

4.2.11 deny

+ +

This is similar to the allow directive (see allow directive), +except that it denies NTP client access to a particular subnet or host, +rather than allowing it. + +

The syntax is identical. + +

There is also a deny all directive with similar behaviour to the +allow all directive. + + +

+

+Next: , +Previous: deny directive, +Up: Configuration file +
+
+ +

4.2.12 driftfile

+ +

One of the main activities of the chronyd program is to work out +the rate at which the system clock gains or loses time relative to real +time. + +

Whenever chronyd computes a new value of the gain/loss rate, it +is desirable to record it somewhere. This allows chronyd to +begin compensating the system clock at that rate whenever it is +restarted, even before it has had a chance to obtain an equally good +estimate of the rate during the new run. (This process may take many +minutes, at least). + +

The driftfile command allows a file to be specified into which +chronyd can store the rate information. Two parameters are +recorded in the file. The first is the rate at which the system clock +gains or loses time, expressed in parts per million, with gains +positive. Therefore, a value of 100.0 indicates that when the system +clock has advanced by a second, it has gained 100 microseconds on +reality (so the true time has only advanced by 999900 microseconds). +The second is an estimate of the error bound around the first value in +which the true rate actually lies. + +

An example of the driftfile command is + +

     driftfile /etc/chrony.drift
+
+ + +
+

+Next: , +Previous: driftfile directive, +Up: Configuration file +
+
+ +

4.2.13 dumpdir

+ +

To compute the rate of gain or loss of time, chronyd has to store +a measurement history for each of the time sources it uses. + +

Certain systems (so far only Linux) have operating system support for +setting the rate of gain or loss to compensate for known errors. (On +other systems, chronyd must simulate such a capability by +periodically slewing the system clock forwards or backwards by a +suitable amount to compensate for the error built up since the previous +slew). + +

For such systems, it is possible to save the measurement history across +restarts of chronyd (assuming no changes are made to the system +clock behaviour whilst it is not running). If this capability is to be +used (via the dumponexit command in the configuration file, or the dump +command in chronyc), the dumpdir command should be used to define the +directory where the measurement histories are saved. + +

An example of the command is + +

     dumpdir /var/log/chrony
+
+

A source whose IP address is 1.2.3.4 would have its measurement +history saved in the file /var/log/chrony/1.2.3.4.dat. + + +

+

+Next: , +Previous: dumpdir directive, +Up: Configuration file +
+
+ +

4.2.14 dumponexit

+ +

If this command is present, it indicates that chronyd should save +the measurement history for each of its time sources recorded whenever +the program exits. (See the dumpdir command above). + + +

+

+Next: , +Previous: dumponexit directive, +Up: Configuration file +
+
+ +

4.2.15 initstepslew

+ +

In normal operation, chronyd always slews the time when it needs to +adjust the system clock. For example, to correct a system clock which +is 1 second slow, chronyd slightly increases the amount by which the +system clock is advanced on each clock interrupt, until the error is +removed. (Actually, this is done by calling the adjtime() or +similar system function which does it for us.) Note that at no time +does time run backwards with this method. + +

On most Unix systems it is not desirable to step the system clock, +because many programs rely on time advancing monotonically forwards. + +

When the chronyd daemon is initially started, it is possible that the +system clock is considerably in error. Attempting to correct such an +error by slewing may not be sensible, since it may take several hours +to correct the error by this means. + +

The purpose of the initstepslew directive is to allow chronyd to +make a rapid measurement of the system clock error at boot time, and to +correct the system clock by stepping before normal operation begins. +Since this would normally be performed only at an appropriate point in +the system boot sequence, no other software should be adversely affected +by the step. + +

If the correction required is less than a specified threshold, a slew is +used instead. This makes it easier to restart chronyd whilst the +system is in normal operation. + +

The initstepslew directive takes a threshold and a list of NTP +servers as arguments. A maximum of 8 will be used. Each of the servers +is rapidly polled several times, and a majority voting mechanism used to +find the most likely range of system clock error that is present. A +step (or slew) is applied to the system clock to correct this error. +chronyd then enters its normal operating mode (where only slews are +used). + +

An example of use of the command is + +

     initstepslew 30 foo.bar.com baz.quz.com
+
+

where 2 NTP servers are used to make the measurement. The 30 +indicates that if the system's error is found to be 30 seconds or less, +a slew will be used to correct it; if the error is above 30 seconds, a +step will be used. + +

The initstepslew directive can also be used in an isolated LAN +environment, where the clocks are set manually. The most stable +computer is chosen as the master, and the other computers are slaved to +it. If each of the slaves is configured with the local option (see +below), the master can be set up with an initstepslew directive +which references some or all of the slaves. Then, if the master machine +has to be rebooted, the slaves can be relied on to 'flywheel' the time +for the master. + + +

+

+Next: , +Previous: initstepslew directive, +Up: Configuration file +
+
+ +

4.2.16 keyfile

+ +

This command is used to specify the location of the file containing +ID/key pairs for the following 2 uses: + +

    +
  • Authentication of NTP packets. +
  • Authentication of administrator commands entered via chronyc. +
+ +

The format of the command is shown in the example below + +

     keyfile /etc/chrony.keys
+
+

The argument is simply the name of the file containing the ID/key +pairs. The format of the file is shown below + +

     10 tulip
+     11 hyacinth
+     20 crocus
+     25 iris
+      ...
+
+

Each line consists of an ID and a password. The ID can be any +unsigned integer in the range 0 through 2**32-1. The password can be +any string of characters not containing a space. + +

For NTP use, the MD5 authentication scheme is always used. This must be +borne in mind if chronyd is to inter-operate in authenticated +mode with xntpd running on other computers. + +

The ID for the chronyc authentication key is specified with the +commandkey command (see earlier). + + +

+

+Next: , +Previous: linux_freq_scale directive, +Up: Configuration file +
+
+ +

4.2.17 local

+ +

The local keyword is used to allow chronyd to appear synchronised +to real time (from the viewpoint of clients polling it), even if it has +no current synchronisation source. + +

This option is normally used on computers in an isolated network, +where several computers are required to synchronise to one other, this +being the "master" which is kept vaguely in line with real time by +manual input. + +

An example of the command is + +

     local stratum 10
+
+

The value 10 may be substituted with other values in the range 1 +through 15. Stratum 1 indicates a computer that has a true real-time +reference directly connected to it (e.g. GPS, atomic clock etc) +&ndash; such computers are expected to be very close to real time. +Stratum 2 computers are those which have a stratum 1 server; stratum 3 +computers have a stratum 2 server and so on. + +

A large value of 10 indicates that the clock is so many hops away from +a reference clock that its time is fairly unreliable. Put another +way, if the computer ever has access to another computer which is +ultimately synchronised to a reference clock, it will almost certainly +be at a stratum less than 10. Therefore, the choice of a high value +like 10 for the local command prevents the machine's own time from +ever being confused with real time, were it ever to leak out to +clients that have visibility of real servers. + + +

+

+Next: , +Previous: keyfile directive, +Up: Configuration file +
+
+ +

4.2.18 linux_hz

+ +

(This option only applies to Linux). + +

By default, chronyd will find the value of HZ from a kernel header file +at compile time. HZ is the nominal number of timer interrupts per +second. If you're running chronyd on the system where it was built, the value +it has should be right, and you don't need to worry about this option. + +

This option is provided for people who move a pre-built chronyd onto a system +where the value of HZ in the kernel headers has been changed from the default +value. + +

An example of the command is + +

     linux_hz 100
+
+ + +
+

+Next: , +Previous: linux_hz directive, +Up: Configuration file +
+
+ +

4.2.19 linux_freq_scale

+ +

(This option only applies to Linux). + +

By default, chronyd will find the value of HZ and SHIFT_HZ from +kernel header files at compile time. An internal value called +freq_scale is calculated from this. By default it is (1<<SHIFT_HZ)/HZ, +except for the case HZ=100, when special case code is used which leads to the +value 128/128.125. If you're running chronyd on the system where it was built, +the value it has should be right, and you don't need to worry about this +option. + +

This option is provided for people who move a pre-built chronyd onto a system +where the method by which the kernel computes the reciprocal of this value has been changed or where the HZ and SHIFT_HZ constants differ from those on the system where chronyd was built. + +

An example of the command is + +

     linux_freq_scale 0.99902439
+
+ + +
+

+Next: , +Previous: local directive, +Up: Configuration file +
+
+ +

4.2.20 log

+ + +

The log command indicates that certain information is to be logged. + +

+
measurements
This option logs the raw NTP measurements and related information to a +file called measurements.log. + +
statistics
This option logs information about the regression processing to a file +called statistics.log. + +
tracking
This option logs changes to the estimate of the system's gain or loss +rate, and any slews made, to a file called tracking.log. + +
rtc
This option logs information about the system's real-time clock. +
+ +

The files are written to the directory specified by the logdir +command. + +

An example of the command is + +

     log measurements statistics tracking
+
+ + + +
+

+Next: , +Up: log directive +
+
+ +
4.2.20.1 Measurements log file format
+ +

An example line (which actually appears as a single line in the file) +from the measurements log file is shown below. + +

     1998-07-22 05:40:50 158.152.1.76    N  8 1111 11 1111 10 10  1 \
+        -4.966e-03  2.296e-01  1.577e-05  1.615e-01  7.446e-03
+
+

The columns are as follows (the quantities in square brackets are the +values from the example line above) : + +

    +
  1. Date [1998-07-22] +
  2. Hour:Minute:Second [05:40:50]. Note that the date/time pair is +expressed in UTC, not the local time zone. +
  3. IP address of server/peer from which measurement comes [158.152.1.76] +
  4. Leap status (N means normal, - means that the last minute +of today has 61 seconds, + means that the last minute of the day +has 59 seconds, ? means the remote computer is not currently +synchronised.) [N] +
  5. Stratum of remote computer. [2] +
  6. RFC1305 tests 1 through 4 (1=pass, 0=fail) [1111] +
  7. Tests for maximum delay and maximum delay ratio, against user defined +parameters (1=pass, 0=fail) [11] +
  8. RFC1305 tests 5 through 8 (1=pass, 0=fail) [1111] +
  9. Local poll [10] +
  10. Remote poll [10] +
  11. `Score' (an internal score within each polling level used to decide when +to increase or decrease the polling level. This is adjusted based on +changes to the variance of the measurements obtained from the source). [1] +
  12. The estimated local clock error (`theta' in RFC1305). Positive indicates that the local clock is slow. [-4.966e-03]. +
  13. The peer delay (`delta' in RFC1305). [2.296e-01] +
  14. The peer dispersion (`epsilon' in RFC1305). [1.577e-05] +
  15. The root delay (`Delta' in RFC1305). [1.615e-01] +
  16. The root dispersion (`E' in RFC1305). [7.446e-03] +
+ +

A banner is periodically written to the log file to indicate the +meanings of the columns. + + +

+

+Next: , +Previous: measurements log, +Up: log directive +
+
+ +
4.2.20.2 Statistics log file format
+ +

An example line (which actually appears as a single line in the file) +from the measurements log file is shown below. + +

     1998-07-22 05:40:50 158.152.1.76     6.261e-03 -3.247e-03 \
+          2.220e-03  1.874e-06  1.080e-06 7.8e-02  16   0   8
+
+

The columns are as follows (the quantities in square brackets are the +values from the example line above) : + +

    +
  1. Date [1998-07-22] +
  2. Hour:Minute:Second [05:40:50]. Note that the date/time pair is +expressed in UTC, not the local time zone. +
  3. IP address of server/peer from which measurement comes [158.152.1.76] +
  4. The estimated standard deviation of the measurements from the source (in +seconds). [6.261e-03] +
  5. The estimated offset of the source (in seconds, positive means the local +clock is estimated to be fast, in this case). [-3.247e-03] +
  6. The estimated standard deviation of the offset estimate (in +seconds). [2.220e-03] +
  7. The estimated rate at which the local clock is gaining or losing time +relative to the source (in seconds per second, positive means the local +clock is gaining). This is relative to the compensation currently being +applied to the local clock, not to the local clock without any +compensation. [1.874e-06] +
  8. The estimated error in the rate value (in seconds per +second). [1.080e-06]. +
  9. The ration of |old_rate - new_rate| / old_rate_error. Large values +indicate the statistics are not modelling the source very well. [7.8e-02] +
  10. The number of measurements currently being used for the regression +algorithm. [16] +
  11. The new starting index (the oldest sample has index 0; this is the +method used to prune old samples when it no longer looks like the +measurements fit a linear model). [0, i.e. no samples discarded this +time] +
  12. The number of runs. The number of runs of regression residuals with the +same sign is computed. If this is too small it indicates that the +measurements are no longer represented well by a linear model and that +some older samples need to be discarded. The number of runs for the +data that is being retained is tabulated. Values of approximately half +the number of samples are expected. [8] +
+ +

A banner is periodically written to the log file to indicate the +meanings of the columns. + + +

+

+Next: , +Previous: statistics log, +Up: log directive +
+
+ +
4.2.20.3 Tracking log file format
+ +

An example line (which actually appears as a single line in the file) +from the measurements log file is shown below. + +

     1998-07-22 05:40:50 158.152.1.76     3    340.529      1.606  1.046e-03
+
+

The columns are as follows (the quantities in square brackets are the +values from the example line above) : + +

    +
  1. Date [1998-07-22] +
  2. Hour:Minute:Second [05:40:50]. Note that the date/time pair is +expressed in UTC, not the local time zone. +
  3. The IP address of the server/peer to which the local system is +synchronised. [158.152.1.76] +
  4. The stratum of the local system. [3] +
  5. The local system frequency (in ppm, positive means the local system runs +fast of UTC). [340.529] +
  6. The error bounds on the frequency (in ppm) [1.606] +
  7. The estimated local offset at the epoch (which is rapidly corrected by +slewing the local clock. (In seconds, positive indicates the local +system is fast of UTC). [1.046e-3] +
+ +

A banner is periodically written to the log file to indicate the +meanings of the columns. + + +

+

+Previous: tracking log, +Up: log directive +
+
+ +
4.2.20.4 Real-time clock log file format
+ +

An example line (which actually appears as a single line in the file) +from the measurements log file is shown below. + +

     1998-07-22 05:40:50     -0.037360 1       -0.037434\
+               -37.948  12   5  120
+
+

The columns are as follows (the quantities in square brackets are the +values from the example line above) : + +

    +
  1. Date [1998-07-22] +
  2. Hour:Minute:Second [05:40:50]. Note that the date/time pair is +expressed in UTC, not the local time zone. +
  3. The measured offset between the system's real time clock and the system +(gettimeofday()) time. In seconds, positive indicates that the +RTC is fast of the system time. [-0.037360]. +
  4. Flag indicating whether the regression has produced valid +coefficients. (1 for yes, 0 for no). [1] +
  5. Offset at the current time predicted by the regression process. A large +difference between this value and the measured offset tends to indicate +that the measurement is an outlier with a serious measurement +error. [-0.037434]. +
  6. The rate at which the RTC is losing or gaining time relative to the +system clock. In ppm, with positive indicating that the RTC is gaining +time. [-37.948] +
  7. The number of measurements used in the regression. [12] +
  8. The number of runs of regression residuals of the same sign. Low values +indicate that a straight line is no longer a good model of the measured +data and that older measurements should be discarded. [5] +
  9. The measurement interval used prior to the measurement being made (in +seconds). [120] +
+ +

A banner is periodically written to the log file to indicate the +meanings of the columns. + + + +

+

+Next: , +Previous: log directive, +Up: Configuration file +
+
+ +

4.2.21 logchange

+ +

This directive forces chronyd to send a message to syslog if it +makes a system clock adjustment larger than a threshold value. An +example of use is + +

     logchange 0.5
+
+

which would cause a syslog message to be generated a system clock error +of over 0.5 seconds starts to be compensated. + +

Clock errors detected either via NTP packets or via timestamps entered +via the settime command of chronyc are logged. + +

This directive assumes that syslog messages are appearing where somebody +can see them. This allows that person to see if a large error has +arisen, e.g. because of a fault, or because of faulty timezone handling, +for example when summer time (daylight saving) starts or ends. + + +

+

+Next: , +Previous: logchange directive, +Up: Configuration file +
+
+ +

4.2.22 logdir

+ +

This directive allows the directory where log files are written to be +specified. + +

An example of the use of this directive is + +

     logdir /var/log/chrony
+
+ + +
+

+Next: , +Previous: logdir directive, +Up: Configuration file +
+
+ +

4.2.23 mailonchange

+ +

This directive defines an email address to which mail should be sent if +chronyd applies a correction exceeding a particular threshold to the +system clock. + +

An example of use of this directive is + +

     mailonchange root@localhost 0.5
+
+

This would send a mail message to root if a change of more than 0.5 +seconds were applied to the system clock. + + +

+

+Next: , +Previous: mailonchange directive, +Up: Configuration file +
+
+ +

4.2.24 manual

+ +

The manual directive enables support at run-time for the +settime command in chronyc (see settime command). If no +manual directive is included, any attempt to use the +settime command in chronyc will be met with an error message. + +

Note that the settime command can be enabled at run-time using +the manual command in chronyc (see manual command). (The +idea of the two commands is that the manual command controls the +manual clock driver's behaviour, whereas the settime command +allows samples of manually entered time to be provided). + + +

+

+Next: , +Previous: manual directive, +Up: Configuration file +
+
+ +

4.2.25 maxupdateskew

+ +

One of chronyd's tasks is to work out how fast or slow the computer's +clock runs relative to its reference sources. In addition, it computes +an estimate of the error bounds around the estimated value. + +

If the range of error is too large, it probably indicates that the +measurements have not settled down yet, and that the estimated gain or +loss rate is not very reliable. + +

The maxupdateskew parameter allows the threshold for determining +whether an estimate may be so unreliable that it should not be used. + +

The syntax is + +

     maxupdateskew <skew-in-ppm>
+
+

Typical values for <skew-in-ppm> might be 100 for a dial-up connection +to servers over a phone line, and 5 or 10 for a computer on a LAN. + +

It should be noted that this is not the only means of protection against +using unreliable estimates. At all times, chronyd keeps track of +both the estimated gain or loss rate, and the error bound on the +estimate. When a new estimate is generated following another +measurement from one of the sources, a weighted combination algorithm is +used to update the master estimate. So if chronyd has an existing +highly-reliable master estimate and a new estimate is generated which +has large error bounds, the existing master estimate will dominate in +the new master estimate. + + +

+

+Next: , +Previous: maxupdateskew directive, +Up: Configuration file +
+
+ +

4.2.26 noclientlog

+ +

This directive, which takes no arguments, specifies that client accesses +are not to be logged. Normally they are logged, allowing statistics to +be reported using the clients command in chronyc. + + +

+

+Next: , +Previous: noclientlog directive, +Up: Configuration file +
+
+ +

4.2.27 peer

+ +

The syntax of this directive is identical to that for the server +directive (see server directive), except that it is used to specify +an NTP peer rather than an NTP server. + + +

+

+Next: , +Previous: peer directive, +Up: Configuration file +
+
+ +

4.2.28 pidfile

+ +

chronyd always writes its process ID (pid) to a file, and checks this file on startup to see if another chronyd may already be running on the system. By default, the file used is /var/run/chronyd.pid. The pidfile directive allows the name to be changed, e.g. + +

     pidfile /var/tmp/chronyd.pid
+
+ + +
+

+Next: , +Previous: pidfile directive, +Up: Configuration file +
+
+ +

4.2.29 port

+ +

This option allows you to configure the port used for the NTP service +on your machine. + +

The compiled in default is udp/123, the standard NTP port. It is +unlikely that you would ever need to change this value. A possible +exception would be if you wanted to operate strictly in client-only +mode and never be available as a server to xntpd clients. + +

An example of the port command is + +

     port 11123
+
+

This would change the NTP port served by chronyd on the computer to +udp/11123. + + +

+

+Next: , +Previous: port directive, +Up: Configuration file +
+
+ +

4.2.30 rtcdevice

+ +

The rtcdevice directive defines the name of the device file for +accessing the real time clock. By default this is /dev/rtc/, unless the +directive is used to set a different value. This applies to Linux systems with +devfs. An example of use is + +

     rtcdevice /dev/misc/rtc
+
+ + +
+

+Next: , +Previous: rtcdevice directive, +Up: Configuration file +
+
+ +

4.2.31 rtcfile

+ +

The rtcfile directive defines the name of the file in which +chronyd can save parameters associated with tracking the accuracy +of the system's real-time clock (RTC). + +

The syntax is illustrated in the following example + +

     rtcfile /etc/chrony.rtc
+
+

chronyd saves information in this file when it exits and when the +writertc command is issued in chronyc. The information +saved is the RTC's error at some epoch, that epoch (in seconds since +January 1 1970), and the rate at which the RTC gains or loses time. + +

So far, the support for real-time clocks is limited - their code is even +more system-specific than the rest of the software. You can only use +the real time clock facilities (the rtcfile directive and the +-s command line option to chronyd) if the following three +conditions apply: + +

    +
  1. You are running Linux version 2.2.x or 2.4.x (for any value of x), or v2.0.x +with x>=32. + +
  2. You have compiled the kernel with extended real-time clock support +(i.e. the /dev/rtc device is capable of doing useful things). + +
  3. You don't have other applications that need to make use of +/dev/rtc at all. + +
+ + +
+

+Next: , +Previous: rtcfile directive, +Up: Configuration file +
+
+ +

4.2.32 rtconutc

+ +

chronyd assumes by default that the real time clock (RTC) keeps +local time (including any daylight saving changes). This is convenient +on PCs running Linux which are dual-booted with DOS or Windows. + +

NOTE : IF YOU KEEP THE REAL TIME CLOCK ON LOCAL TIME AND YOUR COMPUTER +IS OFF WHEN DAYLIGHT SAVING (SUMMER TIME) STARTS OR ENDS, THE COMPUTER'S +SYSTEM TIME WILL BE ONE HOUR IN ERROR WHEN YOU NEXT BOOT AND START +CHRONYD. + +

An alternative is for the RTC to keep Universal Coordinated Time (UTC). +This does not suffer from the 1 hour problem when daylight saving starts +or ends. + +

If the rtconutc directive appears, it means the RTC is required +to keep UTC. The directive takes no arguments. It is equivalent to +specifying the -u switch to the Linux /sbin/clock program. + + +

+

+Previous: rtconutc directive, +Up: Configuration file +
+
+ +

4.2.33 server

+ +

The server directive allows NTP servers to be specified. The +client/server relationship is strictly hierarchical : a client may +synchronise its system time to that of the server, but the server's +system time will never be influenced by that of a client. + +

The server directive is immediately followed by either the name +of the server, or its IP address in dotted-quad notation. The server +command also supports a number of subfields (which may be defined in any +order): + +

+
port
This option allows the UDP port on which the server understands NTP +requests to be specified. For normal servers this option should not be +required (the default is 123, the standard NTP port). +
minpoll
Although chronyd will trim the rate at which it samples the +server during normal operation, the user may wish to constrain the +minimum polling interval. This is always defined as a power of 2, so +<tt/minpoll 5/ would mean that the polling interval cannot drop below 32 +seconds. The default is 6 (64 seconds). +
maxpoll
In a similar way, the user may wish to constrain the maximum polling +interval. Again this is specified as a power of 2, so <tt/maxpoll 9/ +indicates that the polling interval must stay at or below 512 seconds. +The default is 10 (1024 seconds). +
maxdelay
chronyd uses the network round-trip delay to the server to +determine how accurate a particular measurement is likely to be. Long +round-trip delays indicate that the request, or the response, or both +were delayed. If only one of the messages was delayed the measurement +error is likely to be substantial. + +

For small variations in round trip delay, chronyd uses a +weighting scheme when processing the measurements. However, beyond a +certain level of delay the measurements are likely to be so corrupted as +to be useless. (This is particularly so on dial-up or other slow links, +where a long delay probably indicates a highly asymmetric delay caused +by the response waiting behind a lot of packets related to a download of +some sort). + +

If the user knows that round trip delays above a certain level should +cause the measurement to be ignored, this level can be defined with the +maxdelay command. For example, <tt/maxdelay 0.3/ would indicate that +measurements with a round-trip delay of 0.3 seconds or more should be +ignored. + +

maxdelayratio
This option is similar to the maxdelay option above. chronyd +keeps a record of the minimum round-trip delay amongst the previous +measurements that it has buffered. If a measurement has a round trip +delay that is greater than the maxdelayratio times the minimum delay, it +will be rejected. + +
presend
If the timing measurements being made by chronyd are the only +network data passing between two computers, you may find that some +measurements are badly skewed due to either the client or the server +having to do an ARP lookup on the other party prior to transmitting a +packet. This is more of a problem with long sampling intervals, which +may be similar in duration to the lifetime of entries in the ARP caches +of the machines. + +

In order to avoid this problem, the presend option may be used. +It takes a single integer argument, which is the smallest polling +interval for which a pair of packets will be exchanged between the +client and the server prior to the actual measurement being initiated by +the client. For example, with the following option included in a +server directive : + + 

          presend 9
+
+

when the polling interval is 512 seconds or more, a UDP echo datagram +will be sent to the server a short time (currently 4 seconds) before the +NTP client mode datagram. + +

key
The NTP protocol supports the inclusion of checksums in the packets, to +prevent computers having their system time upset by rogue packets being +sent to them. The checksums are generated as a function of a password, +using the MD5 algorithm. + +

The association between key numbers and passwords is contained in the +keys file, defined by the keyfile command. + +

If the key option is present, chronyd will attempt to use +authenticated packets when communicating with this server. The key +number used will be the single argument to the key option. The server +must have the same password for this key number configured, otherwise no +relationship between the computers will be possible. + +

offline
If the server will not be reachable when chronyd is started, the +offline option may be specified. chronyd will not try to poll +the server until it is enabled to do so (by using the online option of +chronyc). + +
auto_offline
If this option is set, the server will be assumed to have gone offline when 2 +requests have been sent to it without receiving a response. This option avoids +the need to run the offline (see offline command) command from +chrony when disconnecting the dial-up link. (It will still be necessary to use +chronyc's online (see online command) command when the link has been +established, to enable measurements to start.) + +
+ + + +
+

+Previous: Configuration file, +Up: Usage reference +
+
+ +

4.3 Running chronyc

+ + +

Chronyc is the program that can be used to reconfigure options within +the chronyd program whilst it is running. Chronyc can also be +used to generate status reports about the operation of chronyd. + +

+ + +
+

+Next: , +Up: Running chronyc +
+
+ +

4.3.1 Basic use

+ +

The program chronyc is run by entering + +

     chronyc
+
+

at the command line. The prompt chronyc is displayed whilst +chronyc is expecting input from the user, when it is being run from a +terminal. If chronyc's input or output are redirected from/to a file, +the prompt is now shown. + +

When you are finished entering commands, the commands exit or +quit will terminate the program. (Entering <Control-D> will +also terminate the program.) + + +

+

+Next: , +Previous: Chronyc basic use, +Up: Running chronyc +
+
+ +

4.3.2 Command line options

+ +

Chronyc supports the following command line options. + +

+
-v
Displays the version number of chronyc on the terminal, and exists. +
-h <host>
This option allows the user to specify which host running the +chronyd program is to be contacted. This allows for remote +configuration, without having to telnet or rlogin to the other host +first. + +

The default is to contact chronyd running on the same host as +that where chronyc is being run. +

-p <port>
This option allows the user to specify the UDP port number which the +target chronyd is using for its command & monitoring connections. +This defaults to the compiled-in default; there would rarely be a need +to change this. +
+ + +
+

+Next: , +Previous: Chronyc command line options, +Up: Running chronyc +
+
+ +

4.3.3 Security with chronyc

+ +

Many of the commands available through chronyc have a fair amount of +power to reconfigure the run-time behaviour of chronyd. Consequently, +chronyc is quite dangerous for the integrity of the target +system's clock performance. Having access to chronyd via chronyc is +more or less equivalent to being able to modify chronyd's configuration +file (typically /etc/chrony.conf) and to restart chronyd. + +

Chronyc also provides a number of monitoring (as opposed to commanding) +commands, which will not affect the behaviour of chronyd. However, you +may still want to restrict access to these commands. + +

In view of this, access to some of the capabilities of chronyc will +usually be tightly controlled. There are two mechanisms supported: + +

    +
  1. The set of hosts from which chronyd will accept commands can be +restricted. By default, commands will only be accepted from the same +host that chronyd is running on. +
  2. Any command that actually reconfigures some aspect of chronyd's +behaviour requires the user of chronyc to know a password. This +password is specified in chronyd's keys file (see keyfile directive) +and specified via the commandkey option in its configuration file +(see commandkey directive). +
+ +

Only the following commands can be used without providing a +password: + +

    +
  • exit +
  • help +
  • password +
  • quit +
  • rtcdata +
  • sources +
  • sourcestats +
  • tracking +
+ +

All other commands require a password to have been specified previously, +because they affect chronyd's operation. + + +

+

+Previous: Security with chronyc, +Up: Running chronyc +
+
+ +

4.3.4 Command reference

+ + +

This section describes each of the commands available within the chronyc +program. Chronyc offers the user a simple command-line driven +interface. + +

+ + +
+

+Next: , +Up: Chronyc command reference +
+
+ +
4.3.4.1 accheck
+ +

This command allows you to check whether client NTP access is allowed +from a particular host. + +

Examples of use, showing a named host and a numeric IP address, are as +follows: + +

     accheck a.b.c
+     accheck 1.2.3.4
+
+

This command can be used to examine the effect of a series of +allow, allow all, deny and deny all commands +specified either via chronyc, or in chronyd's configuration file. + + +

+

+Next: , +Previous: accheck command, +Up: Chronyc command reference +
+
+ +
4.3.4.2 activity
+ +

This command reports the number of servers/peers that are online and offline. +If the auto_offline option is used in specifying some of the servers/peers, the +activity command may be useful for detecting when all of them have +entered the offline state after the PPP link has been disconnected. + +

The report shows the number of servers/peers in 4 states: +

    +
  • online : the server/peer is currently online (i.e. assumed by +chronyd to be reachable) +
  • offline : the server/peer is currently offline (i.e. assumed by +chronyd to be unreachable, and no measurements from it will be attempted.) +
  • burst_online : a burst command has been initiated for the +server/peer and is being performed; after the burst is complete, the +server/peer will be returned to the online state. +
  • burst_offline : a burst command has been initiated for the +server/peer and is being performed; after the burst is complete, the +server/peer will be returned to the offline state. +
+ + +
+

+Next: , +Previous: activity command, +Up: Chronyc command reference +
+
+ +
4.3.4.3 add peer
+ +

The add peer command allows a new NTP peer to be added whilst +chronyd is running. + +

Following the words add peer, the syntax of the following +parameters and options is identical to that for the peer +directive in the configuration file (see peer directive). + +

An example of using this command is shown below. + +

     add peer foo.bar.com minpoll 6 maxpoll 10 authkey 25
+
+ + +
+

+Next: , +Previous: add peer command, +Up: Chronyc command reference +
+
+ +
4.3.4.4 add server
+ +

The add server command allows a new NTP server to be added whilst +chronyd is running. + +

Following the words add server, the syntax of the following +parameters and options is identical to that for the server +directive in the configuration file (see server directive). + +

An example of using this command is shown below. + +

     add server foo.bar.com minpoll 6 maxpoll 10 authkey 25
+
+ + +
+

+Next: , +Previous: add server command, +Up: Chronyc command reference +
+
+ +
4.3.4.5 allow
+ +

The effect of the allow command is identical to the allow directive in +the configuration file (see allow directive). + +

The syntax is illustrated in the following examples: + +

     allow foo.bar.com
+     allow 1.2
+     allow 3.4.5
+     allow 6.7.8/22
+     allow 6.7.8.9/22
+     allow
+
+

The effect of each of these examples is the same as that of the allow +directive in the configuration file. + + +

+

+Next: , +Previous: allow command, +Up: Chronyc command reference +
+
+ +
4.3.4.6 allow all
+ +

The effect of the allow command is identical to the allow all +directive in the configuration file (see allow directive). + + +

+

+Next: , +Previous: allow all command, +Up: Chronyc command reference +
+
+ +
4.3.4.7 burst
+ +

The burst command tells chronyd to make a set of measurements to +each of its sources over a short duration (rather than the usual +periodic measurements that it makes). After such a burst, chronyd will +revert to the previous state for each source. This might be either +online, if the source was being periodically measured in the normal way, +or offline, if the source had been indicated as being offline. +(Switching a source between the online and offline states is described +in online command, offline command). + +

The syntax of the burst command is as follows + +

     burst <n-good-measurements>/<max-measurements> [<mask>/<masked-address>]
+
+

The mask and masked-address arguments are optional, in which case +chronyd will initiate a burst for all of its currently defined sources. + +

The arguments have the following meaning and format. + +

+
n-good-measurements
This defines the number of good measurements that chronyd will want to +obtain from each source. A measurement is good if it passes certain +tests, for example, the round trip time to the source must be +acceptable. (This allows chronyd to reject measurements that are likely +to be bogus.) + +
max-measurements
This defines the maximum number of measurements that chronyd will +attempt to make, even if the required number of good measurements has +not been obtained. + +
mask
This is a dotted quad argument (e.g. 255.255.255.0) with which +the IP address of each of chronyd's sources is to be masked. + +
masked-address
This is a dotted quad argument (e.g. 1.2.3.0). If the masked IP +address of a source matches this value then the burst command is applied +to that source. +
+ +

If no mask or masked address arguments are provided, the default is +0.0.0.0 and 0.0.0.0 respectively, which will match every +source. + +

An example of the two-argument form of the command is + +

     burst 2/10
+
+

This will cause chronyd to attempt to get two good measurements from +each source, stopping after two have been obtained, but in no event will +it try more than ten probes to the source. + +

An example of the four-argument form of the command is + +

     burst 2/10 255.255.0.0/1.2.0.0
+
+

In this case, the two out of ten sampling will only be applied to +sources whose IP addresses are of the form 1.2.x.y, where x and y +are arbitrary. + + +

+

+Next: , +Previous: burst command, +Up: Chronyc command reference +
+
+ + +
4.3.4.8 clients
+ +

This command shows a list of all clients that have accessed the server, +through either the NTP or command/monitoring ports. There are no arguments. + +

An example of the output is + +

     Hostname                   Client    Peer CmdAuth CmdNorm  CmdBad  LstN  LstC
+     =========================  ======  ======  ======  ======  ======  ====  ====
+     localhost                       0       0      15       1       0   29y     0
+     aardvark.xxx                    4       0       0       0       0    49   29y
+     badger.xxx                      4       0       0       0       0     6   29y
+
+

Each row shows the data for a single host. Only hosts that have passed +the host access checks (set with the allow, deny, +cmdallow and cmddeny commands or configuration file +directives) are logged. + +

The columns are as follows: + +

    +
  1. The hostname of the client +
  2. The number of times the client has accessed the server using an NTP +client mode packet. +
  3. The number of times the client has accessed the server using an NTP +symmetric active mode packet. +
  4. The number of authenticated command packets that have been processed +from the client (i.e. those following a successful password +command). +
  5. The number of unauthenticated command packets that have been processed +from the client. +
  6. The number of bad command packets received from the client (not all +forms of bad packet are logged). +
  7. Time since the last NTP packet was received +
  8. Time since the last command packet was received +
+ +

The last two entries will be shown as the time since 1970 if no packet +of that type has ever been received. + + +

+

+Next: , +Previous: clients command, +Up: Chronyc command reference +
+
+ +
4.3.4.9 cmdaccheck
+ +

This command is similar to the accheck command, except that it is +used to check whether command access is permitted from a named host. + +

Examples of use are as follows: + +

     cmdaccheck a.b.c
+     cmdaccheck 1.2.3.4
+
+ + +
+

+Next: , +Previous: cmdaccheck command, +Up: Chronyc command reference +
+
+ +
4.3.4.10 cmdallow
+ +

This is similar to the allow command, except that it is used to +allow particular hosts or subnets to use the chronyc program to interact +with chronyd on the current host. + + +

+

+Next: , +Previous: cmdallow command, +Up: Chronyc command reference +
+
+ +
4.3.4.11 cmdallow all
+ +

This is similar to the allow all command, except that it is used to +allow particular hosts or subnets to use the chronyc program to interact +with chronyd on the current host. + + +

+

+Next: , +Previous: cmdallow all command, +Up: Chronyc command reference +
+
+ +
4.3.4.12 cmddeny
+ +

This is similar to the deny command, except that it is used to +allow particular hosts or subnets to use the chronyc program to interact +with chronyd on the current host. + + +

+

+Next: , +Previous: cmddeny command, +Up: Chronyc command reference +
+
+ +
4.3.4.13 cmddeny all
+ +

This is similar to the deny all command, except that it is used +to allow particular hosts or subnets to use the chronyc program to +interact with chronyd on the current host. + + +

+

+Next: , +Previous: cmddeny all command, +Up: Chronyc command reference +
+
+ +
4.3.4.14 cyclelogs
+ +

The cyclelogs command causes all of chronyd's open log files to +be closed and re-opened. This allows them to be renamed so that they can be +periodically purged. An example of how to do this is shown below. + +

     % mv /var/log/chrony/measurements.log /var/log/chrony/measurements1.log
+     % chronyc
+     chronyc> password aardvark
+     200 OK
+     chronyc> cyclelogs
+     200 OK
+     chronyc> exit
+     % ls -l /var/log/chrony
+     -rw-r--r--   1 root     root            0 Jun  8 18:17 measurements.log
+     -rw-r--r--   1 root     root        12345 Jun  8 18:17 measurements1.log
+     % rm -f measurements1.log
+
+ + +
+

+Next: , +Previous: cyclelogs command, +Up: Chronyc command reference +
+
+ +
4.3.4.15 delete
+ +

The delete command allows an NTP server or peer to be removed +from the current set of sources. + +

The syntax is illustrated in the examples below. + +

     delete foo.bar.com
+     delete 1.2.3.4
+
+

There is one parameter, the name or IP address of the server or peer to +be deleted. + + +

+

+Next: , +Previous: delete command, +Up: Chronyc command reference +
+
+ +
4.3.4.16 deny
+ +

The effect of the allow command is identical to the deny +directive in the configuration file (see deny directive). + +

The syntax is illustrated in the following examples: + +

     deny foo.bar.com
+     deny 1.2
+     deny 3.4.5
+     deny 6.7.8/22
+     deny 6.7.8.9/22
+     deny
+
+ + +
+

+Next: , +Previous: deny command, +Up: Chronyc command reference +
+
+ +
4.3.4.17 deny all
+ +

The effect of the allow command is identical to the deny all +directive in the configuration file (see deny directive). + + +

+

+Next: , +Previous: deny all command, +Up: Chronyc command reference +
+
+ +
4.3.4.18 dump
+ +

The dump command causes chronyd to write its current history of +measurements for each of its sources to dump files, either for +inspection or to support the -r option when chronyd is restarted. + +

The dump command is somewhat equivalent to the dumponexit +directive in the chrony configuration file. See dumponexit directive. + +

To use the dump, you probably want to configure the name of the +directory into which the dump files will be written. This can only be +done in the configuration file, see dumpdir directive. + + +

+

+Next: , +Previous: dump command, +Up: Chronyc command reference +
+
+ +
4.3.4.19 exit
+ +

The exit command exits from chronyc and returns the user to the shell +(same as the quit command). + + +

+

+Next: , +Previous: exit command, +Up: Chronyc command reference +
+
+ +
4.3.4.20 help
+ +

The help command displays a summary of the commands and their arguments. + + +

+

+Next: , +Previous: help command, +Up: Chronyc command reference +
+
+ +
4.3.4.21 local
+ +

The local command allows chronyd to be told that it is to appear +as a reference source, even if it is not itself properly synchronised to +an external source. (This can be used on isolated networks, to allow +one computer to be a master time server with the other computers slaving +to it.) The local command is somewhat equivalent to the +local directive in the configuration file, see local directive. + +

The syntax is as shown in the following examples. + +

     local stratum 10
+     local off
+
+

The first example enables the local reference mode on the host, and sets +the stratum at which it should claim to be synchronised. + +

The second example disables the local reference mode. + + +

+

+Next: , +Previous: local command, +Up: Chronyc command reference +
+
+ +
4.3.4.22 makestep
+ +

Normally chronyd will cause the system to gradually correct any time +offset, by slowing down or speeding up the clock as required. In +certain situations, the system clock may be so far adrift that this +slewing process would take a very long time to correct the system clock. + +

The makestep command can be used in this situation. It cancels +any remaining correction that was being slewed, and jumps the system +clock by the equivalent amount, making it correct immediately. + +

BE WARNED - certain software will be seriously affected by such jumps to +the system time. (That is the reason why chronyd uses slewing +normally.) + +

The makestep command is currently only available on the Linux +version of chrony. + + +

+

+Next: , +Previous: makestep command, +Up: Chronyc command reference +
+
+ +
4.3.4.23 manual
+ +

The manual command enables and disables use of the settime +command (see settime command), and is used to modify the behaviour +of the manual clock driver. + +

Examples of the command are shown below. + +

     manual on
+     manual off
+     manual delete 1
+     manual list
+     manual reset
+
+

The on form of the command enables use of the settime +command. + +

The off form of the command disables use of the settime +command. + +

The list form of the command lists all the samples currently +stored in chronyd. The output is illustrated below. + +

     210 n_samples = 1
+     #    Date  Time(UTC)    Slewed   Original   Residual
+     ====================================================
+      0 27Jan99 22:09:20       0.00       0.97       0.00
+
+

The columns as as follows : + +

    +
  1. The sample index (used for the manual delete command) +
  2. The date and time of the sample +
  3. The system clock error when the timestamp was entered, adjusted to allow +for changes made to the system clock since. +
  4. The system clock error when the timestamp was entered, as it originally +was (without allowing for changes to the system clock since). +
  5. The regression residual at this point, in seconds. This allows +'outliers' to be easily spotted, so that they can be deleted using the +manual delete command. +
+ +

The delete form of the command deletes a single sample. The +parameter is the index of the sample, as shown in the first column of +the output from manual list. Following deletion of the data +point, the current error and drift rate are re-estimated from the +remaining data points and the system clock trimmed if necessary. This +option is intended to allow 'outliers' to be discarded, i.e. samples +where the administrator realises he/she has entered a very poor +timestamp. + +

The reset form of the command deletes all samples at once. The +system clock is left running as it was before the command was entered. + + +

+

+Next: , +Previous: manual command, +Up: Chronyc command reference +
+
+ +
4.3.4.24 maxdelay
+ +

This allows the maxdelay option for one of the sources to be +modified, in the same way as specifying the maxdelay option for +the server directive in the configuration file (see server directive). + +

The following examples illustrate the syntax + +

     maxdelay foo.bar.com 0.3
+     maxdelay 1.2.3.4 0.0015
+
+

The first example sets the maximum network delay allowed for a +measurement to the host foo.bar.com to 0.3 seconds. The second +example sets the maximum network delay for a measurement to the host +with IP address 1.2.3.4 to 1.5 milliseconds. + +

(Any measurement whose network delay exceeds the specified value is +discarded.) + + +

+

+Next: , +Previous: maxdelay command, +Up: Chronyc command reference +
+
+ +
4.3.4.25 maxdelayratio
+ +

This allows the maxdelayratio option for one of the sources to be +modified, in the same way as specifying the maxdelayratio option +for the server directive in the configuration file (see server directive). + +

The following examples illustrate the syntax + +

     maxdelayratio foo.bar.com 1.5
+     maxdelayratio 1.2.3.4 2.0
+
+

The first example sets the maximum network delay for a measurement to +the host foo.bar.com to be 1.5 times the minimum delay found +amongst the previous measurements that have been retained. The second +example sets the maximum network delay for a measurement to the host +with IP address 1.2.3.4 to be double the retained minimum. + +

As for maxdelay, any measurement whose network delay is too large +will be discarded. + + +

+

+Next: , +Previous: maxdelayratio command, +Up: Chronyc command reference +
+
+ +
4.3.4.26 maxpoll
+ +

The maxpoll command is used to modify the minimum polling +interval for one of the current set of sources. It is equivalent to the +maxpoll option in the server directive in the +configuration file (see server directive). + +

The syntax is as follows + +

     maxpoll <host> <new-maxpoll>
+
+

where the host can be specified as either a machine name or dotted-quad +IP address. The new minimum poll is specified as a base-2 logarithm of +the number of seconds between polls (e.g. specify 6 for 64 second +sampling). + +

An example is + +

     maxpoll foo.bar.com 10
+
+

which sets the maximum polling interval for the host foo.bar.com +to 1024 seconds. + +

Note that the new maximum polling interval only takes effect after the +next measurement has been made. + + +

+

+Next: , +Previous: maxpoll command, +Up: Chronyc command reference +
+
+ +
4.3.4.27 maxupdateskew
+ +

This command has the same effect as the maxupdateskew directive +in the configuration file, see maxupdateskew directive. + + +

+

+Next: , +Previous: maxupdateskew command, +Up: Chronyc command reference +
+
+ +
4.3.4.28 minpoll
+ +

The minpoll command is used to modify the minimum polling +interval for one of the current set of sources. It is equivalent to the +minpoll option in the server directive in the +configuration file (see server directive). + +

The syntax is as follows + +

     minpoll <host> <new-minpoll>
+
+

where the host can be specified as either a machine name or dotted-quad +IP address. The new minimum poll is specified as a base-2 logarithm of +the number of seconds between polls (e.g. specify 6 for 64 second +sampling). + +

An example is + +

     minpoll foo.bar.com 5
+
+

which sets the minimum polling interval for the host foo.bar.com +to 32 seconds. + +

Note that the new minimum polling interval only takes effect after the +next measurement has been made. + + +

+

+Next: , +Previous: minpoll command, +Up: Chronyc command reference +
+
+ +
4.3.4.29 offline
+ +

The offline command is used to warn chronyd that the network +connection to a particular host or hosts is about to be lost. It should +be used on computers with a dial-up or similar connection to their time +sources, to warn chronyd that the connection is about to be broken. + +

An example of how to use offline in this case is shown in +Advising chronyd of internet availability. + +

Another case where offline could be used is where a computer +serves time to a local group of computers, and has a permanant +connection to true time servers outside the organisation. However, the +external connection is heavily loaded at certain times of the day and +the measurements obtained are less reliable at those times. In this +case, it is probably most useful to determine the gain/loss rate during +the quiet periods and let the whole network coast through the loaded +periods. The offline and online commands can be used to +achieve this. The situation is shown in the figure below. + +

               +----------+
+               |Ext source|
+               +----------+
+                   |
+                   |
+                   |/| <-- Link with variable
+                     |     reliability
+                     |
+           +-------------------+
+           |Local master server|
+           +-------------------+
+                     |
+       +---+---+-----+-----+----+----+
+       |   |   |     |     |    |    |
+                Local clients
+
+

If the source to which chronyd is currently synchronised is indicated +offline in this way, chronyd will continue to treat it as the +synchronisation source. If the network connection were broken without +the offline command being used, chronyd would assume that the +source had failed and would attempt to pick another synchronisation +source. + +

There are two forms of the offline command. The first form is a +wildcard, meaning all sources. The second form allows a IP address mask +and a masked address to be specified. These forms are illustrated below. + +

     offline
+     offline 255.255.255.0/1.2.3.0
+
+

The second form means that the offline command is to be applied +to any source whose IP address is in the 1.2.3 subnet. (The host's +address is logically and-ed with the mask, and if the result matches the +masked-address the host is processed). + +

The wildcard form of the address is actually equivalent to + +

     offline 0.0.0.0/0.0.0.0
+
+ + +
+

+Next: , +Previous: offline command, +Up: Chronyc command reference +
+
+ +
4.3.4.30 online
+ +

The online command is opposite in function to the offline +command. It is used to advise chronyd that network connectivity to a +particular source or sources has been restored. + +

The syntax is identical to that of the offline command, see +offline command. + + +

+

+Next: , +Previous: online command, +Up: Chronyc command reference +
+
+ +
4.3.4.31 password
+ +

The password command is used to allow chronyc to send privileged +commands to chronyd. The password can either be entered on the command +line, or can be entered without echoing. The syntax for entering the +password on the command line is as follows + +

     password xyzzy
+
+

To enter the password without it being echoed, enter + +

     password
+
+

The computer will respond with a Password: prompt, at which you +should enter the password and press return. (Note that the no-echo mode +is limited to 8 characters on SunOS 4.1 due to limitations in the system +library. Other systems do not have this restriction.) + +

The password is any string of characters not containing whitespace. It +has to match chronyd's currently defined command key (see commandkey directive). + + +

+

+Next: , +Previous: password command, +Up: Chronyc command reference +
+
+ +
4.3.4.32 quit
+ +

The quit command exits from chronyc and returns the user to the shell +(same as the exit command). + + +

+

+Next: , +Previous: quit command, +Up: Chronyc command reference +
+
+ +
4.3.4.33 rtcdata
+ +

The rtcdata command displays the current real time clock RTC parameters. + +

An example output is shown below. + +

     RTC ref time (GMT) : Sat May 30 07:25:56 1998
+     Number of samples  : 10
+     Number of runs     : 5
+     Sample span period :  549
+     RTC is fast by     :    -1.632736 seconds
+     RTC gains time at  :  -107.623 ppm
+
+

The fields have the following meaning + +

+
RTC ref time (GMT)
This is the RTC reading the last time its error was measured. +
Number of samples
This is the number of previous measurements being used to determine the +RTC gain/loss rate. +
Number of runs
This is the number of runs of residuals of the same sign following the +regression fit for (RTC error) versus (RTC time). A value which is +small indicates that the measurements are not well approximated by a +linear model, and that the algorithm will tend to delete the older +measurements to improve the fit. +
Sample span period
This is the period that the measurements span (from the oldest to the +newest). Without a unit the value is in seconds; suffixes `m' for +minutes, `h' for hours, `d' for days or `y' for years may be used. +
RTC is fast by
This is the estimate of how many seconds fast the RTC when it thought +the time was at the reference time (above). If this value is large, you +may (or may not) want to use the trimrtc command to bring the RTC +into line with the system clock. (Note, a large error will not affect +chronyd's operation, unless it becomes so big as to start causing +rounding errors. +
RTC gains time at
This is the amount of time gained (positive) or lost (negative) by the +real time clock for each second that it ticks. It is measured in parts +per million. So if the value shown was +1, suppose the RTC was exactly +right when it crosses a particular second boundary. Then it would be 1 +microsecond fast when it crosses its next second boundary. +
+ + +
+

+Next: , +Previous: rtcdata command, +Up: Chronyc command reference +
+
+ +
4.3.4.34 settime
+ +

The settime command allows the current time to be entered +manually, if this option has been configured into chronyd. (It may be +configured either with the manual directive in the configuration +file (see manual directive), or with the manual command of +chronyc (see manual command). + +

It should be noted that the computer's sense of time will only be as +accurate as the reference you use for providing this input (e.g. your +watch), as well as how well you can time the press of the return key. +When inputting time to an isolated network, I have a battery operated +alarm clock that is synchronised to the Rugby MSF time signal in the UK. + +

Providing your computer's time zone is set up properly, you will be able +to enter a local time (rather than UTC). + +

The response to a successful settime command indicates the amount +that the computer's clock was wrong. It should be apparent from this if +you have entered the time wrongly, e.g. with the wrong time zone. + +

The rate of drift of the system clock is estimated by a regression +process using the entered measurement and all previous measurements +entered during the present run of chronyd. However, the entered +measurement is used for adjusting the current clock offset (rather than +the estimated intercept from the regression, which is ignored). +Contrast what happens with the manual delete command, where the +intercept is used to set the current offset (since there is no +measurement that has just been typed in in that case). + +

The time is parsed by the public domain getdate algorithm. +Consequently, you can only specify time to the nearest second. + +

Examples of inputs that are valid are shown below. + +

     settime 16:30
+     settime 16:30:05
+     settime Nov 21, 1997 16:30:05
+
+

For a full description of getdate, get hold of the getdate +documentation (bundled, for example, with the source for GNU tar). + + +

+

+Next: , +Previous: settime command, +Up: Chronyc command reference +
+
+ +
4.3.4.35 sources
+ +

This command displays information about the current time sources that +chronyd is accessing. + +

The optional argument -v can be specified, meaning verbose. In +this case, extra caption lines are shown as a reminder of the meanings of the +columns. + +

     210 Number of sources = 3
+     MS Name/IP address      Stratum Poll LastRx Last sample
+     =======================================================================
+     ^+ a.b.c                    3     6    47m  -9491us[-6983us] +/-  159ms
+     ^+ d.e.f                    3     6    47m    +32ms[  +35ms] +/-  274ms
+     ^* g.h.i                    2     6    47m  +8839us[  +11ms] +/-  214ms
+
+

The columns are as follows: + +

+
M
This indicates the mode of the source. ^ means a server, += means a peer and # indicates a locally connected +reference clock1. + +
S
This column indicates the state of the sources. * indicates the +source to which chronyd is current synchronised. + indicates +other acceptable sources. ? indicates sources to which +connectivity has been lost. x indicates a clock which chronyd +thinks is is a falseticker (i.e. its time is inconsistent with a +majority of other sources). ~ indicates a source whose time +appears to have too much variability. The ~ condition is also +shown at start-up, until at least 3 samples have been gathered from it. + +
Name/IP address
This shows the name or the IP address of the source. + +
Stratum
This shows the stratum of the source, as reported in its most recently +received sample. Stratum 1 indicates a computer with a locally attached +reference clock. A computer that is synchronised to a stratum 1 +computer is at stratum 2. A computer that is synchronised to a stratum +2 computer is at stratum 3, and so on. + +
Poll
This shows the rate at which the source is being polled, as a base-2 +logarithm of the interval in seconds. Thus, a value of 6 would indicate +that a measurement is being made every 64 seconds. + +

chronyd automatically varies the polling rate in response to prevailing +conditions. + +

LastRx
This column shows how long ago the last sample was received from the +source. This is normally in seconds. The letters m, h, +d or y indicate minutes, hours, days or years. + +
Last sample
This column shows the offset between the local clock and the source at +the last measurement. The number in the square brackets shows the +actual measured offset. This may be suffixed by us (indicating +microseconds), ms (indicating milliseconds), or s +(indicating seconds). The number to the left of the square brackets +shows the original measurement, adjusted to allow for any slews applied +to the local clock since. The number following the +/- indicator +shows the margin of error in the measurement. + +

Positive offsets indicate that the local clock is fast of the source. + +

+ + +
+

+Next: , +Previous: sources command, +Up: Chronyc command reference +
+
+ +
4.3.4.36 sourcestats
+ +

The sourcestats command displays information about the drift rate +and offset estimatation process for each of the sources currently being +examined by chronyd. + +

The optional argument -v can be specified, meaning verbose. In +this case, extra caption lines are shown as a reminder of the meanings of the +columns. + +

An example report is + +

     210 Number of sources = 1
+     Name/IP Address            NP  NR  Span  Frequency   Freq Skew   Std Dev
+     ========================================================================
+     abc.def.ghi                11   5   46m      -0.001       0.045     25us
+
+

The columns are as follows + +

+
Name/IP Address
This is the name or dotted-quad IP address of the NTP server (or peer) +to which the rest of the line relates. + +
NP
This is the number of sample points currently being retained for the +server. The drift rate and current offset are estimated by performing a +linear regression through these points. + +
NR
This is the number of runs of residuals having the same sign following +the last regression. If this number starts to become too small relative +to the number of samples, it indicates that a straight line is no longer +a good fit to the data. If the number of runs is too low, +chronyd discards older samples and re-runs the regression until +the number of runs becomes acceptable. + +
Span
This is the interval between the oldest and newest samples. If no unit +is shown the value is in seconds. In the example, the interval is 46 +minutes. + +
Frequency
This is the estimated residual frequency for the server, in parts per +million. In this case, the computer's clock is estimated to be running +1 part in 10**9 slow relative to the server. + +
Freq Skew
This is the estimated error bounds on Freq (again in parts per +million). + +
Std Dev
This is the estimated sample standard deviation. + +
+ + +
+

+Next: , +Previous: sourcestats command, +Up: Chronyc command reference +
+
+ +
4.3.4.37 tracking
+ +

The tracking command displays parameters about the system's clock +performance. An example of the output is shown below. + +

     Reference ID    : 1.2.3.4 (a.b.c)
+     Stratum         : 3
+     Ref time (UTC)  : Sun May 17 06:13:11 1998
+     System time     : 0.000000 seconds fast of NTP time
+     Frequency       : 331.898 ppm fast
+     Residual freq   : 0.004 ppm
+     Skew            : 0.154 ppm
+     Root delay      : 0.373169 seconds
+     Root dispersion : 0.024780 seconds
+
+

The fields are explained as follows. + +

+
Reference ID
This is the IP address, and name if available, of the server to which +the computer is currently synchronised. If this is 127.127.1.1 +it means the computer is not synchronised to any external source and +that you have the `local' mode operating (via the local command +in chronyc (see local command), or the local directive +in the /etc/chrony.conf file (see local directive)). + +
Stratum
The stratum indicates how many hops away from a computer with an +attached reference clock we are. Such a computer is a stratum-1 +computer, so the computer in the example is two hops away +(i.e. a.b.c is a stratum-2 and is synchronised from a stratum-1). + +
Ref time
This is the time (GMT) at which the last measurement from the reference +source was processed. + +
System time
In normal operation, chronyd never steps the system clock, +because any jump in the timescale can have adverse consequences for +certain application programs. Instead, any error in the system clock is +corrected by slightly speeding up or slowing down the system clock until +the error has been removed, and then returning to the system clock's +normal speed. A consequence of this is that there will be a period when +the system clock (as read by other programs using the +gettimeofday() system call, or by the date command in the +shell) will be different from chronyd's estimate of the current +true time (which it reports to NTP clients when it is operating in +server mode). The value reported on this line is the difference due to +this effect. + +

On systems such as Solaris and SunOS, chronyd has no means to +adjust the fundamental rate of the system clock, so keeps the system +time correct by periodically making offsets to it as though an error had +been measured. The build up of these offsets will be observed in this +report. On systems such as Linux where chronyd can adjust the +fundamental rate of the system clock, this value will show zero unless a +very recent measurement has shown the system to be error. + +

Frequency
The `frequency' is the rate by which the system's clock would be would +be wrong if chronyd was not correcting it. It is expressed in +ppm (parts per million). For example, a value of 1ppm would mean that +when the system's clock thinks it has advanced 1 second, it has actually +advanced by 1.000001 seconds relative to true time. + +

As you can see in the example, the clock in the computer I developed +chrony on is not a very good one - it gains about 30 seconds per +day! This was the reason I started to write chrony in the first +place. + +

Residual freq
This shows the `residual frequency' for the currently selected reference +source. This reflects any difference between what the measurements from +the reference source indicate the frequency should be and the frequency +currently being used. + +

The reason this is not always zero is that a smoothing procedure is +applied to the frequency. Each time a measurement from the reference +source is obtained and a new residual frequency computed, the estimated +accuracy of this residual is compared with the estimated accuracy (see +`skew' next) of the existing frequency value. A weighted average is +computed for the new frequency, with weights depending on these +accuracies. If the measurements from the reference source follow a +consistent trend, the residual will be driven to zero over time. + +

Skew
This is the estimated error bound on the the frequency. + +
Root delay
This is the total of the network path delays to the stratum-1 computer +from which the computer is ultimately synchronised. + +

In certain extreme situations, this value can be negative. (This can +arise in a symmetric peer arrangement where the computers' frequencies +are not tracking each other and the network delay is very short relative +to the turn-around time at each computer.) + +

Root dispersion
This is the total dispersion accumulated through all the computers back +to the stratum-1 computer from which the computer is ultimately +synchronised. Dispersion is due to system clock resolution, statistical +measurement variations etc. + +

An absolute bound on the computer's clock accuracy (assuming the +stratum-1 computer is correct) is given by + + 

          clock_error <= root_dispersion + (0.5 * |root_delay|)
+
+
+ + +
+

+Next: , +Previous: tracking command, +Up: Chronyc command reference +
+
+ +
4.3.4.38 trimrtc
+ +

The trimrtc command is used to correct the system's real time +clock (RTC) to the main system clock. It has no effect if the error +between the two clocks is currently estimated at less than a second (the +resolution of the RTC is only 1 second). + +

The command takes no arguments. It performs the following steps (if the +RTC is more than 1 second away from the system clock): + +

    +
  1. Remember the currently estimated gain/loss rate of the RTC and flush the +previous measurements. +
  2. Step the real time clock to bring it within a second of the system clock. +
  3. Make several measurements to accurately determine the new offset between +the RTC and the system clock (i.e. the remaining fraction of a second +error) +
  4. Save the RTC parameters to the RTC file (specified with the +rtcfile directive in the configuration file (see rtcfile directive). +
+ +

The last step is done as a precaution against the computer suffering a +power failure before either the daemon exits or the writertc +command is issued. + +

chronyd will still work perfectly well both whilst operating and +across machine reboots even if the trimrtc command is never used +(and the RTC is allowed to drift away from true time). The +trimrtc command is provided as a method by which it can be +corrected, in a manner compatible with chronyd using it to +maintain accurate time across machine reboots. + + +

+

+Previous: trimrtc command, +Up: Chronyc command reference +
+
+ +
4.3.4.39 writertc
+ +

The writertc command writes the currently estimated error and +gain/loss rate parameters for the RTC to the RTC file (specified with +the rtcfile directive (see rtcfile directive)). This +information is also written automatically when chronyd is killed +(with SIGHUP, SIGINT, SIGQUIT or SIGTERM). + + + + + +

+

+Next: , +Previous: Usage reference, +Up: Top +
+
+ +

Appendix A Porting guide

+ + +

This appendix discusses issues that have arisen in writing the +system-specific parts of the existing ports. This will provide useful +information for those attempting to write ports to other systems. + +

+ + +
+

+Next: , +Up: Porting guide +
+
+ +

A.1 System driver files

+ +

The system specific parts of the software are contained in files with +names like sys_linux.c. + +

The following functions are required in a system driver file: + +

    +
  1. A function to read the current frequency +
  2. A function to set the current frequency +
  3. A function to slew the system time by a specified delta +
  4. A function to step the system time by a specified delta +
  5. A function to work out the error at a particular time between the +system's clock and chronyd's estimate of real time. (This is required +because some systems have to track real time by making the system time +follow it in a 'sawtooth' fashion). +
+ +

The frequency is the rate at which the system gains or loses time, +measured relative to the system when running uncompensated. + + +

+

+Previous: System driver files, +Up: Porting guide +
+
+ +

A.2 Quirks of particular systems

+ + +

These sections describe quirks in each system type that needed to be +investigated to port the software to each system type. + +

+ + +
+

+Next: , +Up: Quirks of particular systems +
+
+ +

A.2.1 Linux

+ +

The following quirks have been found in developing the Linux port. + +

    +
  1. In order to avoid floating point arithmetic, the kernel uses shifting +and adding to approximate a scaling of 100/128. This approximation +implies that the frequency set via the adjtimex() system call is +not the frequency that is actually obtained. The method of +approximation varies between kernel versions and must be determined by +examining the kernel source. An inverse factor must be included in the +driver to compensate. +
  2. In some kernel versions, an adjtimex() system call with the flags +bits all zeroed will return the amount of offset still to be corrected. +In others (e.g. the 2.0 series beyond 2.0.32), the offset must be +changed in order to get the old offset returned (similar to +adjtime() on other systems). + +
+ + +
+

+Next: , +Previous: Linux porting quirks, +Up: Quirks of particular systems +
+
+ +

A.2.2 Solaris 2.5

+ +

The following quirks have been found in developing the Solaris port. + +

    +
  1. The adjtime() system call with a zero argument does not cancel an +adjustment that is in progress - it just reports the remaining +adjustment. +
  2. The settimeofday() system call only observes the seconds part of +the argument - any fractional seconds part is lost. +second. +
  3. The kernel variable dosynctodr has to be set to zero, otherwise +the system clock is periodically reset to the real-time clock. +
+ + +
+

+Previous: Solaris 2.5 porting quirks, +Up: Quirks of particular systems +
+
+ +

A.2.3 SunOS 4.1.4

+ +

The following quirks have been found in developing the SunOS port. + +

    +
  1. The adjtime() system call truncates its argument to a multiple of +the system's tickadj variable. (chronyd sets that to 100, +giving a 1 part in 100 slewing capability for correcting offsets.) +
  2. The kernel variable dosynctodr has to be set to zero, otherwise +the system clock is periodically reset to the real-time clock. +
+ + + + +
+

+Previous: Porting guide, +Up: Top +
+
+ +

Appendix B GNU General Public License

+ +
GNU GENERAL PUBLIC LICENSE
+
Version 2, June 1991
+ +

Copyright (C) 1989, 1991 Free Software Foundation, Inc. + 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +

Preamble + +

The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +License is intended to guarantee your freedom to share and change free +software–to make sure the software is free for all its users. This +General Public License applies to most of the Free Software +Foundation's software and to any other program whose authors commit to +using it. (Some other Free Software Foundation software is covered by +the GNU Library General Public License instead.) You can apply it to +your programs, too. + +

When we speak of free software, we are referring to freedom, not +price. Our General Public Licenses are designed to make sure that you +have the freedom to distribute copies of free software (and charge for +this service if you wish), that you receive source code or can get it +if you want it, that you can change the software or use pieces of it +in new free programs; and that you know you can do these things. + +

To protect your rights, we need to make restrictions that forbid +anyone to deny you these rights or to ask you to surrender the rights. +These restrictions translate to certain responsibilities for you if you +distribute copies of the software, or if you modify it. + +

For example, if you distribute copies of such a program, whether +gratis or for a fee, you must give the recipients all the rights that +you have. You must make sure that they, too, receive or can get the +source code. And you must show them these terms so they know their +rights. + +

We protect your rights with two steps: (1) copyright the software, and +(2) offer you this license which gives you legal permission to copy, +distribute and/or modify the software. + +

Also, for each author's protection and ours, we want to make certain +that everyone understands that there is no warranty for this free +software. If the software is modified by someone else and passed on, we +want its recipients to know that what they have is not the original, so +that any problems introduced by others will not reflect on the original +authors' reputations. + +

Finally, any free program is threatened constantly by software +patents. We wish to avoid the danger that redistributors of a free +program will individually obtain patent licenses, in effect making the +program proprietary. To prevent this, we have made it clear that any +patent must be licensed for everyone's free use or not licensed at all. + +

The precise terms and conditions for copying, distribution and +modification follow. + +

GNU GENERAL PUBLIC LICENSE + TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION + +

0. This License applies to any program or other work which contains +a notice placed by the copyright holder saying it may be distributed +under the terms of this General Public License. The "Program", below, +refers to any such program or work, and a "work based on the Program" +means either the Program or any derivative work under copyright law: +that is to say, a work containing the Program or a portion of it, +either verbatim or with modifications and/or translated into another +language. (Hereinafter, translation is included without limitation in +the term "modification".) Each licensee is addressed as "you". + +

Activities other than copying, distribution and modification are not +covered by this License; they are outside its scope. The act of +running the Program is not restricted, and the output from the Program +is covered only if its contents constitute a work based on the +Program (independent of having been made by running the Program). +Whether that is true depends on what the Program does. + +

1. You may copy and distribute verbatim copies of the Program's +source code as you receive it, in any medium, provided that you +conspicuously and appropriately publish on each copy an appropriate +copyright notice and disclaimer of warranty; keep intact all the +notices that refer to this License and to the absence of any warranty; +and give any other recipients of the Program a copy of this License +along with the Program. + +

You may charge a fee for the physical act of transferring a copy, and +you may at your option offer warranty protection in exchange for a fee. + +

2. You may modify your copy or copies of the Program or any portion +of it, thus forming a work based on the Program, and copy and +distribute such modifications or work under the terms of Section 1 +above, provided that you also meet all of these conditions: + +

a) You must cause the modified files to carry prominent notices + stating that you changed the files and the date of any change. + +

b) You must cause any work that you distribute or publish, that in + whole or in part contains or is derived from the Program or any + part thereof, to be licensed as a whole at no charge to all third + parties under the terms of this License. + +

c) If the modified program normally reads commands interactively + when run, you must cause it, when started running for such + interactive use in the most ordinary way, to print or display an + announcement including an appropriate copyright notice and a + notice that there is no warranty (or else, saying that you provide + a warranty) and that users may redistribute the program under + these conditions, and telling the user how to view a copy of this + License. (Exception: if the Program itself is interactive but + does not normally print such an announcement, your work based on + the Program is not required to print an announcement.) + +

These requirements apply to the modified work as a whole. If +identifiable sections of that work are not derived from the Program, +and can be reasonably considered independent and separate works in +themselves, then this License, and its terms, do not apply to those +sections when you distribute them as separate works. But when you +distribute the same sections as part of a whole which is a work based +on the Program, the distribution of the whole must be on the terms of +this License, whose permissions for other licensees extend to the +entire whole, and thus to each and every part regardless of who wrote it. + +

Thus, it is not the intent of this section to claim rights or contest +your rights to work written entirely by you; rather, the intent is to +exercise the right to control the distribution of derivative or +collective works based on the Program. + +

In addition, mere aggregation of another work not based on the Program +with the Program (or with a work based on the Program) on a volume of +a storage or distribution medium does not bring the other work under +the scope of this License. + +

3. You may copy and distribute the Program (or a work based on it, +under Section 2) in object code or executable form under the terms of +Sections 1 and 2 above provided that you also do one of the following: + +

a) Accompany it with the complete corresponding machine-readable + source code, which must be distributed under the terms of Sections + 1 and 2 above on a medium customarily used for software interchange; or, + +

b) Accompany it with a written offer, valid for at least three + years, to give any third party, for a charge no more than your + cost of physically performing source distribution, a complete + machine-readable copy of the corresponding source code, to be + distributed under the terms of Sections 1 and 2 above on a medium + customarily used for software interchange; or, + +

c) Accompany it with the information you received as to the offer + to distribute corresponding source code. (This alternative is + allowed only for noncommercial distribution and only if you + received the program in object code or executable form with such + an offer, in accord with Subsection b above.) + +

The source code for a work means the preferred form of the work for +making modifications to it. For an executable work, complete source +code means all the source code for all modules it contains, plus any +associated interface definition files, plus the scripts used to +control compilation and installation of the executable. However, as a +special exception, the source code distributed need not include +anything that is normally distributed (in either source or binary +form) with the major components (compiler, kernel, and so on) of the +operating system on which the executable runs, unless that component +itself accompanies the executable. + +

If distribution of executable or object code is made by offering +access to copy from a designated place, then offering equivalent +access to copy the source code from the same place counts as +distribution of the source code, even though third parties are not +compelled to copy the source along with the object code. + +

4. You may not copy, modify, sublicense, or distribute the Program +except as expressly provided under this License. Any attempt +otherwise to copy, modify, sublicense or distribute the Program is +void, and will automatically terminate your rights under this License. +However, parties who have received copies, or rights, from you under +this License will not have their licenses terminated so long as such +parties remain in full compliance. + +

5. You are not required to accept this License, since you have not +signed it. However, nothing else grants you permission to modify or +distribute the Program or its derivative works. These actions are +prohibited by law if you do not accept this License. Therefore, by +modifying or distributing the Program (or any work based on the +Program), you indicate your acceptance of this License to do so, and +all its terms and conditions for copying, distributing or modifying +the Program or works based on it. + +

6. Each time you redistribute the Program (or any work based on the +Program), the recipient automatically receives a license from the +original licensor to copy, distribute or modify the Program subject to +these terms and conditions. You may not impose any further +restrictions on the recipients' exercise of the rights granted herein. +You are not responsible for enforcing compliance by third parties to +this License. + +

7. If, as a consequence of a court judgment or allegation of patent +infringement or for any other reason (not limited to patent issues), +conditions are imposed on you (whether by court order, agreement or +otherwise) that contradict the conditions of this License, they do not +excuse you from the conditions of this License. If you cannot +distribute so as to satisfy simultaneously your obligations under this +License and any other pertinent obligations, then as a consequence you +may not distribute the Program at all. For example, if a patent +license would not permit royalty-free redistribution of the Program by +all those who receive copies directly or indirectly through you, then +the only way you could satisfy both it and this License would be to +refrain entirely from distribution of the Program. + +

If any portion of this section is held invalid or unenforceable under +any particular circumstance, the balance of the section is intended to +apply and the section as a whole is intended to apply in other +circumstances. + +

It is not the purpose of this section to induce you to infringe any +patents or other property right claims or to contest validity of any +such claims; this section has the sole purpose of protecting the +integrity of the free software distribution system, which is +implemented by public license practices. Many people have made +generous contributions to the wide range of software distributed +through that system in reliance on consistent application of that +system; it is up to the author/donor to decide if he or she is willing +to distribute software through any other system and a licensee cannot +impose that choice. + +

This section is intended to make thoroughly clear what is believed to +be a consequence of the rest of this License. + +

8. If the distribution and/or use of the Program is restricted in +certain countries either by patents or by copyrighted interfaces, the +original copyright holder who places the Program under this License +may add an explicit geographical distribution limitation excluding +those countries, so that distribution is permitted only in or among +countries not thus excluded. In such case, this License incorporates +the limitation as if written in the body of this License. + +

9. The Free Software Foundation may publish revised and/or new versions +of the General Public License from time to time. Such new versions will +be similar in spirit to the present version, but may differ in detail to +address new problems or concerns. + +

Each version is given a distinguishing version number. If the Program +specifies a version number of this License which applies to it and "any +later version", you have the option of following the terms and conditions +either of that version or of any later version published by the Free +Software Foundation. If the Program does not specify a version number of +this License, you may choose any version ever published by the Free Software +Foundation. + +

10. If you wish to incorporate parts of the Program into other free +programs whose distribution conditions are different, write to the author +to ask for permission. For software which is copyrighted by the Free +Software Foundation, write to the Free Software Foundation; we sometimes +make exceptions for this. Our decision will be guided by the two goals +of preserving the free status of all derivatives of our free software and +of promoting the sharing and reuse of software generally. + +

NO WARRANTY + +

11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY +FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN +OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES +PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED +OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF +MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS +TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE +PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, +REPAIR OR CORRECTION. + +

12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING +WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR +REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, +INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING +OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED +TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY +YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER +PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE +POSSIBILITY OF SUCH DAMAGES. + +

END OF TERMS AND CONDITIONS + +

Appendix: How to Apply These Terms to Your New Programs + +

If you develop a new program, and you want it to be of the greatest +possible use to the public, the best way to achieve this is to make it +free software which everyone can redistribute and change under these terms. + +

To do so, attach the following notices to the program. It is safest +to attach them to the start of each source file to most effectively +convey the exclusion of warranty; and each file should have at least +the "copyright" line and a pointer to where the full notice is found. + +

<one line to give the program's name and a brief idea of what it does.> + Copyright (C) 19yy <name of author> + +

This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + +

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., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + +

Also add information on how to contact you by electronic and paper mail. + +

If the program is interactive, make it output a short notice like this +when it starts in an interactive mode: + +

Gnomovision version 69, Copyright (C) 19yy name of author + Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. + This is free software, and you are welcome to redistribute it + under certain conditions; type `show c' for details. + +

The hypothetical commands `show w' and `show c' should show the appropriate +parts of the General Public License. Of course, the commands you use may +be called something other than `show w' and `show c'; they could even be +mouse-clicks or menu items–whatever suits your program. + +

You should also get your employer (if you work as a programmer) or your +school, if any, to sign a "copyright disclaimer" for the program, if +necessary. Here is a sample; alter the names: + +

Yoyodyne, Inc., hereby disclaims all copyright interest in the program + `Gnomovision' (which makes passes at compilers) written by James Hacker. + +

<signature of Ty Coon>, 1 April 1989 + Ty Coon, President of Vice + +

This General Public License does not permit incorporating your program into +proprietary programs. If your program is a subroutine library, you may +consider it more useful to permit linking proprietary applications with the +library. If this is what you want to do, use the GNU Library General +Public License instead of this License. + +

+

Table of Contents

+ +
+ + + +
+
+

Footnotes

[1] In the current version this will never be +shown, because chronyd has no support for reference clocks yet.

+ +

+ + + --- chrony-1.21z.orig/chrony.info +++ chrony-1.21z/chrony.info @@ -0,0 +1,4172 @@ +This is chrony.info, produced by makeinfo version 4.7 from chrony.texi. + +INFO-DIR-SECTION Net Utilities +START-INFO-DIR-ENTRY +* chrony: (chrony). How to use chronyd and chronyc +* chronyd: (chrony)Starting chronyd. Reference for chronyd +* chronyc: (chrony)Running chronyc. Reference for chronyc +END-INFO-DIR-ENTRY + + +File: chrony.info, Node: Top, Next: Introduction, Up: (dir) + +User guide for the chrony suite +******************************* + +* Menu: + +* Introduction:: What the chrony suite does +* Installation:: How to compile and install the software +* Typical scenarios:: How to configure the software for some common cases +* Usage reference:: Reference manual +* Porting guide:: Hints to help with porting the software +* GPL:: The GNU General Public License + + +File: chrony.info, Node: Introduction, Next: Installation, Prev: Top, Up: Top + +1 Introduction +************** + +* Menu: + +* Overview:: What the programs do +* Acknowledgements:: Credit where credit is due +* Availability:: Where to get the software +* Other time synchronisation packages:: Comparision with other software +* Distribution and warranty:: There is no warranty +* Bug reporting:: How to report bugs and make suggestions +* Contributing:: Areas where contributions are particularly welcome + + +File: chrony.info, Node: Overview, Next: Acknowledgements, Up: Introduction + +1.1 Overview +============ + +Chrony is a software package for maintaining the accuracy of computer +system clocks. It consists of a pair of programs : + + * `chronyd'. This is a daemon which runs in background on the + system. It obtains measurements (e.g. via the network) of the + system's offset relative to other systems, and adjusts the system + time accordingly. For isolated systems, the user can periodically + enter the correct time by hand (using `chronyc'). In either case, + `chronyd' determines the rate at which the computer gains or loses + time, and compensates for this. + + `chronyd' can also act as an NTP server, and provide a time-of-day + service to other computers. A typical set-up is to run `chronyd' + on a gateway computer that has a dial-up link to the Internet, and + use it to serve time to computers on a private LAN sitting behind + the gateway. The IP addresses that can act as clients of + `chronyd' can be tightly controlled. The default is no client + access. + + * `chronyc'. This is a command-line driven control and monitoring + program. An administrator can use this to fine-tune various + parameters within the daemon, add or delete servers etc whilst the + daemon is running. + + The IP addresses from which `chronyc' clients may connect can be + tightly controlled. The default is just the computer that + `chronyd' itself is running on. + + +File: chrony.info, Node: Acknowledgements, Next: Availability, Prev: Overview, Up: Introduction + +1.2 Acknowledgements +==================== + +The `chrony' suite makes use of the algorithm known as _RSA Data +Security, Inc. MD5 Message-Digest Algorithm_ for authenticating +messages between different machines on the network. + + In writing the `chronyd' program, extensive use has been made of +RFC1305, written by David Mills. I have occasionally referred to the +`xntp' suite's source code to check details of the protocol that the +RFC did not make absolutely clear. The core algorithms in `chronyd' +are all completely distinct from `xntp', however. + + +File: chrony.info, Node: Availability, Next: Other time synchronisation packages, Prev: Acknowledgements, Up: Introduction + +1.3 Availability +================ + +* Menu: + +* Getting the software:: Where can I get the software from? +* Platforms:: Which platforms will it run on? + + +File: chrony.info, Node: Getting the software, Next: Platforms, Up: Availability + +1.3.1 Getting the software +-------------------------- + +Links on the chrony home page (http://chrony.sunsite.dk/download.php) +describe how to obtain the software. + + +File: chrony.info, Node: Platforms, Prev: Getting the software, Up: Availability + +1.3.2 Platforms +--------------- + +Although most of the program is portable between Unix-like systems, +there are parts that have to be tailored to each specific vendor's +system. These are the parts that interface with the operating system's +facilities for adjusting the system clock; different operating systems +may provide different function calls to achieve this, and even where +the same function is used it may have different quirks in its behaviour. + + The software is known to work in the following environments: + * Linux/i386 and Linux/ppc. The software is known to work on Linux + 2.0.x, 2.2.x and 2.4.x. Prior to 2.0.31, the real time clock + can't be used. + + * NetBSD + + * BSD/386 + + * Solaris 2.3/2.5/2.5.1/2.6/2.7/2.8 on Sparc (Sparc 20, Ultrasparc) + and i386 + + * SunOS 4.1.4 on Sparc 2 and Sparc20. + + Closely related systems may work too, but they have not been tested. + + Porting the software to other system (particularly to those +supporting an `adjtime' system call) should not be difficult, however it +requires access to such systems to test out the driver. + + +File: chrony.info, Node: Other time synchronisation packages, Next: Distribution and warranty, Prev: Availability, Up: Introduction + +1.4 Relationship to other software packages +=========================================== + +* Menu: + +* Comparison with xntpd:: +* Comparison with timed:: + + +File: chrony.info, Node: Comparison with xntpd, Next: Comparison with timed, Up: Other time synchronisation packages + +1.4.1 xntpd +----------- + +The `reference' implementation of the Network Time Protocol is the +program `xntpd', available via The NTP home page +(http://www.eecis.udel.edu/~ntp). + + `xntpd' is designed to support all the operating modes defined by +RFC1305, and has driver support for a large number of reference clocks +(such as GPS receivers) that can be connected directly to a computer, +thereby providing a so-called 'stratum 1' server. + + Things `chronyd' can do that `xntpd' can't: + + * `chronyd' can perform usefully in an environment where access to + the time reference is intermittent. `chronyd' estimates _both_ + the current time offset _and_ the rate at which the computer's + clock gains or loses time, and can use that rate estimate to trim + the clock after the reference disappears. `xntpd' corrects any + time offset by speeding up and slowing down the computer clock, and + so could be left with a significant rate error if the reference + disappears whilst it is trying to correct a big offset. + + * `chronyd' provides support for isolated networks whether the only + method of time correction is manual entry (e.g. by the + administrator looking at a clock). `chronyd' can look at the + errors corrected at different updates to work out the rate at + which the computer gains or loses time, and use this estimate to + trim the computer clock subsequently. + + * `chronyd' provides support to work out the gain or loss rate of the + `real-time clock', i.e. the clock that maintains the time when the + computer is turned off. It can use this data when the system + boots to set the system time from a corrected version of the + real-time clock. These real-time clock facilities are only + available on certain releases of Linux, so far. + + * The `xntpd' program is supported by other programs to carry out + certain functions. `ntpdate' is used to provide an initial + correction to the system clock based on a `one-shot' sampling of + other NTP servers. `tickadj' is used to adjust certain operating + system parameters to make `xntpd' work better. All this + functionality is integrated into `chronyd'. + + Things `xntpd' can do that `chronyd' can't: + + * `xntpd' supports a range of different hardware reference clocks + (GPS, atomic etc) that can be connected to a computer to provide a + `stratum-1' server. `chronyd' does not support any such hardware + _yet_; I don't have access to any to do any development work. + However, the software architecture should allow such equipment to + be interfaced at a later date. + + * `xntpd' supports effectively all of RFC1305, including broadcast / + multicast clients, leap seconds, and extra encryption schemes for + authenticating data packets. + + * `xntpd' has been ported to more types of computer / operating + system (so far). + + * xntpd is designed to work solely with integer arithmetic (i.e. + does not require floating point support from its host). + + +File: chrony.info, Node: Comparison with timed, Prev: Comparison with xntpd, Up: Other time synchronisation packages + +1.4.2 timed +----------- + +`timed' is a program that is part of the BSD networking suite. It uses +broadcast packets to find all machines running the daemon within a +subnet. The machines elect a master which periodically measures the +system clock offsets of the other computers using ICMP timestamps. +Corrections are sent to each member as a result of this process. + + Problems that may arise with `timed' are : + + * Because it uses broadcasts, it is not possible to isolate its + functionality to a particular group of computers; there is a risk + of upsetting other computers on the same network (e.g. where a + whole company is on the same subnet but different departments are + independent from the point of view of administering their + computers.) + + * The update period appears to be 10 minutes. Computers can build up + significant offsets relative to each other in that time. If a + computer can estimate its rate of drift it can keep itself closer + to the other computers between updates by adjusting its clock + every few seconds. `timed' does not seem to do this. + + * `timed' does not have any integrated capability for feeding + real-time into its estimates, or for estimating the average rate + of time loss/gain of the machines relative to real-time (unless + one of the computers in the group has access to an external + reference and is always appointed as the `master'). + + `timed' does have the benefit over `chronyd' that for isolated +networks of computers, they will track the `majority vote' time. For +such isolated networks, `chronyd' requires one computer to be the +`master' with the others slaved to it. If the master has a particular +defective clock, the whole set of computers will tend to slip relative +to real time (but they _will_ stay accurate relative to one another). + + +File: chrony.info, Node: Distribution and warranty, Next: Bug reporting, Prev: Other time synchronisation packages, Up: Introduction + +1.5 Distribution rights and (lack of) warranty +============================================== + +Chrony may be distributed in accordance with the GNU General Public +License version 2, reproduced in *Note GPL::. + + +File: chrony.info, Node: Bug reporting, Next: Contributing, Prev: Distribution and warranty, Up: Introduction + +1.6 Bug reporting and suggestions +================================= + +If you think you've found a bug in chrony, or have a suggestion, please +let me know. My primary current email address is . If +that fails, you could try finding me through one of the chrony mailing +lists, or by looking up my name on a search engine. + + I can't promise a timescale to fix a bug; it depends a lot on the +how complex the bug is to track down, as I have a lot of other calls on +my time : 2 young children, my job, and indeed other free/open source +software projects. However, I do intend to look into problems when +time allows. + + Another source of information to try is the chrony users mailing +list. You can join this by sending an empty message to +. Only subscribers can post to the +list. + + When you are reporting a bug, please send me all the information you +can. Unfortunately, chrony has proven to be one of those programs +where it is very difficult to reproduce bugs in a different +environment. So I may have to interact with you quite a lot to obtain +enough extra logging and tracing to pin-point the problem in some +cases. Please be patient and plan for this! + + Of course, if you can debug the problem yourself and send me a +source code patch to fix it, I will be very grateful! + + +File: chrony.info, Node: Contributing, Prev: Bug reporting, Up: Introduction + +1.7 Contributions +================= + +Although chrony is now a fairly mature and established project, there +are still areas that could be improved. If you can program in C and +have some expertise in these areas, you might be able to fill the gaps. + + Particular areas I know need addressing are : + + 1. Porting to other Unices + + This involves creating equivalents of sys_solaris.c, sys_linux.c + etc for the new system. Note, the Linux driver has been reported + as working on a range of different architectures (Alpha, Sparc, + MIPS as well as x86 of course). + + 2. Porting to Windows NT + + I did a small amount of work on this under Cygwin. Only the + sorting out of the include files has really been achieved so far. + The two main areas still to address are + + 1. The system clock driver. + + 2. How to make chronyd into an NT service (i.e. what to replace + fork(), setsid() etc with so that chronyd can be + automatically started in the system bootstrap. + + 3. Hardware clock support + + 4. Automation of the trimrtc and writertc mechanisms + + Currently, the RTC trimming mechanism is a manual operation, + because there has to be a reasonable guarantee that the system + will stay up for a reasonable length of time afterwards. (If it + is shut down too soon, a poor characterisation of the RTC drift + rate will be stored on disc, giving a bad system clock error when + the system is next booted.) + + To make chrony more automated for the non-expert user, it would be + useful if this problem could be avoided so that trimrtc could be + done automatically (e.g. in a crontab, or as part of the ip-up or + ip-down scripts.) + + + +File: chrony.info, Node: Installation, Next: Typical scenarios, Prev: Introduction, Up: Top + +2 Installation +************** + +The software is distributed as source code which has to be compiled. +The source code is supplied in the form of a gzipped tar file, which +unpacks to a subdirectory identifying the name and version of the +program. + + After unpacking the source code, change directory into it, and type + + ./configure + + This is a shell script that automatically determines the system type. +There is a single optional parameter, `--prefix' which indicates the +directory tree where the software should be installed. For example, + + ./configure --prefix=/opt/free + + will install the `chronyd' daemon into /opt/free/sbin and the +chronyc control program into /opt/free/bin. The default value for the +prefix is /usr/local. + + The configure script assumes you want to use gcc as your compiler. +If you want to use a different compiler, you can configure this way: + + CC=cc CFLAGS=-O ./configure --prefix=/opt/free + + for Bourne-family shells, or + + setenv CC cc + setenv CFLAGS -O + ./configure --prefix=/opt/free + + for C-family shells. + + If the software cannot (yet) be built on your system, an error +message will be shown. Otherwise, the files `options.h' and `Makefile' +will be generated. + + By default, chronyc will be built to make use of the readline +library. If you don't want this, specify the -disable-readline flag to +configure. If you have readline and/or ncurses installed in a +non-standard location, please refer to *note readline support:: for +information. + + Now type + + make + + to build the programs. + + If you want to build the manual in plain text, HTML and info +versions, type + + make docs + + Once the programs have been successfully compiled, they need to be +installed in their target locations. This step normally needs to be +performed by the superuser, and requires the following command to be +entered. + + make install + + This will install the binaries, plain text manual and manpages. + + To install the HTML and info versions of the manual as well, enter +the command + + make install-docs + + If you want chrony to appear in the top level info directory +listing, you need to run the `install-info' command manually after this +step. `install-info' takes 2 arguments. The first is the path to the +`chrony.info' file you have just installed. This will be the argument +you gave to -prefix when you configured (`/usr/local' by default), with +`/info/chrony.info' on the end. The second argument is the location of +the file called `dir'. This will typically be `/usr/info/dir'. So the +typical command line would be + + install-info /usr/local/info/chrony.info /usr/info/dir + + Now that the software is successfully installed, the next step is to +set up a configuration file. The contents of this depend on the +network environment in which the computer operates. The Debian package +installs a simple configuration file suitable for a dial-up pc. You +should edit it to suit your situation. Typical scenarios are described +in the following section of the document. + +* Menu: + +* readline support:: If readline or ncurses in in a non-standard place +* package builders:: Extra options useful to package builders + + +File: chrony.info, Node: readline support, Next: package builders, Up: Installation + +2.1 Support for the readline library +==================================== + +By default, chronyc is built to make use of the readline library. This +allows you to use the cursor keys to replay and edit old commands. If +you don't want to use readline (in which case chronyc will use a +minimal command line interface), invoke configure like this: + + ./configure --disable-readline other-options... + + If you have readline and/or ncurses installed in locations that +aren't normally searched by the compiler and linker, you need extra +options if you want readline to be used: + +`--with-readline-includes=directory_name' + This defines the name of the directory above the one where + `readline.h' is. `readline.h' is assumed to be in a `readline' + subdirectory of the named directory. + +`--with-readline-library=directory_name' + This defines the directory containing the `libreadline.a' or + `libreadline.so' file. + +`--with-ncurses-library=directory_name' + This defines the directory containing the `libncurses.a' or + `libncurses.so' file. + + +File: chrony.info, Node: package builders, Prev: readline support, Up: Installation + +2.2 Extra options for package builders +====================================== + +The configure and make procedures have some extra options that may be +useful if you are building a distribution package for chrony. + + The -infodir=DIR option to configure specifies a different install +directory for the info files. This overrides the `info' subdirectory +of the argument to the -prefix option. For example, you might use + + ./configure --prefix=/usr --infodir=/usr/share/info + + The -mandir=DIR option to configure specifies a different install +directory for the man pages. This overrides the `man' subdirectory of +the argument to the -prefix option. + + ./configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man + + to set both options together. + + The final option is the DESTDIR option to the make command. For +example, you could use the commands + + ./configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man + make all docs + make install DESTDIR=./tmp + cd tmp + tar cvf - . | gzip -9 > chrony.tar.gz + + to build a package. When untarred within the root directory, this +will install the files to the intended final locations. + + +File: chrony.info, Node: Typical scenarios, Next: Usage reference, Prev: Installation, Up: Top + +3 Typical operating scenarios +***************************** + +* Menu: + +* Computers on the net:: Your computer is permanently on the Internet (or on + a private network with NTP servers) +* Infrequent connection:: You connect to the Internet sometimes (e.g. via a modem) +* Isolated networks:: You have an isolated network with no reference clocks +* Dial-up home PCs:: Additional considerations if you turn your computer off + when it's not in use. +* Configuration options overview:: Overview of some configuration options. + + +File: chrony.info, Node: Computers on the net, Next: Infrequent connection, Up: Typical scenarios + +3.1 Computers connected to the internet +======================================= + +In this section we discuss how to configure chrony for computers that +have permanent connections to the internet (or to any network +containing true NTP servers which ultimately derive their time from a +reference clock). + + To operate in this mode, you will need to know the names of the NTP +server machines you wish to use. You may be able to find names of +suitable servers by one of the following methods: + + * Your institution may already operate servers on its network. + Contact your system administrator to find out. + + * Your ISP probably has one or more NTP servers available for its + customers. + + * Somewhere under the NTP homepage there is a list of public stratum + 1 and stratum 2 servers. You should find one or more servers that + are near to you -- check that their access policy allows you to + use their facilities. + + Assuming that you have found some servers, you need to set up a +configuration file to run chrony. The (compiled-in) default location +for this file is `/etc/chrony.conf'. In the Debian package the +configuration files are in the directory `/etc/chrony'. Assuming that +your ntp servers are called `a.b.c' and `d.e.f', your `chrony.conf' +file could contain as a minimum + + server a.b.c + server d.e.f + server g.h.i + + However, you will probably want to include some of the other +directives described later. The following directives will be +particularly useful : `driftfile', `commandkey', `keyfile'. The +smallest useful configuration file would look something like + + server a.b.c + server d.e.f + server g.h.i + keyfile /etc/chrony.keys + commandkey 1 + driftfile /etc/chrony.drift + + +File: chrony.info, Node: Infrequent connection, Next: Isolated networks, Prev: Computers on the net, Up: Typical scenarios + +3.2 Infrequent connection to true NTP servers +============================================= + +In this section we discuss how to configure chrony for computers that +have occasional connections to the internet. + +* Menu: + +* Configuration for infrequent connections:: How to set up the `/etc/chrony' file +* Advising chronyd of internet availability:: How to tell chronyd when the link is available + + +File: chrony.info, Node: Configuration for infrequent connections, Next: Advising chronyd of internet availability, Up: Infrequent connection + +3.2.1 Setting up the configuration file for infrequent connections +------------------------------------------------------------------ + +As in the previous section, you will need access to NTP servers on the +internet. The same remarks apply for how to find them. + + In this case, you will need some additional configuration to tell +`chronyd' when the connection to the internet goes up and down. This +saves the program from continuously trying to poll the servers when +they are inaccessible. + + Again, assuming that your ntp servers are called `a.b.c' and +`d.e.f', your `chrony.conf' file would need to contain something like + + server a.b.c + server d.e.f + server g.h.i + + However, the following issues need to be addressed: + + 1. Your computer probably doesn't have DNS access whilst offline to + turn the machine names into IP addresses. + + 2. Your computer will keep trying to contact the servers to obtain + timestamps, even whilst offline. If you operate a dial-on-demand + system, things are even worse, because the link to the internet + will keep getting established. + + For this reason, it would be better to specify this part of your +configuration file in the following way: + + server 1.2.3.4 offline + server 5.6.7.8 offline + server 9.10.11.12 offline + + Because numeric IP addresses have been used, the first problem is +overcome. The `offline' keyword indicates that the servers start in an +offline state, and that they should not be contacted until `chronyd' +receives notification that the link to the internet is present. + + An alternative is to use the names of the NTP servers, and put +entries for them into your `/etc/hosts' file. This will be OK as long +as `files' comes before `dns' in the `hosts' line of the +`/etc/nsswitch.conf' file. + + In order to notify `chronyd' of the presence of the link, you will +need to be able to log in to it with the program chronyc. To do this, +`chronyd' needs to be configured with an administrator password. The +Debian package puts a randomly generated key in +`/etc/chrony/chrony.keys'. You should change it. To set up an +administrator password, you can create a file `/etc/chrony.keys' +containing a single line + + 1 xyzzy + + and add the following line to `/etc/chrony.conf' (the order of the +lines does not matter) + + commandkey 1 + + The smallest useful configuration file would look something like + + server 1.2.3.4 offline + server 5.6.7.8 offline + server 9.10.11.12 offline + keyfile /etc/chrony.keys + commandkey 1 + driftfile /etc/chrony.drift + + The next section describes how to tell `chronyd' when the internet +link goes up and down. + + +File: chrony.info, Node: Advising chronyd of internet availability, Prev: Configuration for infrequent connections, Up: Infrequent connection + +3.2.2 How to tell chronyd when the internet link is available. +-------------------------------------------------------------- + +To use this option, you will need to configure a command key in +`chronyd's' configuration file `/etc/chrony.conf', as described in the +previous section. + + To tell `chronyd' when to start and finish sampling the servers, the +`online' and `offline' commands of chronyc need to be used. To give an +example of their use, we assume that `pppd' is the program being used +to connect to the internet, and that chronyc has been installed at its +default location `/usr/local/bin/chronyc'. We also assume that the +command key has been set up as described in the previous section. + + In the file `/etc/ppp/ip-up' we add the command sequence + + /usr/local/bin/chronyc <| |-------| | | | + | clock | drift rate +-------+ +-----+ +---+ + +---------+ ^ | + | | | + +---------------------------+ --o-----o--- + set time at boot up | + +----------+ + |NTP server| + +----------+ + + When the computer is connected to the Internet (via the modem), +`chronyd' has access to external NTP servers which it makes +measurements from. These measurements are saved, and straight-line fits +are performed on them to provide an estimate of the computer's time +error and rate of gaining/losing time. + + When the computer is taken offline from the Internet, the best +estimate of the gain/loss rate is used to free-run the computer until +it next goes online. + + Whilst the computer is running, `chronyd' makes measurements of the +real-time clock (RTC) (via the `/dev/rtc' interface, which must be +compiled into the kernel). An estimate is made of the RTC error at a +particular RTC second, and the rate at which the RTC gains or loses time +relative to true time. + + The RTC is fully supported in 2.2, 2.4 and 2.6 kernels. + + On 2.6 kernels, if your motherboard has a HPET, you need to enable +the `HPET_EMULATE_RTC' option in your kernel configuration. Otherwise, +chrony will not be able to interact with the RTC device and will give +up using it. + + For kernels in the 2.0 series prior to 2.0.32, the kernel was set up +to trim the RTC every 11 minutes. This would be disasterous for +`chronyd' - there is no reliable way of synchronising with this +trimming. For this reason, `chronyd' only supports the RTC in 2.0 +kernels from v2.0.32 onwards. + + When the computer is powered down, the measurement histories for all +the NTP servers are saved to files (if the `dumponexit' directive is +specified in the configuration file), and the RTC tracking information +is also saved to a file (if the `rtcfile' directive has been +specified). These pieces of information are also saved if the `dump' +and `writertc' commands respectively are issued through `chronyc'. + + When the computer is rebooted, `chronyd' reads the current RTC time +and the RTC information saved at the last shutdown. This information is +used to set the system clock to the best estimate of what its time would +have been now, had it been left running continuously. The measurement +histories for the servers are then reloaded. + + The next time the computer goes online, the previous sessions' +measurements can contribute to the line-fitting process, which gives a +much better estimate of the computer's gain/loss rate. + + One problem with saving the measurements and RTC data when the +machine is shut down is what happens if there is a power failure; the +most recent data will not be saved. Although `chronyd' is robust enough +to cope with this, some performance may be lost. (The main danger +arises if the RTC has been changed during the session, with the +`trimrtc' command in `chronyc'. Because of this, `trimrtc' will make +sure that a meaningful RTC file is saved out after the change is +completed). + + The easiest protection against power failure is to put the `dump' +and `writertc' commands in the same place as the `offline' command is +issued to take `chronyd' offline; because `chronyd' free-runs between +online sessions, no parameters will change significantly between going +offline from the Internet and any power failure. + + A final point regards home computers which are left running for +extended periods and where it is desired to spin down the hard disc +when it is not in use (e.g. when not accessed for 15 minutes). +`chronyd' has been planned so it supports such operation; this is the +reason why the RTC tracking parameters are not saved to disc after +every update, but only when the user requests such a write, or during +the shutdown sequence. The only other facility that will generate +periodic writes to the disc is the `log rtc' facility in the +configuration file; this option should not be used if you want your +disc to spin down. + + +File: chrony.info, Node: Dial-up configuration, Prev: Dial-up overview, Up: Dial-up home PCs + +3.4.2 Typical configuration files. +---------------------------------- + +To illustrate how a dial-up home computer might be configured, example +configuration files are shown in this section. + + For the `/etc/chrony.conf' file, the following can be used as an +example. _NOTE : The `server' directives are only applicable to +customers of Demon Internet; users of other ISPs will need to use their +own ISP's NTP servers or public NTP servers._ + + server 158.152.1.65 minpoll 5 maxpoll 10 maxdelay 0.4 offline + server 158.152.1.76 minpoll 5 maxpoll 10 maxdelay 0.4 offline + server 194.159.253.2 minpoll 5 maxpoll 10 maxdelay 0.4 offline + logdir /var/log/chrony + log statistics measurements tracking + driftfile /etc/chrony.drift + keyfile /etc/chrony.keys + commandkey 25 + maxupdateskew 100.0 + dumponexit + dumpdir /var/log/chrony + rtcfile /etc/chrony.rtc + + With Freeserve as the ISP, I use the following server lines : + + server 194.152.64.68 minpoll 5 maxpoll 10 maxdelay 0.4 offline + server 194.152.64.35 minpoll 5 maxpoll 10 maxdelay 0.4 offline + server 194.152.64.34 minpoll 5 maxpoll 10 maxdelay 0.4 offline + + I use `pppd' for connecting to my ISP. This runs two scripts +`/etc/ppp/ip-up' and `/etc/ppp/ip-down' when the link goes online and +offline respectively. + + The relevant part of the `/etc/ppp/ip-up' file is (with a dummy +password) + + /usr/local/bin/chronyc <' + This option can be used to specify an alternate location for the + configuration file (default `/etc/chrony.conf'). + +`-r' + This option will reload sample histories for each of the servers + being used. These histories are created by using the `dump' + command in `chronyc', or by setting the `dumponexit' directive in + the configuration file. This option is useful if you want to stop + and restart `chronyd' briefly for any reason, e.g. to install a new + version. However, it only makes sense on systems where the kernel + can maintain clock compensation whilst not under `chronyd's' + control. The only version where this happens so far is Linux. On + systems where this is not the case, e.g. Solaris and SunOS the + option should not be used. + +`-s' + This option will set the system clock from the computer's real-time + clock. This is analogous to supplying the `-s' flag to the + `/sbin/clock' program during the Linux boot sequence. + + Support for real-time clocks is limited at present - the criteria + are described in the section on the `rtcfile' directive (*note + rtcfile directive::). + + If `chronyd' cannot support the real time clock on your computer, + this option cannot be used and a warning message will be logged to + the syslog. + + If used in conjunction with the `-r' flag, `chronyd' will attempt + to preserve the old samples after setting the system clock from + the real time clock. This can be used to allow `chronyd' to + perform long term averaging of the gain or loss rate across system + reboots, and is useful for dial-up systems that are shut down when + not in use. For this to work well, it relies on `chronyd' having + been able to determine accurate statistics for the difference + between the real time clock and system clock last time the + computer was on. + +`-v' + This option displays `chronyd's' version number to the terminal and + exits. + + On systems that support an `/etc/rc.local' file for starting +programs at boot time, `chronyd' can be started from there. + + On systems with a System V style initialisation (e.g. Solaris), a +suitable start/stop script might be as shown below. This might be +placed in the file `/etc/rc2.d/S83chrony'. + + #!/bin/sh + # This file should have uid root, gid sys and chmod 744 + # + + killproc() { # kill the named process(es) + pid=`/usr/bin/ps -e | + /usr/bin/grep -w $1 | + /usr/bin/sed -e 's/^ *//' -e 's/ .*//'` + [ "$pid" != "" ] && kill $pid + } + + case "$1" in + + 'start') + if [ -f /opt/free/sbin/chronyd -a -f /etc/chrony.conf ]; then + /opt/free/sbin/chronyd + fi + ;; + 'stop') + killproc chronyd + ;; + *) + echo "Usage: /etc/rc2.d/S83chrony { start | stop }" + ;; + esac + + (In both cases, you may want to bear in mind that `chronyd' can step +the time when it starts. There may be other programs started at boot +time that could be upset by this, so you may need to consider the +ordering carefully. However, `chronyd' will need to start after +daemons providing services that it may require, e.g. the domain name +service.) + + +File: chrony.info, Node: Configuration file, Next: Running chronyc, Prev: Starting chronyd, Up: Usage reference + +4.2 The chronyd configuration file +================================== + +The configuration file is normally called `/etc/chrony.conf'; in fact, +this is the compiled-in default. However, other locations can be +specified with a command line option. + + Each command in the configuration file is placed on a separate line. +The following sections describe each of the commands in turn. The +directives can occur in any order in the file. + +* Menu: + +* comments in config file:: How to write a comment +* acquisitionport directive:: Set port to use for initial time probes +* allow directive:: Give access to NTP clients +* bindaddress directive:: Limit the network interface that is used for NTP +* bindcmdaddress directive:: Limit the network interface that is used for commands +* broadcast directive:: Make chronyd act as an NTP broadcast server +* cmdallow directive:: Give control access to chronyc on other computers +* cmddeny directive:: Deny control access to chronyc on other computers +* commandkey directive:: Set runtime command key +* cmdport directive:: Set port to use for runtime commanding +* deny directive:: Deny access to NTP clients +* driftfile directive:: Specify location of file containing drift data +* dumpdir directive:: Specify directory for dumping measurements +* dumponexit directive:: Dump measurements when daemon exits +* initstepslew directive:: Trim the system clock on boot-up. +* keyfile directive:: Specify location of file containing keys +* linux_hz directive:: Define a non-standard value of the kernel HZ constant +* linux_freq_scale directive:: Define a non-standard value to compensate the kernel frequency bias +* local directive:: Allow unsynchronised machine to act as server +* log directive:: Make daemon log certain sets of information +* logchange directive:: Generate syslog messages if large offsets occur +* logdir directive:: Specify directory for logging +* mailonchange directive:: Send email if a clock correction above a threshold occurs +* manual directive:: Allow manual entry using chronyc's settime cmd. +* maxupdateskew directive:: Stop bad estimates upsetting machine clock +* noclientlog directive:: Prevent chronyd from gathering data about clients +* peer directive:: Specify an NTP peer +* pidfile directive:: Specify the file where chronyd's pid is written +* port directive:: Set port to use for NTP packets +* rtcdevice directive:: Specify name of enhanced RTC device (if not /dev/rtc) +* rtcfile directive:: Specify the file where real-time clock data is stored +* rtconutc directive:: Specify that the real time clock keeps UTC not local time +* server directive:: Specify an NTP server + + +File: chrony.info, Node: comments in config file, Next: acquisitionport directive, Up: Configuration file + +4.2.1 Comments in the configuration file +---------------------------------------- + +The configuration file may contain comment lines. A comment line is +any line that starts with zero or more spaces followed by any one of +the following characters: + * ! + + * ; + + * # + + * % + Any line with this format will be ignored. + + +File: chrony.info, Node: acquisitionport directive, Next: allow directive, Prev: comments in config file, Up: Configuration file + +4.2.2 acquisitionport +--------------------- + +`chronyd' uses a separate client-side port for the rapid-fire +measurements requested with the `initstepslew' directive (*note +initstepslew directive::). Normally, that port is chosen arbitrarily +by the operating system. However, you can use `acquisitionport' to +explicitly specify a port. This may be useful for getting through +firewalls. + + Do not make acquisition and regular NTP service (*note port +directive::) use the same port. + + An example of the `acquisitionport' command is + + acquisitionport 1123 + + This would change the port used for rapid queries to udp/1123. You +could then persuade the firewall administrator to let that port through. + + +File: chrony.info, Node: allow directive, Next: bindaddress directive, Prev: acquisitionport directive, Up: Configuration file + +4.2.3 allow +----------- + +The `allow' command is used to designate a particular subnet from which +NTP clients are allowed to access the computer as an NTP server. + + The default is that no clients are allowed access, i.e. `chronyd' +operates purely as an NTP client. If the `allow' directive is used, +`chronyd' will be both a client of its servers, and a server to other +clients. + + Examples of use of the command are as follows: + + allow foo.bar.com + allow 1.2 + allow 3.4.5 + allow 6.7.8/22 + allow 6.7.8.9/22 + allow + + The first command allows the named node to be an NTP client of this +computer. The second command allows any node with an IP address of the +form 1.2.x.y (with x and y arbitrary) to be an NTP client of this +computer. Likewise, the third command allows any node with an IP +address of the form 3.4.5.x to have client NTP access. The fourth and +fifth forms allow access from any node with an IP address of the form +6.7.8.x, 6.7.9.x, 6.7.10.x or 6.7.11.x (with x arbitrary), i.e. the +value 22 is the number of bits defining the specified subnet. (In the +fifth form, the final byte is ignored). The sixth form allows access +by any node on the entire Internet. + + A second form of the directive, `allow all', has a greater effect, +depending on the ordering of directives in the configuration file. To +illustrate the effect, consider the two examples + + allow 1.2.3.4 + deny 1.2.3 + allow 1.2 + + and + + allow 1.2.3.4 + deny 1.2.3 + allow all 1.2 + + In the first example, the effect is the same regardles of what order +the three directives are given in. So the 1.2.x.y subnet is allowed +access, except for the 1.2.3.x subnet, which is denied access, however +the host 1.2.3.4 is allowed access. + + In the second example, the `allow all 1.2' directives overrides the +effect of _any_ previous directive relating to a subnet within the +specified subnet. Within a configuration file this capability is +probably rather moot; however, it is of greater use for reconfiguration +at run-time via `chronyc' (*note allow all command::). + + Note, if the `initstepslew' directive (*note initstepslew +directive::) is used in the configuration file, each of the computers +listed in that directive must allow client access by this computer for +it to work. + + +File: chrony.info, Node: bindaddress directive, Next: bindcmdaddress directive, Prev: allow directive, Up: Configuration file + +4.2.4 bindaddress +----------------- + +The bindaddress allows you to restrict the network interface to which +chronyd will listen for NTP packets. This provides an additional level +of access restriction above that available through the 'deny' mechanism. + + Suppose you have a local ethernet with addresses in the 192.168.1.0 +subnet together with a dial-up connection. The ethernet interface's IP +address is 192.168.1.1. Suppose (for some reason) you want to block all +access through the dialup connection (note, this will even block replies +from servers on the dialup side, so you will not be able to synchronise +to an external source). You could add the line + + bindaddress 192.168.1.1 + + to the configuration file. + + This directive affects NTP (UDP port 123) packets. If no +`bindcmdaddress' directive is present, the address supplied by +`bindaddress' will be used to control binding of the command socket +(UDP port 323) as well. + + The `bindaddress' directive has been found to cause problems when +used on computers that need to pass NTP traffic over multiple network +interfaces (e.g. firewalls). It is, therefore, not particularly +useful. Use of the `allow' and `deny' directives together with a +network firewall is more likely to be successful. + + +File: chrony.info, Node: bindcmdaddress directive, Next: broadcast directive, Prev: bindaddress directive, Up: Configuration file + +4.2.5 bindcmdaddress +-------------------- + +The bindcmdaddress allows you to restrict the network interface to which +chronyd will listen for command packets (issued by chronyc). + + Suppose you have a local ethernet with addresses in the 192.168.1.0 +subnet together with a dial-up connection. The ethernet interface's IP +address is 192.168.1.1. Suppose you want to block all access through +the dialup connection. You could add the line + + bindcmdaddress 192.168.1.1 + + to the configuration file. + + The `bindcmdaddress' directive has been found to cause problems when +used on computers that need to pass command traffic over multiple +network interfaces. It is, therefore, not particularly useful. Use of +the `cmdallow' and `cmddeny' directives together with a network firewall +is more likely to be successful. + + +File: chrony.info, Node: broadcast directive, Next: cmdallow directive, Prev: bindcmdaddress directive, Up: Configuration file + +4.2.6 broadcast +--------------- + +The `broadcast' directive is used to declare a broadcast address to +which chronyd should send packets in NTP broadcast mode (i.e. make +chronyd act as a broadcast server). Broadcast clients on that subnet +will be able to synchronise. + + The syntax is as follows + + broadcast 30 192.168.1.255 + broadcast 60 192.168.2.255 12123 + + In the first example, the destination port defaults to 123/udp (the +normal NTP port). In the second example, the destionation port is +specified as 12123. The first parameter in each case (30 or 60 +respectively) is the interval in seconds between broadcast packets +being sent. The second parameter in each case is the broadcast address +to send the packet to. This should correspond to the broadcast address +of one of the network interfaces on the computer where chronyd is +running. + + You can have more than 1 `broadcast' directive if you have more than +1 network interface onto which you wish to send NTP broadcast packets. + + Chronyd itself cannot currently act as a broadcast client; it must +always be configured as a point-to-point client by defining specific +NTP servers and peers. This broadcast server feature is intended for +providing a time source to other NTP software (e.g. various MS Windows +clients). + + If xntpd is used as the broadcast client, it will try to use a +point-to-point client/server NTP access to measure the round-trip +delay. Thus, the broadcast subnet should also be the subject of an +`allow' directive (*note allow directive::). + + +File: chrony.info, Node: cmdallow directive, Next: cmddeny directive, Prev: broadcast directive, Up: Configuration file + +4.2.7 cmdallow +-------------- + +This is similar to the `allow' directive (*note allow directive::), +except that it allows control access (rather than NTP client access) to +a particular subnet or host. (By 'control access' is meant that +chronyc can be run on those hosts and successfully connect to chronyd +on this computer.) + + The syntax is identical to the `allow' directive. + + There is also a `cmdallow all' directive with similar behaviour to +the `allow all' directive (but applying to control access in this case, +of course). + + +File: chrony.info, Node: cmddeny directive, Next: commandkey directive, Prev: cmdallow directive, Up: Configuration file + +4.2.8 cmddeny +------------- + +This is similar to the `cmdallow' directive (*note cmdallow +directive::), except that it denies control access to a particular +subnet or host, rather than allowing it. + + The syntax is identical. + + There is also a `cmddeny all' directive with similar behaviour to the +`cmdallow all' directive. + + +File: chrony.info, Node: commandkey directive, Next: cmdport directive, Prev: cmddeny directive, Up: Configuration file + +4.2.9 commandkey +---------------- + +The commandkey command is used to set the key number used for +authenticating user commands via the chronyc program at run time. This +allows certain actions of the chronyc program to be restricted to +administrators. + + An example of the commandkey command is + + commandkey 20 + + In the key file (see the keyfile command) there should be a line of +the form + + 20 foobar + + When running the chronyc program to perform run-time configuration, +the command + + password foobar + + must be entered before any commands affecting the operation of the +daemon can be entered. + + +File: chrony.info, Node: cmdport directive, Next: deny directive, Prev: commandkey directive, Up: Configuration file + +4.2.10 cmdport +-------------- + +The `cmdport' directive allows the port that is used for run-time +command and monitoring (via the program `chronyc') to be altered from +its default (323/udp). + + An example shows the syntax + + cmdport 257 + + This would make `chronyd' use 257/udp as its command port. +(`chronyc' would need to be run with the `-p 257' switch to +inter-operate correctly). + + +File: chrony.info, Node: deny directive, Next: driftfile directive, Prev: cmdport directive, Up: Configuration file + +4.2.11 deny +----------- + +This is similar to the `allow' directive (*note allow directive::), +except that it denies NTP client access to a particular subnet or host, +rather than allowing it. + + The syntax is identical. + + There is also a `deny all' directive with similar behaviour to the +`allow all' directive. + + +File: chrony.info, Node: driftfile directive, Next: dumpdir directive, Prev: deny directive, Up: Configuration file + +4.2.12 driftfile +---------------- + +One of the main activities of the `chronyd' program is to work out the +rate at which the system clock gains or loses time relative to real +time. + + Whenever `chronyd' computes a new value of the gain/loss rate, it is +desirable to record it somewhere. This allows `chronyd' to begin +compensating the system clock at that rate whenever it is restarted, +even before it has had a chance to obtain an equally good estimate of +the rate during the new run. (This process may take many minutes, at +least). + + The driftfile command allows a file to be specified into which +`chronyd' can store the rate information. Two parameters are recorded +in the file. The first is the rate at which the system clock gains or +loses time, expressed in parts per million, with gains positive. +Therefore, a value of 100.0 indicates that when the system clock has +advanced by a second, it has gained 100 microseconds on reality (so the +true time has only advanced by 999900 microseconds). The second is an +estimate of the error bound around the first value in which the true +rate actually lies. + + An example of the driftfile command is + + driftfile /etc/chrony.drift + + +File: chrony.info, Node: dumpdir directive, Next: dumponexit directive, Prev: driftfile directive, Up: Configuration file + +4.2.13 dumpdir +-------------- + +To compute the rate of gain or loss of time, `chronyd' has to store a +measurement history for each of the time sources it uses. + + Certain systems (so far only Linux) have operating system support for +setting the rate of gain or loss to compensate for known errors. (On +other systems, `chronyd' must simulate such a capability by +periodically slewing the system clock forwards or backwards by a +suitable amount to compensate for the error built up since the previous +slew). + + For such systems, it is possible to save the measurement history +across restarts of `chronyd' (assuming no changes are made to the system +clock behaviour whilst it is not running). If this capability is to be +used (via the dumponexit command in the configuration file, or the dump +command in chronyc), the dumpdir command should be used to define the +directory where the measurement histories are saved. + + An example of the command is + + dumpdir /var/log/chrony + + A source whose IP address is 1.2.3.4 would have its measurement +history saved in the file `/var/log/chrony/1.2.3.4.dat'. + + +File: chrony.info, Node: dumponexit directive, Next: initstepslew directive, Prev: dumpdir directive, Up: Configuration file + +4.2.14 dumponexit +----------------- + +If this command is present, it indicates that `chronyd' should save the +measurement history for each of its time sources recorded whenever the +program exits. (See the dumpdir command above). + + +File: chrony.info, Node: initstepslew directive, Next: keyfile directive, Prev: dumponexit directive, Up: Configuration file + +4.2.15 initstepslew +------------------- + +In normal operation, `chronyd' always slews the time when it needs to +adjust the system clock. For example, to correct a system clock which +is 1 second slow, `chronyd' slightly increases the amount by which the +system clock is advanced on each clock interrupt, until the error is +removed. (Actually, this is done by calling the `adjtime()' or similar +system function which does it for us.) Note that at no time does time +run backwards with this method. + + On most Unix systems it is not desirable to step the system clock, +because many programs rely on time advancing monotonically forwards. + + When the `chronyd' daemon is initially started, it is possible that +the system clock is considerably in error. Attempting to correct such +an error by slewing may not be sensible, since it may take several hours +to correct the error by this means. + + The purpose of the `initstepslew' directive is to allow `chronyd' to +make a rapid measurement of the system clock error at boot time, and to +correct the system clock by stepping before normal operation begins. +Since this would normally be performed only at an appropriate point in +the system boot sequence, no other software should be adversely affected +by the step. + + If the correction required is less than a specified threshold, a +slew is used instead. This makes it easier to restart `chronyd' whilst +the system is in normal operation. + + The `initstepslew' directive takes a threshold and a list of NTP +servers as arguments. A maximum of 8 will be used. Each of the servers +is rapidly polled several times, and a majority voting mechanism used to +find the most likely range of system clock error that is present. A +step (or slew) is applied to the system clock to correct this error. +`chronyd' then enters its normal operating mode (where only slews are +used). + + An example of use of the command is + + initstepslew 30 foo.bar.com baz.quz.com + + where 2 NTP servers are used to make the measurement. The `30' +indicates that if the system's error is found to be 30 seconds or less, +a slew will be used to correct it; if the error is above 30 seconds, a +step will be used. + + The `initstepslew' directive can also be used in an isolated LAN +environment, where the clocks are set manually. The most stable +computer is chosen as the master, and the other computers are slaved to +it. If each of the slaves is configured with the local option (see +below), the master can be set up with an `initstepslew' directive which +references some or all of the slaves. Then, if the master machine has +to be rebooted, the slaves can be relied on to 'flywheel' the time for +the master. + + +File: chrony.info, Node: keyfile directive, Next: linux_hz directive, Prev: initstepslew directive, Up: Configuration file + +4.2.16 keyfile +-------------- + +This command is used to specify the location of the file containing +ID/key pairs for the following 2 uses: + + * Authentication of NTP packets. + + * Authentication of administrator commands entered via chronyc. + + The format of the command is shown in the example below + + keyfile /etc/chrony.keys + + The argument is simply the name of the file containing the ID/key +pairs. The format of the file is shown below + + 10 tulip + 11 hyacinth + 20 crocus + 25 iris + ... + + Each line consists of an ID and a password. The ID can be any +unsigned integer in the range 0 through 2**32-1. The password can be +any string of characters not containing a space. + + For NTP use, the MD5 authentication scheme is always used. This +must be borne in mind if `chronyd' is to inter-operate in authenticated +mode with `xntpd' running on other computers. + + The ID for the chronyc authentication key is specified with the +commandkey command (see earlier). + + +File: chrony.info, Node: local directive, Next: log directive, Prev: linux_freq_scale directive, Up: Configuration file + +4.2.17 local +------------ + +The local keyword is used to allow `chronyd' to appear synchronised to +real time (from the viewpoint of clients polling it), even if it has no +current synchronisation source. + + This option is normally used on computers in an isolated network, +where several computers are required to synchronise to one other, this +being the "master" which is kept vaguely in line with real time by +manual input. + + An example of the command is + + local stratum 10 + + The value 10 may be substituted with other values in the range 1 +through 15. Stratum 1 indicates a computer that has a true real-time +reference directly connected to it (e.g. GPS, atomic clock etc) – +such computers are expected to be very close to real time. Stratum 2 +computers are those which have a stratum 1 server; stratum 3 computers +have a stratum 2 server and so on. + + A large value of 10 indicates that the clock is so many hops away +from a reference clock that its time is fairly unreliable. Put another +way, if the computer ever has access to another computer which is +ultimately synchronised to a reference clock, it will almost certainly +be at a stratum less than 10. Therefore, the choice of a high value +like 10 for the local command prevents the machine's own time from ever +being confused with real time, were it ever to leak out to clients that +have visibility of real servers. + + +File: chrony.info, Node: linux_hz directive, Next: linux_freq_scale directive, Prev: keyfile directive, Up: Configuration file + +4.2.18 linux_hz +--------------- + +(This option only applies to Linux). + + By default, chronyd will find the value of `HZ' from a kernel header +file at compile time. `HZ' is the nominal number of timer interrupts +per second. If you're running chronyd on the system where it was +built, the value it has should be right, and you don't need to worry +about this option. + + This option is provided for people who move a pre-built chronyd onto +a system where the value of HZ in the kernel headers has been changed +from the default value. + + An example of the command is + + linux_hz 100 + + +File: chrony.info, Node: linux_freq_scale directive, Next: local directive, Prev: linux_hz directive, Up: Configuration file + +4.2.19 linux_freq_scale +----------------------- + +(This option only applies to Linux). + + By default, chronyd will find the value of `HZ' and `SHIFT_HZ' from +kernel header files at compile time. An internal value called +`freq_scale' is calculated from this. By default it is +(1< + + Typical values for might be 100 for a dial-up +connection to servers over a phone line, and 5 or 10 for a computer on +a LAN. + + It should be noted that this is not the only means of protection +against using unreliable estimates. At all times, `chronyd' keeps +track of both the estimated gain or loss rate, and the error bound on +the estimate. When a new estimate is generated following another +measurement from one of the sources, a weighted combination algorithm is +used to update the master estimate. So if `chronyd' has an existing +highly-reliable master estimate and a new estimate is generated which +has large error bounds, the existing master estimate will dominate in +the new master estimate. + + +File: chrony.info, Node: noclientlog directive, Next: peer directive, Prev: maxupdateskew directive, Up: Configuration file + +4.2.26 noclientlog +------------------ + +This directive, which takes no arguments, specifies that client accesses +are not to be logged. Normally they are logged, allowing statistics to +be reported using the `clients' command in `chronyc'. + + +File: chrony.info, Node: peer directive, Next: pidfile directive, Prev: noclientlog directive, Up: Configuration file + +4.2.27 peer +----------- + +The syntax of this directive is identical to that for the `server' +directive (*note server directive::), except that it is used to specify +an NTP peer rather than an NTP server. + + +File: chrony.info, Node: pidfile directive, Next: port directive, Prev: peer directive, Up: Configuration file + +4.2.28 pidfile +-------------- + +chronyd always writes its process ID (pid) to a file, and checks this +file on startup to see if another chronyd may already be running on the +system. By default, the file used is `/var/run/chronyd.pid'. The +`pidfile' directive allows the name to be changed, e.g. + + pidfile /var/tmp/chronyd.pid + + +File: chrony.info, Node: port directive, Next: rtcdevice directive, Prev: pidfile directive, Up: Configuration file + +4.2.29 port +----------- + +This option allows you to configure the port used for the NTP service +on your machine. + + The compiled in default is udp/123, the standard NTP port. It is +unlikely that you would ever need to change this value. A possible +exception would be if you wanted to operate strictly in client-only +mode and never be available as a server to xntpd clients. + + An example of the port command is + + port 11123 + + This would change the NTP port served by chronyd on the computer to +udp/11123. + + +File: chrony.info, Node: rtcdevice directive, Next: rtcfile directive, Prev: port directive, Up: Configuration file + +4.2.30 rtcdevice +---------------- + +The `rtcdevice' directive defines the name of the device file for +accessing the real time clock. By default this is `/dev/rtc/', unless +the directive is used to set a different value. This applies to Linux +systems with devfs. An example of use is + + rtcdevice /dev/misc/rtc + + +File: chrony.info, Node: rtcfile directive, Next: rtconutc directive, Prev: rtcdevice directive, Up: Configuration file + +4.2.31 rtcfile +-------------- + +The `rtcfile' directive defines the name of the file in which `chronyd' +can save parameters associated with tracking the accuracy of the +system's real-time clock (RTC). + + The syntax is illustrated in the following example + + rtcfile /etc/chrony.rtc + + `chronyd' saves information in this file when it exits and when the +`writertc' command is issued in `chronyc'. The information saved is +the RTC's error at some epoch, that epoch (in seconds since January 1 +1970), and the rate at which the RTC gains or loses time. + + So far, the support for real-time clocks is limited - their code is +even more system-specific than the rest of the software. You can only +use the real time clock facilities (the `rtcfile' directive and the +`-s' command line option to `chronyd') if the following three +conditions apply: + + 1. You are running Linux version 2.2.x or 2.4.x (for any value of x), + or v2.0.x with x>=32. + + 2. You have compiled the kernel with extended real-time clock support + (i.e. the `/dev/rtc' device is capable of doing useful things). + + 3. You don't have other applications that need to make use of + `/dev/rtc' at all. + + + +File: chrony.info, Node: rtconutc directive, Next: server directive, Prev: rtcfile directive, Up: Configuration file + +4.2.32 rtconutc +--------------- + +`chronyd' assumes by default that the real time clock (RTC) keeps local +time (including any daylight saving changes). This is convenient on +PCs running Linux which are dual-booted with DOS or Windows. + + NOTE : IF YOU KEEP THE REAL TIME CLOCK ON LOCAL TIME AND YOUR +COMPUTER IS OFF WHEN DAYLIGHT SAVING (SUMMER TIME) STARTS OR ENDS, THE +COMPUTER'S SYSTEM TIME WILL BE ONE HOUR IN ERROR WHEN YOU NEXT BOOT AND +START CHRONYD. + + An alternative is for the RTC to keep Universal Coordinated Time +(UTC). This does not suffer from the 1 hour problem when daylight +saving starts or ends. + + If the `rtconutc' directive appears, it means the RTC is required to +keep UTC. The directive takes no arguments. It is equivalent to +specifying the `-u' switch to the Linux `/sbin/clock' program. + + +File: chrony.info, Node: server directive, Prev: rtconutc directive, Up: Configuration file + +4.2.33 server +------------- + +The `server' directive allows NTP servers to be specified. The +client/server relationship is strictly hierarchical : a client may +synchronise its system time to that of the server, but the server's +system time will never be influenced by that of a client. + + The `server' directive is immediately followed by either the name of +the server, or its IP address in dotted-quad notation. The server +command also supports a number of subfields (which may be defined in any +order): + +`port' + This option allows the UDP port on which the server understands NTP + requests to be specified. For normal servers this option should + not be required (the default is 123, the standard NTP port). + +`minpoll' + Although `chronyd' will trim the rate at which it samples the + server during normal operation, the user may wish to constrain the + minimum polling interval. This is always defined as a power of 2, + so will also +terminate the program.) + + +File: chrony.info, Node: Chronyc command line options, Next: Security with chronyc, Prev: Chronyc basic use, Up: Running chronyc + +4.3.2 Command line options +-------------------------- + +Chronyc supports the following command line options. + +`-v' + Displays the version number of chronyc on the terminal, and exists. + +`-h ' + This option allows the user to specify which host running the + `chronyd' program is to be contacted. This allows for remote + configuration, without having to telnet or rlogin to the other host + first. + + The default is to contact `chronyd' running on the same host as + that where chronyc is being run. + +`-p ' + This option allows the user to specify the UDP port number which + the target `chronyd' is using for its command & monitoring + connections. This defaults to the compiled-in default; there + would rarely be a need to change this. + + +File: chrony.info, Node: Security with chronyc, Next: Chronyc command reference, Prev: Chronyc command line options, Up: Running chronyc + +4.3.3 Security with chronyc +--------------------------- + +Many of the commands available through chronyc have a fair amount of +power to reconfigure the run-time behaviour of `chronyd'. Consequently, +`chronyc' is quite dangerous for the integrity of the target system's +clock performance. Having access to `chronyd' via chronyc is more or +less equivalent to being able to modify `chronyd's' configuration file +(typically `/etc/chrony.conf') and to restart `chronyd'. + + Chronyc also provides a number of monitoring (as opposed to +commanding) commands, which will not affect the behaviour of `chronyd'. +However, you may still want to restrict access to these commands. + + In view of this, access to some of the capabilities of chronyc will +usually be tightly controlled. There are two mechanisms supported: + + 1. The set of hosts from which `chronyd' will accept commands can be + restricted. By default, commands will only be accepted from the + same host that `chronyd' is running on. + + 2. Any command that actually reconfigures some aspect of `chronyd's' + behaviour requires the user of chronyc to know a password. This + password is specified in `chronyd's' keys file (*note keyfile + directive::) and specified via the commandkey option in its + configuration file (*note commandkey directive::). + + Only the following commands can be used _without_ providing a +password: + + * `exit' + + * `help' + + * `password' + + * `quit' + + * `rtcdata' + + * `sources' + + * `sourcestats' + + * `tracking' + + All other commands require a password to have been specified +previously, because they affect `chronyd's' operation. + + +File: chrony.info, Node: Chronyc command reference, Prev: Security with chronyc, Up: Running chronyc + +4.3.4 Command reference +----------------------- + +This section describes each of the commands available within the chronyc +program. Chronyc offers the user a simple command-line driven +interface. + +* Menu: + +* accheck command:: Verifying NTP client access +* activity command:: Check how many NTP servers/peers are online/offline +* add peer command:: Add a new NTP peer +* add server command:: Add a new NTP server +* allow command:: Allowing NTP client access +* allow all command:: Allowing NTP client access +* burst command:: Initiating a rapid set of measurements +* clients command:: Show clients that have accessed the server +* cmdaccheck command:: Verifying command client access +* cmdallow command:: Allowing command client access +* cmdallow all command:: Allowing command client access +* cmddeny command:: Denying command client access +* cmddeny all command:: Denying command client access +* cyclelogs command:: Close and re-open open log files +* delete command:: Remove an NTP server or peer +* deny command :: Denying NTP client access +* deny all command:: Denying NTP client access +* dump command:: Dump measurement histories to files +* exit command:: Exit from chronyc +* help command:: Generate help summary +* local command:: Let computer be a server when it is unsynchronised +* makestep command:: Immediately correct the system clock instead of slewing +* manual command:: Enable/disable/configure options for settime +* maxdelay command:: Set max measurement delay for a source +* maxdelayratio command:: Set max measurement delay for a source as ratio +* maxpoll command:: Set maximum polling interval for a source +* maxupdateskew command:: Set safety threshold for clock gain/loss rate +* minpoll command:: Set minimum polling interval for a source +* offline command:: Warn that connectivity to a source will be lost +* online command:: Warn that connectivity to a source has been restored +* password command:: Provide password needed for most commands +* quit command:: Exit from chronyc +* rtcdata command:: Display RTC parameters +* settime command:: Provide a manual input of the current time +* sources command:: Display information about the current set of sources +* sourcestats command:: Display the rate & offset estimation performance of sources +* tracking command:: Display system clock performance +* trimrtc command:: Correct the RTC time to the current system time +* writertc command:: Write the RTC parameters to file. + + +File: chrony.info, Node: accheck command, Next: activity command, Up: Chronyc command reference + +4.3.4.1 accheck +............... + +This command allows you to check whether client NTP access is allowed +from a particular host. + + Examples of use, showing a named host and a numeric IP address, are +as follows: + + accheck a.b.c + accheck 1.2.3.4 + + This command can be used to examine the effect of a series of +`allow', `allow all', `deny' and `deny all' commands specified either +via chronyc, or in `chronyd's' configuration file. + + +File: chrony.info, Node: activity command, Next: add peer command, Prev: accheck command, Up: Chronyc command reference + +4.3.4.2 activity +................ + +This command reports the number of servers/peers that are online and +offline. If the auto_offline option is used in specifying some of the +servers/peers, the `activity' command may be useful for detecting when +all of them have entered the offline state after the PPP link has been +disconnected. + + The report shows the number of servers/peers in 4 states: + * `online' : the server/peer is currently online (i.e. assumed by + chronyd to be reachable) + + * `offline' : the server/peer is currently offline (i.e. assumed by + chronyd to be unreachable, and no measurements from it will be + attempted.) + + * `burst_online' : a burst command has been initiated for the + server/peer and is being performed; after the burst is complete, + the server/peer will be returned to the online state. + + * `burst_offline' : a burst command has been initiated for the + server/peer and is being performed; after the burst is complete, + the server/peer will be returned to the offline state. + + +File: chrony.info, Node: add peer command, Next: add server command, Prev: activity command, Up: Chronyc command reference + +4.3.4.3 add peer +................ + +The `add peer' command allows a new NTP peer to be added whilst +`chronyd' is running. + + Following the words `add peer', the syntax of the following +parameters and options is identical to that for the `peer' directive in +the configuration file (*note peer directive::). + + An example of using this command is shown below. + + add peer foo.bar.com minpoll 6 maxpoll 10 authkey 25 + + +File: chrony.info, Node: add server command, Next: allow command, Prev: add peer command, Up: Chronyc command reference + +4.3.4.4 add server +.................. + +The `add server' command allows a new NTP server to be added whilst +`chronyd' is running. + + Following the words `add server', the syntax of the following +parameters and options is identical to that for the `server' directive +in the configuration file (*note server directive::). + + An example of using this command is shown below. + + add server foo.bar.com minpoll 6 maxpoll 10 authkey 25 + + +File: chrony.info, Node: allow command, Next: allow all command, Prev: add server command, Up: Chronyc command reference + +4.3.4.5 allow +............. + +The effect of the allow command is identical to the `allow' directive in +the configuration file (*note allow directive::). + + The syntax is illustrated in the following examples: + + allow foo.bar.com + allow 1.2 + allow 3.4.5 + allow 6.7.8/22 + allow 6.7.8.9/22 + allow + + The effect of each of these examples is the same as that of the +`allow' directive in the configuration file. + + +File: chrony.info, Node: allow all command, Next: burst command, Prev: allow command, Up: Chronyc command reference + +4.3.4.6 allow all +................. + +The effect of the allow command is identical to the `allow all' +directive in the configuration file (*note allow directive::). + + +File: chrony.info, Node: burst command, Next: clients command, Prev: allow all command, Up: Chronyc command reference + +4.3.4.7 burst +............. + +The `burst' command tells `chronyd' to make a set of measurements to +each of its sources over a short duration (rather than the usual +periodic measurements that it makes). After such a burst, `chronyd' +will revert to the previous state for each source. This might be either +online, if the source was being periodically measured in the normal way, +or offline, if the source had been indicated as being offline. +(Switching a source between the online and offline states is described +in *Note online command::, *Note offline command::). + + The syntax of the burst command is as follows + + burst / [/] + + The mask and masked-address arguments are optional, in which case +`chronyd' will initiate a burst for all of its currently defined +sources. + + The arguments have the following meaning and format. + +`n-good-measurements' + This defines the number of good measurements that `chronyd' will + want to obtain from each source. A measurement is good if it + passes certain tests, for example, the round trip time to the + source must be acceptable. (This allows `chronyd' to reject + measurements that are likely to be bogus.) + +`max-measurements' + This defines the maximum number of measurements that `chronyd' will + attempt to make, even if the required number of good measurements + has not been obtained. + +`mask' + This is a dotted quad argument (e.g. `255.255.255.0') with which + the IP address of each of `chronyd''s sources is to be masked. + +`masked-address' + This is a dotted quad argument (e.g. `1.2.3.0'). If the masked IP + address of a source matches this value then the burst command is + applied to that source. + + If no mask or masked address arguments are provided, the default is +`0.0.0.0' and `0.0.0.0' respectively, which will match every source. + + An example of the two-argument form of the command is + + burst 2/10 + + This will cause `chronyd' to attempt to get two good measurements +from each source, stopping after two have been obtained, but in no +event will it try more than ten probes to the source. + + An example of the four-argument form of the command is + + burst 2/10 255.255.0.0/1.2.0.0 + + In this case, the two out of ten sampling will only be applied to +sources whose IP addresses are of the form `1.2.x.y', where x and y are +arbitrary. + + +File: chrony.info, Node: clients command, Next: cmdaccheck command, Prev: burst command, Up: Chronyc command reference + +4.3.4.8 clients +............... + +This command shows a list of all clients that have accessed the server, +through either the NTP or command/monitoring ports. There are no +arguments. + + An example of the output is + + Hostname Client Peer CmdAuth CmdNorm CmdBad LstN LstC + ========================= ====== ====== ====== ====== ====== ==== ==== + localhost 0 0 15 1 0 29y 0 + aardvark.xxx 4 0 0 0 0 49 29y + badger.xxx 4 0 0 0 0 6 29y + + Each row shows the data for a single host. Only hosts that have +passed the host access checks (set with the `allow', `deny', `cmdallow' +and `cmddeny' commands or configuration file directives) are logged. + + The columns are as follows: + + 1. The hostname of the client + + 2. The number of times the client has accessed the server using an NTP + client mode packet. + + 3. The number of times the client has accessed the server using an NTP + symmetric active mode packet. + + 4. The number of authenticated command packets that have been + processed from the client (i.e. those following a successful + `password' command). + + 5. The number of unauthenticated command packets that have been + processed from the client. + + 6. The number of bad command packets received from the client (not all + forms of bad packet are logged). + + 7. Time since the last NTP packet was received + + 8. Time since the last command packet was received + + The last two entries will be shown as the time since 1970 if no +packet of that type has ever been received. + + +File: chrony.info, Node: cmdaccheck command, Next: cmdallow command, Prev: clients command, Up: Chronyc command reference + +4.3.4.9 cmdaccheck +.................. + +This command is similar to the `accheck' command, except that it is +used to check whether command access is permitted from a named host. + + Examples of use are as follows: + + cmdaccheck a.b.c + cmdaccheck 1.2.3.4 + + +File: chrony.info, Node: cmdallow command, Next: cmdallow all command, Prev: cmdaccheck command, Up: Chronyc command reference + +4.3.4.10 cmdallow +................. + +This is similar to the `allow' command, except that it is used to allow +particular hosts or subnets to use the chronyc program to interact with +`chronyd' on the current host. + + +File: chrony.info, Node: cmdallow all command, Next: cmddeny command, Prev: cmdallow command, Up: Chronyc command reference + +4.3.4.11 cmdallow all +..................... + +This is similar to the `allow all' command, except that it is used +toallow particular hosts or subnets to use the chronyc program to +interactwith `chronyd' on the current host. + + +File: chrony.info, Node: cmddeny command, Next: cmddeny all command, Prev: cmdallow all command, Up: Chronyc command reference + +4.3.4.12 cmddeny +................ + +This is similar to the `deny' command, except that it is used to allow +particular hosts or subnets to use the chronyc program to interact with +`chronyd' on the current host. + + +File: chrony.info, Node: cmddeny all command, Next: cyclelogs command, Prev: cmddeny command, Up: Chronyc command reference + +4.3.4.13 cmddeny all +.................... + +This is similar to the `deny all' command, except that it is used to +allow particular hosts or subnets to use the chronyc program to +interact with `chronyd' on the current host. + + +File: chrony.info, Node: cyclelogs command, Next: delete command, Prev: cmddeny all command, Up: Chronyc command reference + +4.3.4.14 cyclelogs +.................. + +The `cyclelogs' command causes all of `chronyd's' open log files to be +closed and re-opened. This allows them to be renamed so that they can +be periodically purged. An example of how to do this is shown below. + + % mv /var/log/chrony/measurements.log /var/log/chrony/measurements1.log + % chronyc + chronyc> password aardvark + 200 OK + chronyc> cyclelogs + 200 OK + chronyc> exit + % ls -l /var/log/chrony + -rw-r--r-- 1 root root 0 Jun 8 18:17 measurements.log + -rw-r--r-- 1 root root 12345 Jun 8 18:17 measurements1.log + % rm -f measurements1.log + + +File: chrony.info, Node: delete command, Next: deny command, Prev: cyclelogs command, Up: Chronyc command reference + +4.3.4.15 delete +............... + +The `delete' command allows an NTP server or peer to be removed from +the current set of sources. + + The syntax is illustrated in the examples below. + + delete foo.bar.com + delete 1.2.3.4 + + There is one parameter, the name or IP address of the server or peer +to be deleted. + + +File: chrony.info, Node: deny command, Next: deny all command, Prev: delete command, Up: Chronyc command reference + +4.3.4.16 deny +............. + +The effect of the allow command is identical to the `deny' directive in +the configuration file (*note deny directive::). + + The syntax is illustrated in the following examples: + + deny foo.bar.com + deny 1.2 + deny 3.4.5 + deny 6.7.8/22 + deny 6.7.8.9/22 + deny + + +File: chrony.info, Node: deny all command, Next: dump command, Prev: deny command, Up: Chronyc command reference + +4.3.4.17 deny all +................. + +The effect of the allow command is identical to the `deny all' +directive in the configuration file (*note deny directive::). + + +File: chrony.info, Node: dump command, Next: exit command, Prev: deny all command, Up: Chronyc command reference + +4.3.4.18 dump +............. + +The `dump' command causes `chronyd' to write its current history of +measurements for each of its sources to dump files, either for +inspection or to support the `-r' option when `chronyd' is restarted. + + The `dump' command is somewhat equivalent to the `dumponexit' +directive in the chrony configuration file. *Note dumponexit +directive::. + + To use the `dump', you probably want to configure the name of the +directory into which the dump files will be written. This can only be +done in the configuration file, see *Note dumpdir directive::. + + +File: chrony.info, Node: exit command, Next: help command, Prev: dump command, Up: Chronyc command reference + +4.3.4.19 exit +............. + +The exit command exits from chronyc and returns the user to the shell +(same as the quit command). + + +File: chrony.info, Node: help command, Next: local command, Prev: exit command, Up: Chronyc command reference + +4.3.4.20 help +............. + +The help command displays a summary of the commands and their arguments. + + +File: chrony.info, Node: local command, Next: makestep command, Prev: help command, Up: Chronyc command reference + +4.3.4.21 local +.............. + +The `local' command allows `chronyd' to be told that it is to appear as +a reference source, even if it is not itself properly synchronised to +an external source. (This can be used on isolated networks, to allow +one computer to be a master time server with the other computers slaving +to it.) The `local' command is somewhat equivalent to the `local' +directive in the configuration file, see *Note local directive::. + + The syntax is as shown in the following examples. + + local stratum 10 + local off + + The first example enables the local reference mode on the host, and +sets the stratum at which it should claim to be synchronised. + + The second example disables the local reference mode. + + +File: chrony.info, Node: makestep command, Next: manual command, Prev: local command, Up: Chronyc command reference + +4.3.4.22 makestep +................. + +Normally chronyd will cause the system to gradually correct any time +offset, by slowing down or speeding up the clock as required. In +certain situations, the system clock may be so far adrift that this +slewing process would take a very long time to correct the system clock. + + The `makestep' command can be used in this situation. It cancels +any remaining correction that was being slewed, and jumps the system +clock by the equivalent amount, making it correct immediately. + + BE WARNED - certain software will be seriously affected by such +jumps to the system time. (That is the reason why chronyd uses slewing +normally.) + + The `makestep' command is currently only available on the Linux +version of chrony. + + +File: chrony.info, Node: manual command, Next: maxdelay command, Prev: makestep command, Up: Chronyc command reference + +4.3.4.23 manual +............... + +The manual command enables and disables use of the `settime' command +(*note settime command::), and is used to modify the behaviour of the +manual clock driver. + + Examples of the command are shown below. + + manual on + manual off + manual delete 1 + manual list + manual reset + + The `on' form of the command enables use of the `settime' command. + + The `off' form of the command disables use of the `settime' command. + + The `list' form of the command lists all the samples currently +stored in `chronyd'. The output is illustrated below. + + 210 n_samples = 1 + # Date Time(UTC) Slewed Original Residual + ==================================================== + 0 27Jan99 22:09:20 0.00 0.97 0.00 + + The columns as as follows : + + 1. The sample index (used for the `manual delete' command) + + 2. The date and time of the sample + + 3. The system clock error when the timestamp was entered, adjusted to + allow for changes made to the system clock since. + + 4. The system clock error when the timestamp was entered, as it + originally was (without allowing for changes to the system clock + since). + + 5. The regression residual at this point, in seconds. This allows + 'outliers' to be easily spotted, so that they can be deleted using + the `manual delete' command. + + The `delete' form of the command deletes a single sample. The +parameter is the index of the sample, as shown in the first column of +the output from `manual list'. Following deletion of the data point, +the current error and drift rate are re-estimated from the remaining +data points and the system clock trimmed if necessary. This option is +intended to allow 'outliers' to be discarded, i.e. samples where the +administrator realises he/she has entered a very poor timestamp. + + The `reset' form of the command deletes all samples at once. The +system clock is left running as it was before the command was entered. + + +File: chrony.info, Node: maxdelay command, Next: maxdelayratio command, Prev: manual command, Up: Chronyc command reference + +4.3.4.24 maxdelay +................. + +This allows the `maxdelay' option for one of the sources to be +modified, in the same way as specifying the `maxdelay' option for the +`server' directive in the configuration file (*note server directive::). + + The following examples illustrate the syntax + + maxdelay foo.bar.com 0.3 + maxdelay 1.2.3.4 0.0015 + + The first example sets the maximum network delay allowed for a +measurement to the host `foo.bar.com' to 0.3 seconds. The second +example sets the maximum network delay for a measurement to the host +with IP address `1.2.3.4' to 1.5 milliseconds. + + (Any measurement whose network delay exceeds the specified value is +discarded.) + + +File: chrony.info, Node: maxdelayratio command, Next: maxpoll command, Prev: maxdelay command, Up: Chronyc command reference + +4.3.4.25 maxdelayratio +...................... + +This allows the `maxdelayratio' option for one of the sources to be +modified, in the same way as specifying the `maxdelayratio' option for +the `server' directive in the configuration file (*note server +directive::). + + The following examples illustrate the syntax + + maxdelayratio foo.bar.com 1.5 + maxdelayratio 1.2.3.4 2.0 + + The first example sets the maximum network delay for a measurement to +the host `foo.bar.com' to be 1.5 times the minimum delay found amongst +the previous measurements that have been retained. The second example +sets the maximum network delay for a measurement to the host with IP +address `1.2.3.4' to be double the retained minimum. + + As for `maxdelay', any measurement whose network delay is too large +will be discarded. + + +File: chrony.info, Node: maxpoll command, Next: maxupdateskew command, Prev: maxdelayratio command, Up: Chronyc command reference + +4.3.4.26 maxpoll +................ + +The `maxpoll' command is used to modify the minimum polling interval +for one of the current set of sources. It is equivalent to the +`maxpoll' option in the `server' directive in the configuration file +(*note server directive::). + + The syntax is as follows + + maxpoll + + where the host can be specified as either a machine name or +dotted-quad IP address. The new minimum poll is specified as a base-2 +logarithm of the number of seconds between polls (e.g. specify 6 for 64 +second sampling). + + An example is + + maxpoll foo.bar.com 10 + + which sets the maximum polling interval for the host `foo.bar.com' +to 1024 seconds. + + Note that the new maximum polling interval only takes effect after +the next measurement has been made. + + +File: chrony.info, Node: maxupdateskew command, Next: minpoll command, Prev: maxpoll command, Up: Chronyc command reference + +4.3.4.27 maxupdateskew +...................... + +This command has the same effect as the `maxupdateskew' directive in +the configuration file, see *Note maxupdateskew directive::. + + +File: chrony.info, Node: minpoll command, Next: offline command, Prev: maxupdateskew command, Up: Chronyc command reference + +4.3.4.28 minpoll +................ + +The `minpoll' command is used to modify the minimum polling interval +for one of the current set of sources. It is equivalent to the +`minpoll' option in the `server' directive in the configuration file +(*note server directive::). + + The syntax is as follows + + minpoll + + where the host can be specified as either a machine name or +dotted-quad IP address. The new minimum poll is specified as a base-2 +logarithm of the number of seconds between polls (e.g. specify 6 for 64 +second sampling). + + An example is + + minpoll foo.bar.com 5 + + which sets the minimum polling interval for the host `foo.bar.com' +to 32 seconds. + + Note that the new minimum polling interval only takes effect after +the next measurement has been made. + + +File: chrony.info, Node: offline command, Next: online command, Prev: minpoll command, Up: Chronyc command reference + +4.3.4.29 offline +................ + +The `offline' command is used to warn `chronyd' that the network +connection to a particular host or hosts is about to be lost. It should +be used on computers with a dial-up or similar connection to their time +sources, to warn `chronyd' that the connection is about to be broken. + + An example of how to use `offline' in this case is shown in *Note +Advising chronyd of internet availability::. + + Another case where `offline' could be used is where a computer +serves time to a local group of computers, and has a permanant +connection to true time servers outside the organisation. However, the +external connection is heavily loaded at certain times of the day and +the measurements obtained are less reliable at those times. In this +case, it is probably most useful to determine the gain/loss rate during +the quiet periods and let the whole network coast through the loaded +periods. The `offline' and `online' commands can be used to achieve +this. The situation is shown in the figure below. + + +----------+ + |Ext source| + +----------+ + | + | + |/| <-- Link with variable + | reliability + | + +-------------------+ + |Local master server| + +-------------------+ + | + +---+---+-----+-----+----+----+ + | | | | | | | + Local clients + + If the source to which `chronyd' is currently synchronised is +indicated offline in this way, `chronyd' will continue to treat it as +the synchronisation source. If the network connection were broken +without the `offline' command being used, `chronyd' would assume that +the source had failed and would attempt to pick another synchronisation +source. + + There are two forms of the `offline' command. The first form is a +wildcard, meaning all sources. The second form allows a IP address mask +and a masked address to be specified. These forms are illustrated +below. + + offline + offline 255.255.255.0/1.2.3.0 + + The second form means that the `offline' command is to be applied to +any source whose IP address is in the 1.2.3 subnet. (The host's +address is logically and-ed with the mask, and if the result matches the +masked-address the host is processed). + + The wildcard form of the address is actually equivalent to + + offline 0.0.0.0/0.0.0.0 + + +File: chrony.info, Node: online command, Next: password command, Prev: offline command, Up: Chronyc command reference + +4.3.4.30 online +............... + +The `online' command is opposite in function to the `offline' command. +It is used to advise `chronyd' that network connectivity to a +particular source or sources has been restored. + + The syntax is identical to that of the `offline' command, see *Note +offline command::. + + +File: chrony.info, Node: password command, Next: quit command, Prev: online command, Up: Chronyc command reference + +4.3.4.31 password +................. + +The password command is used to allow chronyc to send privileged +commands to `chronyd'. The password can either be entered on the +command line, or can be entered without echoing. The syntax for +entering the password on the command line is as follows + + password xyzzy + + To enter the password without it being echoed, enter + + password + + The computer will respond with a `Password:' prompt, at which you +should enter the password and press return. (Note that the no-echo mode +is limited to 8 characters on SunOS 4.1 due to limitations in the system +library. Other systems do not have this restriction.) + + The password is any string of characters not containing whitespace. +It has to match `chronyd's' currently defined command key (*note +commandkey directive::). + + +File: chrony.info, Node: quit command, Next: rtcdata command, Prev: password command, Up: Chronyc command reference + +4.3.4.32 quit +............. + +The quit command exits from chronyc and returns the user to the shell +(same as the exit command). + + +File: chrony.info, Node: rtcdata command, Next: settime command, Prev: quit command, Up: Chronyc command reference + +4.3.4.33 rtcdata +................ + +The `rtcdata' command displays the current real time clock RTC +parameters. + + An example output is shown below. + + RTC ref time (GMT) : Sat May 30 07:25:56 1998 + Number of samples : 10 + Number of runs : 5 + Sample span period : 549 + RTC is fast by : -1.632736 seconds + RTC gains time at : -107.623 ppm + + The fields have the following meaning + +`RTC ref time (GMT)' + This is the RTC reading the last time its error was measured. + +`Number of samples' + This is the number of previous measurements being used to + determine the RTC gain/loss rate. + +`Number of runs' + This is the number of runs of residuals of the same sign following + the regression fit for (RTC error) versus (RTC time). A value + which is small indicates that the measurements are not well + approximated by a linear model, and that the algorithm will tend + to delete the older measurements to improve the fit. + +`Sample span period' + This is the period that the measurements span (from the oldest to + the newest). Without a unit the value is in seconds; suffixes `m' + for minutes, `h' for hours, `d' for days or `y' for years may be + used. + +`RTC is fast by' + This is the estimate of how many seconds fast the RTC when it + thought the time was at the reference time (above). If this value + is large, you may (or may not) want to use the `trimrtc' command + to bring the RTC into line with the system clock. (Note, a large + error will not affect `chronyd's' operation, unless it becomes so + big as to start causing rounding errors. + +`RTC gains time at' + This is the amount of time gained (positive) or lost (negative) by + the real time clock for each second that it ticks. It is measured + in parts per million. So if the value shown was +1, suppose the + RTC was exactly right when it crosses a particular second + boundary. Then it would be 1 microsecond fast when it crosses its + next second boundary. + + +File: chrony.info, Node: settime command, Next: sources command, Prev: rtcdata command, Up: Chronyc command reference + +4.3.4.34 settime +................ + +The `settime' command allows the current time to be entered manually, +if this option has been configured into `chronyd'. (It may be +configured either with the `manual' directive in the configuration file +(*note manual directive::), or with the `manual' command of chronyc +(*note manual command::). + + It should be noted that the computer's sense of time will only be as +accurate as the reference you use for providing this input (e.g. your +watch), as well as how well you can time the press of the return key. +When inputting time to an isolated network, I have a battery operated +alarm clock that is synchronised to the Rugby MSF time signal in the UK. + + Providing your computer's time zone is set up properly, you will be +able to enter a local time (rather than UTC). + + The response to a successful `settime' command indicates the amount +that the computer's clock was wrong. It should be apparent from this if +you have entered the time wrongly, e.g. with the wrong time zone. + + The rate of drift of the system clock is estimated by a regression +process using the entered measurement and all previous measurements +entered during the present run of `chronyd'. However, the entered +measurement is used for adjusting the current clock offset (rather than +the estimated intercept from the regression, which is ignored). +Contrast what happens with the `manual delete' command, where the +intercept is used to set the current offset (since there is no +measurement that has just been typed in in that case). + + The time is parsed by the public domain `getdate' algorithm. +Consequently, you can only specify time to the nearest second. + + Examples of inputs that are valid are shown below. + + settime 16:30 + settime 16:30:05 + settime Nov 21, 1997 16:30:05 + + For a full description of `getdate', get hold of the getdate +documentation (bundled, for example, with the source for GNU tar). + + +File: chrony.info, Node: sources command, Next: sourcestats command, Prev: settime command, Up: Chronyc command reference + +4.3.4.35 sources +................ + +This command displays information about the current time sources that +`chronyd' is accessing. + + The optional argument `-v' can be specified, meaning _verbose_. In +this case, extra caption lines are shown as a reminder of the meanings +of the columns. + + 210 Number of sources = 3 + MS Name/IP address Stratum Poll LastRx Last sample + ======================================================================= + ^+ a.b.c 3 6 47m -9491us[-6983us] +/- 159ms + ^+ d.e.f 3 6 47m +32ms[ +35ms] +/- 274ms + ^* g.h.i 2 6 47m +8839us[ +11ms] +/- 214ms + + The columns are as follows: + +`M' + This indicates the mode of the source. `^' means a server, `=' + means a peer and `#' indicates a locally connected reference + clock(1). + +`S' + This column indicates the state of the sources. `*' indicates the + source to which `chronyd' is current synchronised. `+' indicates + other acceptable sources. `?' indicates sources to which + connectivity has been lost. `x' indicates a clock which `chronyd' + thinks is is a falseticker (i.e. its time is inconsistent with a + majority of other sources). `~' indicates a source whose time + appears to have too much variability. The `~' condition is also + shown at start-up, until at least 3 samples have been gathered + from it. + +`Name/IP address' + This shows the name or the IP address of the source. + +`Stratum' + This shows the stratum of the source, as reported in its most + recently received sample. Stratum 1 indicates a computer with a + locally attached reference clock. A computer that is synchronised + to a stratum 1 computer is at stratum 2. A computer that is + synchronised to a stratum 2 computer is at stratum 3, and so on. + +`Poll' + This shows the rate at which the source is being polled, as a + base-2 logarithm of the interval in seconds. Thus, a value of 6 + would indicate that a measurement is being made every 64 seconds. + + `chronyd' automatically varies the polling rate in response to + prevailing conditions. + +`LastRx' + This column shows how long ago the last sample was received from + the source. This is normally in seconds. The letters `m', `h', + `d' or `y' indicate minutes, hours, days or years. + +`Last sample' + This column shows the offset between the local clock and the + source at the last measurement. The number in the square brackets + shows the actual measured offset. This may be suffixed by `us' + (indicating microseconds), `ms' (indicating milliseconds), or `s' + (indicating seconds). The number to the left of the square + brackets shows the original measurement, adjusted to allow for any + slews applied to the local clock since. The number following the + `+/-' indicator shows the margin of error in the measurement. + + Positive offsets indicate that the local clock is fast of the + source. + + + ---------- Footnotes ---------- + + (1) In the current version this will never be shown, because +`chronyd' has no support for reference clocks yet. + + +File: chrony.info, Node: sourcestats command, Next: tracking command, Prev: sources command, Up: Chronyc command reference + +4.3.4.36 sourcestats +.................... + +The `sourcestats' command displays information about the drift rate and +offset estimatation process for each of the sources currently being +examined by `chronyd'. + + The optional argument `-v' can be specified, meaning _verbose_. In +this case, extra caption lines are shown as a reminder of the meanings +of the columns. + + An example report is + + 210 Number of sources = 1 + Name/IP Address NP NR Span Frequency Freq Skew Std Dev + ======================================================================== + abc.def.ghi 11 5 46m -0.001 0.045 25us + + The columns are as follows + +`Name/IP Address' + This is the name or dotted-quad IP address of the NTP server (or + peer) to which the rest of the line relates. + +`NP' + This is the number of sample points currently being retained for + the server. The drift rate and current offset are estimated by + performing a linear regression through these points. + +`NR' + This is the number of runs of residuals having the same sign + following the last regression. If this number starts to become + too small relative to the number of samples, it indicates that a + straight line is no longer a good fit to the data. If the number + of runs is too low, `chronyd' discards older samples and re-runs + the regression until the number of runs becomes acceptable. + +`Span' + This is the interval between the oldest and newest samples. If no + unit is shown the value is in seconds. In the example, the + interval is 46 minutes. + +`Frequency' + This is the estimated residual frequency for the server, in parts + per million. In this case, the computer's clock is estimated to + be running 1 part in 10**9 slow relative to the server. + +`Freq Skew' + This is the estimated error bounds on `Freq' (again in parts per + million). + +`Std Dev' + This is the estimated sample standard deviation. + + + +File: chrony.info, Node: tracking command, Next: trimrtc command, Prev: sourcestats command, Up: Chronyc command reference + +4.3.4.37 tracking +................. + +The `tracking' command displays parameters about the system's clock +performance. An example of the output is shown below. + + Reference ID : 1.2.3.4 (a.b.c) + Stratum : 3 + Ref time (UTC) : Sun May 17 06:13:11 1998 + System time : 0.000000 seconds fast of NTP time + Frequency : 331.898 ppm fast + Residual freq : 0.004 ppm + Skew : 0.154 ppm + Root delay : 0.373169 seconds + Root dispersion : 0.024780 seconds + + The fields are explained as follows. + +`Reference ID' + This is the IP address, and name if available, of the server to + which the computer is currently synchronised. If this is + `127.127.1.1' it means the computer is not synchronised to any + external source and that you have the `local' mode operating (via + the `local' command in `chronyc' (*note local command::), or the + `local' directive in the `/etc/chrony.conf' file (*note local + directive::)). + +`Stratum' + The stratum indicates how many hops away from a computer with an + attached reference clock we are. Such a computer is a stratum-1 + computer, so the computer in the example is two hops away (i.e. + `a.b.c' is a stratum-2 and is synchronised from a stratum-1). + +`Ref time' + This is the time (GMT) at which the last measurement from the + reference source was processed. + +`System time' + In normal operation, `chronyd' _never_ steps the system clock, + because any jump in the timescale can have adverse consequences for + certain application programs. Instead, any error in the system + clock is corrected by slightly speeding up or slowing down the + system clock until the error has been removed, and then returning + to the system clock's normal speed. A consequence of this is that + there will be a period when the system clock (as read by other + programs using the `gettimeofday()' system call, or by the `date' + command in the shell) will be different from `chronyd's' estimate + of the current true time (which it reports to NTP clients when it + is operating in server mode). The value reported on this line is + the difference due to this effect. + + On systems such as Solaris and SunOS, `chronyd' has no means to + adjust the fundamental rate of the system clock, so keeps the + system time correct by periodically making offsets to it as though + an error had been measured. The build up of these offsets will be + observed in this report. On systems such as Linux where `chronyd' + can adjust the fundamental rate of the system clock, this value + will show zero unless a very recent measurement has shown the + system to be error. + +`Frequency' + The `frequency' is the rate by which the system's clock would be + would be wrong if `chronyd' was not correcting it. It is + expressed in ppm (parts per million). For example, a value of + 1ppm would mean that when the system's clock thinks it has + advanced 1 second, it has actually advanced by 1.000001 seconds + relative to true time. + + As you can see in the example, the clock in the computer I + developed `chrony' on is not a very good one - it gains about 30 + seconds per day! This was the reason I started to write `chrony' + in the first place. + +`Residual freq' + This shows the `residual frequency' for the currently selected + reference source. This reflects any difference between what the + measurements from the reference source indicate the frequency + should be and the frequency currently being used. + + The reason this is not always zero is that a smoothing procedure is + applied to the frequency. Each time a measurement from the + reference source is obtained and a new residual frequency + computed, the estimated accuracy of this residual is compared with + the estimated accuracy (see `skew' next) of the existing frequency + value. A weighted average is computed for the new frequency, with + weights depending on these accuracies. If the measurements from + the reference source follow a consistent trend, the residual will + be driven to zero over time. + +`Skew' + This is the estimated error bound on the the frequency. + +`Root delay' + This is the total of the network path delays to the stratum-1 + computer from which the computer is ultimately synchronised. + + In certain extreme situations, this value can be negative. (This + can arise in a symmetric peer arrangement where the computers' + frequencies are not tracking each other and the network delay is + very short relative to the turn-around time at each computer.) + +`Root dispersion' + This is the total dispersion accumulated through all the computers + back to the stratum-1 computer from which the computer is + ultimately synchronised. Dispersion is due to system clock + resolution, statistical measurement variations etc. + + An absolute bound on the computer's clock accuracy (assuming the + stratum-1 computer is correct) is given by + + clock_error <= root_dispersion + (0.5 * |root_delay|) + + + +File: chrony.info, Node: trimrtc command, Next: writertc command, Prev: tracking command, Up: Chronyc command reference + +4.3.4.38 trimrtc +................ + +The `trimrtc' command is used to correct the system's real time clock +(RTC) to the main system clock. It has no effect if the error between +the two clocks is currently estimated at less than a second (the +resolution of the RTC is only 1 second). + + The command takes no arguments. It performs the following steps (if +the RTC is more than 1 second away from the system clock): + + 1. Remember the currently estimated gain/loss rate of the RTC and + flush the previous measurements. + + 2. Step the real time clock to bring it within a second of the system + clock. + + 3. Make several measurements to accurately determine the new offset + between the RTC and the system clock (i.e. the remaining fraction + of a second error) + + 4. Save the RTC parameters to the RTC file (specified with the + `rtcfile' directive in the configuration file (*note rtcfile + directive::). + + The last step is done as a precaution against the computer suffering +a power failure before either the daemon exits or the `writertc' +command is issued. + + `chronyd' will still work perfectly well both whilst operating and +across machine reboots even if the `trimrtc' command is never used (and +the RTC is allowed to drift away from true time). The `trimrtc' +command is provided as a method by which it can be corrected, in a +manner compatible with `chronyd' using it to maintain accurate time +across machine reboots. + + +File: chrony.info, Node: writertc command, Prev: trimrtc command, Up: Chronyc command reference + +4.3.4.39 writertc +................. + +The `writertc' command writes the currently estimated error and +gain/loss rate parameters for the RTC to the RTC file (specified with +the `rtcfile' directive (*note rtcfile directive::)). This information +is also written automatically when `chronyd' is killed (with SIGHUP, +SIGINT, SIGQUIT or SIGTERM). + + +File: chrony.info, Node: Porting guide, Next: GPL, Prev: Usage reference, Up: Top + +Appendix A Porting guide +************************ + +This appendix discusses issues that have arisen in writing the +system-specific parts of the existing ports. This will provide useful +information for those attempting to write ports to other systems. + +* Menu: + +* System driver files:: What needs to go in a driver file for a + particular type of system +* Quirks of particular systems:: Problem areas that have been found on ports + already written. + + +File: chrony.info, Node: System driver files, Next: Quirks of particular systems, Up: Porting guide + +A.1 System driver files +======================= + +The system specific parts of the software are contained in files with +names like `sys_linux.c'. + + The following functions are required in a system driver file: + + 1. A function to read the current frequency + + 2. A function to set the current frequency + + 3. A function to slew the system time by a specified delta + + 4. A function to step the system time by a specified delta + + 5. A function to work out the error at a particular time between the + system's clock and `chronyd's' estimate of real time. (This is + required because some systems have to track real time by making + the system time follow it in a 'sawtooth' fashion). + + The "frequency" is the rate at which the system gains or loses time, +measured relative to the system when running uncompensated. + + +File: chrony.info, Node: Quirks of particular systems, Prev: System driver files, Up: Porting guide + +A.2 Quirks of particular systems +================================ + +These sections describe quirks in each system type that needed to be +investigated to port the software to each system type. + +* Menu: + +* Linux porting quirks:: +* Solaris 2.5 porting quirks:: +* SunOS 4.1.4 porting quirks:: + + +File: chrony.info, Node: Linux porting quirks, Next: Solaris 2.5 porting quirks, Up: Quirks of particular systems + +A.2.1 Linux +----------- + +The following quirks have been found in developing the Linux port. + + 1. In order to avoid floating point arithmetic, the kernel uses + shifting and adding to approximate a scaling of 100/128. This + approximation implies that the frequency set via the `adjtimex()' + system call is not the frequency that is actually obtained. The + method of approximation varies between kernel versions and must be + determined by examining the kernel source. An inverse factor must + be included in the driver to compensate. + + 2. In some kernel versions, an `adjtimex()' system call with the flags + bits all zeroed will return the amount of offset still to be + corrected. In others (e.g. the 2.0 series beyond 2.0.32), the + offset must be changed in order to get the old offset returned + (similar to `adjtime()' on other systems). + + + +File: chrony.info, Node: Solaris 2.5 porting quirks, Next: SunOS 4.1.4 porting quirks, Prev: Linux porting quirks, Up: Quirks of particular systems + +A.2.2 Solaris 2.5 +----------------- + +The following quirks have been found in developing the Solaris port. + + 1. The `adjtime()' system call with a zero argument does not cancel an + adjustment that is in progress - it just reports the remaining + adjustment. + + 2. The `settimeofday()' system call only observes the seconds part of + the argument - any fractional seconds part is lost. second. + + 3. The kernel variable `dosynctodr' has to be set to zero, otherwise + the system clock is periodically reset to the real-time clock. + + +File: chrony.info, Node: SunOS 4.1.4 porting quirks, Prev: Solaris 2.5 porting quirks, Up: Quirks of particular systems + +A.2.3 SunOS 4.1.4 +----------------- + +The following quirks have been found in developing the SunOS port. + + 1. The `adjtime()' system call truncates its argument to a multiple of + the system's `tickadj' variable. (`chronyd' sets that to 100, + giving a 1 part in 100 slewing capability for correcting offsets.) + + 2. The kernel variable `dosynctodr' has to be set to zero, otherwise + the system clock is periodically reset to the real-time clock. + + +File: chrony.info, Node: GPL, Prev: Porting guide, Up: Top + +Appendix B GNU General Public License +************************************* + + GNU GENERAL PUBLIC LICENSE + Version 2, June 1991 + + Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59 Temple +Place - Suite 330, Boston, MA 02111-1307, USA Everyone is permitted to +copy and distribute verbatim copies of this license document, but +changing it is not allowed. + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +License is intended to guarantee your freedom to share and change free +software-to make sure the software is free for all its users. This +General Public License applies to most of the Free Software +Foundation's software and to any other program whose authors commit to +using it. (Some other Free Software Foundation software is covered by +the GNU Library General Public License instead.) You can apply it to +your programs, too. + + When we speak of free software, we are referring to freedom, not +price. Our General Public Licenses are designed to make sure that you +have the freedom to distribute copies of free software (and charge for +this service if you wish), that you receive source code or can get it +if you want it, that you can change the software or use pieces of it in +new free programs; and that you know you can do these things. + + To protect your rights, we need to make restrictions that forbid +anyone to deny you these rights or to ask you to surrender the rights. +These restrictions translate to certain responsibilities for you if you +distribute copies of the software, or if you modify it. + + For example, if you distribute copies of such a program, whether +gratis or for a fee, you must give the recipients all the rights that +you have. You must make sure that they, too, receive or can get the +source code. And you must show them these terms so they know their +rights. + + We protect your rights with two steps: (1) copyright the software, +and (2) offer you this license which gives you legal permission to copy, +distribute and/or modify the software. + + Also, for each author's protection and ours, we want to make certain +that everyone understands that there is no warranty for this free +software. If the software is modified by someone else and passed on, we +want its recipients to know that what they have is not the original, so +that any problems introduced by others will not reflect on the original +authors' reputations. + + Finally, any free program is threatened constantly by software +patents. We wish to avoid the danger that redistributors of a free +program will individually obtain patent licenses, in effect making the +program proprietary. To prevent this, we have made it clear that any +patent must be licensed for everyone's free use or not licensed at all. + + The precise terms and conditions for copying, distribution and +modification follow. + + GNU GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, +DISTRIBUTION AND MODIFICATION + + 0. This License applies to any program or other work which contains +a notice placed by the copyright holder saying it may be distributed +under the terms of this General Public License. The "Program", below, +refers to any such program or work, and a "work based on the Program" +means either the Program or any derivative work under copyright law: +that is to say, a work containing the Program or a portion of it, +either verbatim or with modifications and/or translated into another +language. (Hereinafter, translation is included without limitation in +the term "modification".) Each licensee is addressed as "you". + + Activities other than copying, distribution and modification are not +covered by this License; they are outside its scope. The act of +running the Program is not restricted, and the output from the Program +is covered only if its contents constitute a work based on the Program +(independent of having been made by running the Program). Whether that +is true depends on what the Program does. + + 1. You may copy and distribute verbatim copies of the Program's +source code as you receive it, in any medium, provided that you +conspicuously and appropriately publish on each copy an appropriate +copyright notice and disclaimer of warranty; keep intact all the +notices that refer to this License and to the absence of any warranty; +and give any other recipients of the Program a copy of this License +along with the Program. + + You may charge a fee for the physical act of transferring a copy, and +you may at your option offer warranty protection in exchange for a fee. + + 2. You may modify your copy or copies of the Program or any portion +of it, thus forming a work based on the Program, and copy and +distribute such modifications or work under the terms of Section 1 +above, provided that you also meet all of these conditions: + + a) You must cause the modified files to carry prominent notices +stating that you changed the files and the date of any change. + + b) You must cause any work that you distribute or publish, that in + whole or in part contains or is derived from the Program or any +part thereof, to be licensed as a whole at no charge to all third +parties under the terms of this License. + + c) If the modified program normally reads commands interactively +when run, you must cause it, when started running for such +interactive use in the most ordinary way, to print or display an +announcement including an appropriate copyright notice and a notice +that there is no warranty (or else, saying that you provide a +warranty) and that users may redistribute the program under these +conditions, and telling the user how to view a copy of this +License. (Exception: if the Program itself is interactive but does +not normally print such an announcement, your work based on the +Program is not required to print an announcement.) + + These requirements apply to the modified work as a whole. If +identifiable sections of that work are not derived from the Program, +and can be reasonably considered independent and separate works in +themselves, then this License, and its terms, do not apply to those +sections when you distribute them as separate works. But when you +distribute the same sections as part of a whole which is a work based +on the Program, the distribution of the whole must be on the terms of +this License, whose permissions for other licensees extend to the +entire whole, and thus to each and every part regardless of who wrote +it. + + Thus, it is not the intent of this section to claim rights or contest +your rights to work written entirely by you; rather, the intent is to +exercise the right to control the distribution of derivative or +collective works based on the Program. + + In addition, mere aggregation of another work not based on the +Program with the Program (or with a work based on the Program) on a +volume of a storage or distribution medium does not bring the other +work under the scope of this License. + + 3. You may copy and distribute the Program (or a work based on it, +under Section 2) in object code or executable form under the terms of +Sections 1 and 2 above provided that you also do one of the following: + + a) Accompany it with the complete corresponding machine-readable +source code, which must be distributed under the terms of Sections +1 and 2 above on a medium customarily used for software interchange; or, + + b) Accompany it with a written offer, valid for at least three +years, to give any third party, for a charge no more than your cost +of physically performing source distribution, a complete +machine-readable copy of the corresponding source code, to be +distributed under the terms of Sections 1 and 2 above on a medium +customarily used for software interchange; or, + + c) Accompany it with the information you received as to the offer +to distribute corresponding source code. (This alternative is +allowed only for noncommercial distribution and only if you +received the program in object code or executable form with such an +offer, in accord with Subsection b above.) + + The source code for a work means the preferred form of the work for +making modifications to it. For an executable work, complete source +code means all the source code for all modules it contains, plus any +associated interface definition files, plus the scripts used to control +compilation and installation of the executable. However, as a special +exception, the source code distributed need not include anything that +is normally distributed (in either source or binary form) with the +major components (compiler, kernel, and so on) of the operating system +on which the executable runs, unless that component itself accompanies +the executable. + + If distribution of executable or object code is made by offering +access to copy from a designated place, then offering equivalent access +to copy the source code from the same place counts as distribution of +the source code, even though third parties are not compelled to copy +the source along with the object code. + + 4. You may not copy, modify, sublicense, or distribute the Program +except as expressly provided under this License. Any attempt otherwise +to copy, modify, sublicense or distribute the Program is void, and will +automatically terminate your rights under this License. However, +parties who have received copies, or rights, from you under this +License will not have their licenses terminated so long as such parties +remain in full compliance. + + 5. You are not required to accept this License, since you have not +signed it. However, nothing else grants you permission to modify or +distribute the Program or its derivative works. These actions are +prohibited by law if you do not accept this License. Therefore, by +modifying or distributing the Program (or any work based on the +Program), you indicate your acceptance of this License to do so, and +all its terms and conditions for copying, distributing or modifying the +Program or works based on it. + + 6. Each time you redistribute the Program (or any work based on the +Program), the recipient automatically receives a license from the +original licensor to copy, distribute or modify the Program subject to +these terms and conditions. You may not impose any further +restrictions on the recipients' exercise of the rights granted herein. +You are not responsible for enforcing compliance by third parties to +this License. + + 7. If, as a consequence of a court judgment or allegation of patent +infringement or for any other reason (not limited to patent issues), +conditions are imposed on you (whether by court order, agreement or +otherwise) that contradict the conditions of this License, they do not +excuse you from the conditions of this License. If you cannot +distribute so as to satisfy simultaneously your obligations under this +License and any other pertinent obligations, then as a consequence you +may not distribute the Program at all. For example, if a patent +license would not permit royalty-free redistribution of the Program by +all those who receive copies directly or indirectly through you, then +the only way you could satisfy both it and this License would be to +refrain entirely from distribution of the Program. + + If any portion of this section is held invalid or unenforceable under +any particular circumstance, the balance of the section is intended to +apply and the section as a whole is intended to apply in other +circumstances. + + It is not the purpose of this section to induce you to infringe any +patents or other property right claims or to contest validity of any +such claims; this section has the sole purpose of protecting the +integrity of the free software distribution system, which is +implemented by public license practices. Many people have made +generous contributions to the wide range of software distributed +through that system in reliance on consistent application of that +system; it is up to the author/donor to decide if he or she is willing +to distribute software through any other system and a licensee cannot +impose that choice. + + This section is intended to make thoroughly clear what is believed to +be a consequence of the rest of this License. + + 8. If the distribution and/or use of the Program is restricted in +certain countries either by patents or by copyrighted interfaces, the +original copyright holder who places the Program under this License may +add an explicit geographical distribution limitation excluding those +countries, so that distribution is permitted only in or among countries +not thus excluded. In such case, this License incorporates the +limitation as if written in the body of this License. + + 9. The Free Software Foundation may publish revised and/or new +versions of the General Public License from time to time. Such new +versions will be similar in spirit to the present version, but may +differ in detail to address new problems or concerns. + + Each version is given a distinguishing version number. If the +Program specifies a version number of this License which applies to it +and "any later version", you have the option of following the terms and +conditions either of that version or of any later version published by +the Free Software Foundation. If the Program does not specify a +version number of this License, you may choose any version ever +published by the Free Software Foundation. + + 10. If you wish to incorporate parts of the Program into other free +programs whose distribution conditions are different, write to the +author to ask for permission. For software which is copyrighted by the +Free Software Foundation, write to the Free Software Foundation; we +sometimes make exceptions for this. Our decision will be guided by the +two goals of preserving the free status of all derivatives of our free +software and of promoting the sharing and reuse of software generally. + + NO WARRANTY + + 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO +WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. +EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR +OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, +EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED +WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. +THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS +WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF +ALL NECESSARY SERVICING, REPAIR OR CORRECTION. + + 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN +WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY +AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU +FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR +CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE +PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING +RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A +FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF +SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH +DAMAGES. + + END OF TERMS AND CONDITIONS + + Appendix: How to Apply These Terms to Your New Programs + + If you develop a new program, and you want it to be of the greatest +possible use to the public, the best way to achieve this is to make it +free software which everyone can redistribute and change under these +terms. + + To do so, attach the following notices to the program. It is safest +to attach them to the start of each source file to most effectively +convey the exclusion of warranty; and each file should have at least +the "copyright" line and a pointer to where the full notice is found. + + Copyright (C) 19yy + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + 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., 59 Temple Place - Suite 330, Boston, MA 02111-1307, +USA + + Also add information on how to contact you by electronic and paper +mail. + + If the program is interactive, make it output a short notice like +this when it starts in an interactive mode: + + Gnomovision version 69, Copyright (C) 19yy name of author +Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show +w'. This is free software, and you are welcome to redistribute it + under certain conditions; type `show c' for details. + + The hypothetical commands `show w' and `show c' should show the +appropriate parts of the General Public License. Of course, the +commands you use may be called something other than `show w' and `show +c'; they could even be mouse-clicks or menu items-whatever suits your +program. + + You should also get your employer (if you work as a programmer) or +your school, if any, to sign a "copyright disclaimer" for the program, +if necessary. Here is a sample; alter the names: + + Yoyodyne, Inc., hereby disclaims all copyright interest in the +program `Gnomovision' (which makes passes at compilers) written by +James Hacker. + + , 1 April 1989 Ty Coon, President of Vice + + This General Public License does not permit incorporating your +program into proprietary programs. If your program is a subroutine +library, you may consider it more useful to permit linking proprietary +applications with the library. If this is what you want to do, use the +GNU Library General Public License instead of this License. + + + +Tag Table: +Node: Top315 +Node: Introduction855 +Node: Overview1432 +Node: Acknowledgements2959 +Node: Availability3614 +Node: Getting the software3920 +Node: Platforms4170 +Node: Other time synchronisation packages5355 +Node: Comparison with xntpd5645 +Node: Comparison with timed8800 +Node: Distribution and warranty10775 +Node: Bug reporting11125 +Node: Contributing12576 +Node: Installation14373 +Node: readline support17686 +Node: package builders18839 +Node: Typical scenarios20120 +Node: Computers on the net20838 +Node: Infrequent connection22696 +Node: Configuration for infrequent connections23222 +Node: Advising chronyd of internet availability26042 +Node: Isolated networks27404 +Node: Dial-up home PCs29389 +Node: Dial-up overview29772 +Node: Dial-up configuration35337 +Node: Configuration options overview38620 +Node: Usage reference39785 +Node: Starting chronyd40135 +Node: Configuration file44065 +Node: comments in config file47088 +Node: acquisitionport directive47525 +Node: allow directive48368 +Node: bindaddress directive50806 +Node: bindcmdaddress directive52202 +Node: broadcast directive53159 +Node: cmdallow directive54831 +Node: cmddeny directive55493 +Node: commandkey directive55948 +Node: cmdport directive56688 +Node: deny directive57202 +Node: driftfile directive57639 +Node: dumpdir directive58951 +Node: dumponexit directive60185 +Node: initstepslew directive60547 +Node: keyfile directive63362 +Node: local directive64488 +Node: linux_hz directive66008 +Node: linux_freq_scale directive66729 +Node: log directive67733 +Node: measurements log68831 +Node: statistics log70815 +Node: tracking log73342 +Node: RTC log74557 +Node: logchange directive76391 +Node: logdir directive77247 +Node: mailonchange directive77564 +Node: manual directive78083 +Node: maxupdateskew directive78808 +Node: noclientlog directive80276 +Node: peer directive80646 +Node: pidfile directive80975 +Node: port directive81425 +Node: rtcdevice directive82063 +Node: rtcfile directive82502 +Node: rtconutc directive83807 +Node: server directive84752 +Node: Running chronyc90205 +Node: Chronyc basic use90794 +Node: Chronyc command line options91380 +Node: Security with chronyc92302 +Node: Chronyc command reference94094 +Node: accheck command97080 +Node: activity command97622 +Node: add peer command98791 +Node: add server command99340 +Node: allow command99902 +Node: allow all command100462 +Node: burst command100750 +Node: clients command103295 +Node: cmdaccheck command105119 +Node: cmdallow command105508 +Node: cmdallow all command105855 +Node: cmddeny command106209 +Node: cmddeny all command106553 +Node: cyclelogs command106906 +Node: delete command107695 +Node: deny command108135 +Node: deny all command108568 +Node: dump command108851 +Node: exit command109547 +Node: help command109791 +Node: local command110011 +Node: makestep command110866 +Node: manual command111743 +Node: maxdelay command113868 +Node: maxdelayratio command114685 +Node: maxpoll command115626 +Node: maxupdateskew command116560 +Node: minpoll command116869 +Node: offline command117794 +Node: online command120379 +Node: password command120810 +Node: quit command121748 +Node: rtcdata command121999 +Node: settime command124160 +Node: sources command126223 +Ref: sources command-Footnote-1129440 +Node: sourcestats command129556 +Node: tracking command131686 +Node: trimrtc command136994 +Node: writertc command138569 +Node: Porting guide139013 +Node: System driver files139621 +Node: Quirks of particular systems140556 +Node: Linux porting quirks140951 +Node: Solaris 2.5 porting quirks141955 +Node: SunOS 4.1.4 porting quirks142655 +Node: GPL143240 + +End Tag Table --- chrony-1.21z.orig/faq.html +++ chrony-1.21z/faq.html @@ -0,0 +1,635 @@ + + +Frequently asked questions + + + + + + + + +

+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. Administrative issues +
      +
    • 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. Chrony compared to other programs +
      +
    • 2.1. How does chrony compare to xntpd? +
    +
  • 3. Compilation issues +
      +
    • 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. Selection of NTP servers +
      +
    • 4.1. I have several computers on a LAN. Should I make one the master, or make them all clients of an external server? +
    +
  • 5. Addressing issues +
      +
    • 5.1. I get the following error message : "Could not get IP adress for localhost" +
    • 5.2. I have problems if I put the names of my NTP servers in the chrony.conf file. +
    +
  • 6. My computer is not synchronising. +
      +
    • 6.1. Behind a firewall? +
    • 6.2. Do you have a non-permanant (i.e. intermittent) Internet connection? +
    • 6.3. In measurements.log, do the '7' and '8' flag columns always show zero? +
    +
  • 7. Issues with chronyd +
      +
    • 7.1. chronyd crashes after a syslog message "adjtimex failed for set frequency" +
    +
  • 8. Issues with chronyc +
      +
    • 8.1. I keep getting the error '510 No command access from this host --- Reply not authenticated'. +
    • 8.2. I cannot log in from chronyc to carry out privileged tasks. +
    • 8.3. When I enter a command and hit <Return>, chronyc hangs +
    • 8.4. Is the chronyc<->chronyd protocol documented anywhere? +
    +
  • 9. Real-time clock issues. +
      +
    • 9.1. What is the real-time clock (RTC)? +
    • 9.2. I want to use chronyd's real-time clock support. Must I disable hwclock? +
    • 9.3. I just keep getting the '513 RTC driver not running' message +
    +
  • 10. Problems with isolated networks. +
      +
    • 10.1. When I use the 'settime' command, chronyd crashes. +
    +
  • 11. Microsoft Windows +
      +
    • 11.1. Does chrony support Windows? +
    • 11.2. Are there any plans to support Windows? +
    • 11.3. What alternative NTP clients are there for Windows? +
    +
  • 12. NTP-specific issues +
      +
    • 12.1. Can chrony be driven from broadcast NTP servers? +
    • 12.2. Can chronyd transmit broadcast NTP packets (e.g. to synchronise other computers on a private LAN)? +
    • 12.3. Can chrony keep the system clock a fixed offset away from real time? +
    • 12.4. What happens if the network connection is dropped without using chronyc's 'offline' command first? +
    +
  • 13. Development +
      +
    • 13.1. Can I get the source via CVS from anywhere? +
    +
  • 14. Linux-specific issues +
      +
    • 14.1. Why does the source code include kernel header files? +
    • 14.2. I get "Could not open /dev/rtc, Device or resource busy" in my syslog file. +
    +
  • 15. Solaris-specific issues +
      +
    • 15.1. On Solaris 2.8, I get an error message about not being able to open kvm to change dosynctodr. +
    +
+
+ + +

+ +1.1. Where can I get chrony source code? +

+Via the home page, see below.
+
+
+

+ +1.2. Are there any packaged versions of chrony? +

+I am aware of packages for Debian, Mandrake and Redhat.  I am not personally
+involved with how these are built or distributed.
+
+
+

+ +1.3. Where is the home page? +

+It is currently at http://chrony.sunsite.dk/. 
+
+
+

+ +1.4. Is there a mailing list? +

+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.
+
+
+

+ +1.5. What licence is applied to chrony? +

+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).
+
+
+
+ + +

+ +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 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
+
+
+

+ +3.2. Can I compile chrony with an ANSI-C compiler that is not GCC v2.x? +

+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.
+
+
+

+ +3.3. I get errors like 'client.c:44: readline/readline.h: file not found' +

+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).
+
+
+

+ +3.4. I have RedHat 7.3 and can't compile rtc_linux.c (error in spinlock.h) +

+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.
+
+
+
+ + +

+ +4.1. I have several computers on a LAN. Should I make one the master, or make them all clients of an external server? +

+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.
+
+
+
+ + +

+ +5.1. I get the following error message : "Could not get IP adress for localhost" +

+Add a line like the following to your /etc/hosts file
+    127.0.0.1   localhost
+
+
+

+ +5.2. I have problems if I put the names of my NTP servers in the chrony.conf file. +

+If you have no connection to the Internet at boot time, chrony won't be able to
+turn the names into IP addresses when it starts.  There seem to be 2 solutions:
+
+1. Put the numeric IP addresses in the chrony.conf file
+or
+2. Put the server->IP address mappings in your /etc/hosts file and ensure that
+   /etc/host.conf reads 'order hosts,bind'.
+
+The problem is that chronyd (currently) isn't designed in a way that allows
+hostname->IP address lookups during normal operation.  I hope to work on this
+problem very soon.
+
+
+
+ + +
+This is the most common problem.  There are a number of reasons, see the
+following questions.
+
+
+

+ +6.1. 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 etherfind 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 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.
+
+
+

+ +6.2. Do you have a non-permanant (i.e. intermittent) Internet connection? +

+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.
+
+
+

+ +6.3. In measurements.log, do the '7' and '8' flag columns always show zero? +

+Do you have a 'local stratum X' directive in the chrony.conf file?  If X is
+lower than the stratum of the server you're trying to use, this situation will
+arise.  You should always make X quite high (e.g. 10) in this directive.
+
+
+
+ + +

+ +7.1. chronyd crashes after a syslog message "adjtimex failed for set frequency" +

+The usual cause is that the kernel is running with a different value of 'HZ'
+(the timer interrupt rate) than the value that was found in the kernel header
+files when chrony was compiled.  The chrony.conf file can include options to
+modify the HZ value (see the discussion of linux_hz and linux_freq_scale in the
+documentation), however the problem is to find the value of HZ being used.
+
+At the end of the chrony v1.18 section of the download page
+you'll find instructions on how to do this.
+
+This will be fixed in version 1.19, by getting chronyd to auto-detect the
+kernel's value rather than relying on the compiled-in default.
+
+
+
+ + +

+ +8.1. I keep getting the error '510 No command access from this host --- Reply not authenticated'. +

+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.  This
+shouldn't be necessary for localhost, but some people still seem to need an
+entry like 'cmdallow 127.0.0.1'.  (It would be good to understand why problem
+only affects some people).
+
+
+

+ +8.2. I cannot log in from chronyc to carry out privileged tasks. +

+This is the second most common problem.
+
+Perhaps your /etc/chrony.keys file is badly formatted.  Make sure that the
+final line has a line feed at the end, otherwise the key on that line will work
+as though the last character is missing.  (Note, this bug was fixed in version
+1.16.)
+
+
+

+ +8.3. When I enter a command and hit <Return>, chronyc hangs +

+This probably means that chronyc cannot communicate with chronyd.
+
+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.
+
+
+

+ +8.4. Is the chronyc<->chronyd protocol documented anywhere? +

+Only by the source code :-)  See cmdmon.c (chronyd side) and client.c (chronyc
+side).
+
+
+
+ + +

+ +9.1. What is the real-time clock (RTC)? +

+This is the clock which keeps the time even when your computer is turned off.
+It works with 1 second resolution.   chronyd can monitor the rate at which the
+real-time clock gains or loses time, and compensate for it when you set the
+system time from it at the next reboot.  See the documentation for details.
+
+
+

+ +9.2. I want to use chronyd's real-time clock support. Must I disable hwclock? +

+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
+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.  At the next reboot, chronyd 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.
+
+
+

+ +9.3. 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.                                                                                  
+
+
+
+ + +

+ +10.1. When I use the 'settime' command, chronyd crashes. +

+If you enter times that are too far away from the real time, chronyd will
+think the system clock runs fast or slow by an excessive amount.  The required
+compensation factor will be outside the bounds for the adjtimex() system call.
+chronyd will crash when it tries to apply such an excessive adjustment.
+
+
+
+ + +

+ +11.1. 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 an NT service.
+
+
+

+ +11.2. Are there any plans to support Windows? +

+I have no personal plans to do this.  I have neither the time nor the
+Windows programming expertise.  Some time ago I did start work on a port which
+I was developing under Cygwin.  Anyone is welcome to pick this work up and
+contribute it back to the project.
+
+
+

+ +11.3. What alternative NTP clients are there for Windows? +

+Some of the names I've seen mentioned are 
+   - Automachron
+   - NetTime (nettime.sourceforge.net)
+
+
+
+ + +

+ +12.1. Can chrony be driven from broadcast NTP servers? +

+No.  I remember looking at how they worked when I was first writing chrony.
+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!
+
+
+

+ +12.2. 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.
+
+
+

+ +12.3. 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
+the program currently stands.
+
+
+

+ +12.4. 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
+are online.  Eventually it will decide that they are unreachable and no longer
+consider itself synchronised to them.  If you have other computers on 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
+computer.
+
+The 'auto_offline' option to the 'server' entry in the chrony.conf file may be
+useful to avoid this situation.
+
+
+
+ + +

+ +13.1. Can I get the source via CVS from anywhere? +

+Yes.  See http://chrony.sunsite.dk/cvs.php for information.  Currently there is
+only anonymous read-only access.  I keep the master copy on my own PC, which is
+more convenient for me because I don't have to connect to the Internet to do
+CVS operations on the files.  So for now, there is no read-write access for
+other developers.  Please email me your patches + documentation instead.
+
+
+
+ + +

+ +14.1. 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 (from 2.0 up anyway, I doubt 1.x still works.)  Hopefully
+the situation will not deteriorate further with future kernel versions.
+
+
+

+ +14.2. 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
+defined in different start-up scripts.)
+
+
+
+ + +

+ +15.1. On Solaris 2.8, I get an error message about not being able to open kvm to change dosynctodr. +

+(The dosynctodr variable controls whether Solaris couples the equivalent of its
+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
+has changed which prevents the same technique working.  I no longer have root
+access to any Solaris machines to work on this, and am reliant on somebody
+developing the patch and testing it.  A good starting point would be to see if
+xntpd has been modified to work for Solaris 2.8.
+
+
+
+ +Back to +the author's +main page + +