Re: [chrony-users] chrony configuration help (please)
Hi, Thanks for the answer. Comments inline below. Il 04/08/2015 17:50, Bill Unruh ha scritto: On Tue, 4 Aug 2015, Miroslav Lichvar wrote: On Mon, Aug 03, 2015 at 10:56:51PM +0200, Mauro Condarelli wrote: 2. In the above event, after several minutes, chrony announces it is going to step by several million seconds (as expected); shortly thereafter system dies... somewhat; i.e.: serial console and ssh are completely unresponsive, but "ping" gets an answer. Nothing is logged. Hm, that's odd. Can you reproduce the problem by stepping the clock manually with the date command, e.g. date -s '+ 100 sec' ? In this context might there be an option for chrony to take the intial time when starting up from the date and time on some file. eg --startfile If that directive is there then chrony would use the mtime (plus say 60 sec) from that file as the startup file if the rtc time does not exist, or if the rtc time is earlier than that mtime. That would solve the problem of an insanely early rtc time or no rtc at all (rPi for example) and give a time which is at least not totally crazy. The problem with iburst is that the clock is initially set already to a potentially insane time so the system for a while has a problematic time. Agreed. Can You give me specific instructions? As said this is the first time I attempt to use chrony at all. Re the problem itself, ping is pretty deep down in the kernel, so much of the kernel could be dead, and user programs dead and ping will still respond. But the kernel should not die just because the clock is advanced by a few decades. Sounds like a kernel bug. What OS/Distribution is this again I do not have a "distribution". This is an embedded system based on ACME AriaG25. I recompiled everything from scratch (including arm-gcc) using the Biuldroot framework. / # uname -a Linux ok-cash 3.16.1 #1 Thu Jul 16 14:02:29 CEST 2015 armv5tejl GNU/Linux System seems to be generically be well behaving, but I *cannot* exclude neither software build nor straight hardware bugs, unfortunately. Brutally cutting power (mains *and* battery backup, so no graceful chrony termination *and* RTC reset) i get into the error condition: ... Jan 1 01:00:09 ok-cash user.info kernel: [3.093750] EXT4-fs (mmcblk0p6): mounted filesystem with ordered data mode. Opts: (null) Jan 1 01:00:09 ok-cash daemon.info kernel: [3.492187] udevd[476]: starting version 3.0 Jan 1 01:00:09 ok-cash user.notice kernel: [3.515625] random: udevd urandom read with 85 bits of entropy available Jan 1 01:00:11 ok-cash user.notice kernel: [4.968750] random: nonblocking pool is initialized Jan 1 01:00:11 ok-cash daemon.info chronyd[494]: chronyd version 1.31 starting Jan 1 01:00:11 ok-cash daemon.err chronyd[494]: Could not open IPv6 NTP socket : Address family not supported by protocol Jan 1 01:00:11 ok-cash daemon.err chronyd[494]: Could not open IPv6 command socket : Address family not supported by protocol Jan 1 01:00:11 ok-cash daemon.info chronyd[494]: Set system time, error in RTC = 31906737.155476 Dec 27 18:01:14 ok-cash daemon.info chronyd[494]: Frequency -1.498 +/- 0.147 ppm read from /var/lib/chrony/drift Dec 27 18:01:24 ok-cash daemon.info chronyd[494]: System trim from RTC = 0.691058 Dec 27 18:01:24 ok-cash daemon.info init: starting pid 506, tty '': '/bin/ash ' Dec 27 18:01:26 ok-cash user.info kernel: [ 17.867187] macb f802c000.ethernet eth0: link up (100/Full) Dec 27 18:01:29 ok-cash daemon.info avahi-daemon[555]: Found user 'avahi' (UID 1003) and group 'avahi' (GID 1000). ... Dec 27 18:03:02 ok-cash auth.info sshd[605]: Accepted password for mcon from 192.168.7.114 port 16760 ssh2 Dec 27 18:03:05 ok-cash authpriv.notice sudo: mcon : TTY=pts/1 ; PWD=/home/mcon ; USER=root ; COMMAND=/bin/su - Dec 27 18:03:05 ok-cash auth.notice su: + /dev/pts/1 mcon:root ... / # date Tue Dec 27 18:01:58 CET 2005 ... Dec 27 18:05:06 ok-cash daemon.info chronyd[494]: Selected source 193.204.114.233 Aug 4 20:47:36 ok-cash daemon.warn chronyd[494]: System clock was stepped by 303010949.791602 seconds Here the system is virtually dead. I can post the whole startup sequence, if deemed useful. Pretty please HLP!!! TiA Mauro -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] chrony configuration help (please)
Hi, Thanks for the answer. Comments inline below. Il 04/08/2015 11:00, Miroslav Lichvar ha scritto: On Mon, Aug 03, 2015 at 10:56:51PM +0200, Mauro Condarelli wrote: Absolute precision is not a requirement, I can tolerate errors of several seconds, but I cannot leave clocks to drift and rely on manual resynchronization. My current /etc/chrony.conf is: === server 0.it.pool.ntp.org server 1.it.pool.ntp.org server 2.pool.ntp.org server 3.pool.ntp.org logdir /var/log/chrony log statistics measurements tracking driftfile /var/lib/chrony/drift keyfile /etc/chrony.keys generatecommandkey makestep 10 3 maxupdateskew 100.0 dumponexit dumpdir /var/lib/chrony rtconutc rtcautotrim 1 rtcfile /var/lib/chrony/rtc === This, however, is far from being optimal for (at least) two reasons 1. If, for any reason (e.g.: battery disconnection), the RTC loses the right time Date is severely (several years) in the past for minutes, even if the system is connected to the Internet. You can speed up the initial synchronization by adding the iburst option to the server lines, or use the initstepslew directive. You may also want to start chronyd with the -s option so it sets the system clock from RTC with compensated drift. I'll try, but explicit examples would be welcome, as I am a first-time user of chrony. 2. In the above event, after several minutes, chrony announces it is going to step by several million seconds (as expected); shortly thereafter system dies... somewhat; i.e.: serial console and ssh are completely unresponsive, but "ping" gets an answer. Nothing is logged. Hm, that's odd. Can you reproduce the problem by stepping the clock manually with the date command, e.g. date -s '+ 100 sec' ? not exactly. I have the following log (interspersed are commads given via ssh on another connection): Aug 4 20:19:16 ok-cash daemon.info avahi-daemon[555]: Registering new address record for 192.168.7.102 on eth0.IPv4. Aug 4 20:19:16 ok-cash daemon.info avahi-daemon[555]: Registering HINFO record with values 'ARMV5TEJL'/'LINUX'. Aug 4 20:19:17 ok-cash daemon.info avahi-daemon[555]: Server startup complete. Host name is ok-cash.local. Local service cookie is 2363394918. Aug 4 20:19:18 ok-cash auth.info sshd[569]: Server listening on 0.0.0.0 port 22. Aug 4 20:19:18 ok-cash daemon.info avahi-daemon[555]: Service "ok-cash" (/etc/avahi/services/ssh.service) successfully established. Aug 4 20:19:18 ok-cash daemon.info avahi-daemon[555]: Service "ok-cash" (/etc/avahi/services/sftp-ssh.service) successfully established. Aug 4 20:19:29 ok-cash auth.info sshd[577]: Accepted password for mcon from 192.168.7.124 port 16309 ssh2 Aug 4 20:19:32 ok-cash authpriv.notice sudo: mcon : TTY=pts/0 ; PWD=/home/mcon ; USER=root ; COMMAND=/bin/su - Aug 4 20:19:32 ok-cash auth.notice su: + /dev/pts/0 mcon:root Aug 4 20:21:50 ok-cash daemon.info chronyd[494]: Selected source 193.204.114.233 Aug 4 20:22:23 ok-cash daemon.info chronyd[494]: Trimming RTC, error = -37.392 seconds Aug 4 20:22:49 ok-cash daemon.info chronyd[494]: Trimming RTC, error = -3.106 seconds Aug 4 20:23:32 ok-cash daemon.info chronyd[494]: Trimming RTC, error = -4.693 seconds Aug 4 20:24:15 ok-cash daemon.info chronyd[494]: Trimming RTC, error = -5.170 seconds Aug 4 20:24:57 ok-cash daemon.info chronyd[494]: Trimming RTC, error = -4.649 seconds / # date -s '2025-01-07' Tue Jan 7 00:00:00 CET 2025 Jan 7 00:00:00 ok-cash daemon.warn chronyd[494]: Forward time jump detected! Jan 7 00:00:00 ok-cash daemon.info chronyd[494]: Can't synchronise: no reachable sources Jan 7 00:02:55 ok-cash daemon.info chronyd[494]: Selected source 192.71.245.44 Jan 7 00:02:55 ok-cash daemon.info chronyd[494]: Selected source 212.45.144.206 Jan 7 00:02:55 ok-cash daemon.info chronyd[494]: Selected source 193.204.114.233 Jan 7 00:02:56 ok-cash daemon.info chronyd[494]: Trimming RTC, error = -21.945 seconds Jan 7 00:03:37 ok-cash daemon.info chronyd[494]: Trimming RTC, error = -5.648 seconds Jan 7 00:04:18 ok-cash daemon.info chronyd[494]: Trimming RTC, error = -5.348 seconds As You see it takes about 3 min to resync... but date is not really corrected. I do not really understand these very large errors; shouldn't they decrease? TiA Mauro -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] chrony configuration help (please)
On Mon, Aug 03, 2015 at 10:56:51PM +0200, Mauro Condarelli wrote: > Absolute precision is not a requirement, I can tolerate errors of several > seconds, but I cannot leave clocks to drift and rely on manual > resynchronization. > > My current /etc/chrony.conf is: > === > server 0.it.pool.ntp.org > server 1.it.pool.ntp.org > server 2.pool.ntp.org > server 3.pool.ntp.org > > logdir /var/log/chrony > log statistics measurements tracking > driftfile /var/lib/chrony/drift > keyfile /etc/chrony.keys > generatecommandkey > makestep 10 3 > maxupdateskew 100.0 > dumponexit > dumpdir /var/lib/chrony > rtconutc > rtcautotrim 1 > rtcfile /var/lib/chrony/rtc > === > > This, however, is far from being optimal for (at least) two reasons > > 1. If, for any reason (e.g.: battery disconnection), the RTC loses the right > time Date is severely (several years) in the past for minutes, even if the > system is connected to the Internet. You can speed up the initial synchronization by adding the iburst option to the server lines, or use the initstepslew directive. You may also want to start chronyd with the -s option so it sets the system clock from RTC with compensated drift. > 2. In the above event, after several minutes, chrony announces it is going to > step by several million seconds (as expected); shortly thereafter system > dies... somewhat; i.e.: serial console and ssh are completely unresponsive, > but "ping" gets an answer. Nothing is logged. Hm, that's odd. Can you reproduce the problem by stepping the clock manually with the date command, e.g. date -s '+ 100 sec' ? -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
