Walter Dnes wrote: > On Tue, Dec 10, 2019 at 11:14:48PM -0600, Dale wrote >> Walter Dnes wrote: >> >>> ======================================================================= >>> >>> strip: x86_64-pc-linux-gnu-strip --strip-unneeded -N >>> __gentoo_check_ldflags__ -R .comment -R .GCC.command.line -R >>> .note.gnu.gold-version >>> /usr/bin/chronyc >>> /usr/sbin/chronyd >>> >> I have no idea what this part is doing. > That is approaching the end of the "emerge chrony" process. I wanted > to show that I've installed chrony. > >>>>>> Installing (1 of 1) net-misc/chrony-3.5-r2::gentoo >>>>>> Recording net-misc/chrony in "world" favorites file... >>>>>> Auto-cleaning packages... >>>>>> No outdated packages were found on your system. >>> * GNU info directory index is up-to-date. >>> [i660][root][~] man chrony >>> No manual entry for chrony >>> [i660][root][~] info chrony >>> info: No menu item 'chrony' in node '(dir)Top' >>> [i660][root][~] emerge --unmerge chrony >>> >>> ======================================================================= >> I found the manual here. It was the first hit on google for me. >> >> https://chrony.tuxfamily.org/documentation.html >> Hope that helps. > Thanks. From that webpage... > >> 2.7. Does chronyd have an ntpdate mode? >> >> Yes. With the -q option chronyd will set the system clock once and >> exit. With the -Q option it will print the measured offset without >> setting the clock. If you don't want to use a configuration file, >> NTP servers can be specified on the command line. For example: >> >> # chronyd -q 'pool pool.ntp.org iburst' > So I ran a script 3 times... > > #!/bin/bash > date > chronyd -q 'pool ca.pool.ntp.org iburst' > date > > ...and I got... > > [i660][root][~] ./settime > Wed 11 Dec 2019 12:18:45 PM EST > 2019-12-11T17:18:45Z chronyd version 3.5 starting (+CMDMON +NTP +REFCLOCK > +RTC -PRIVDROP +SCFILTER -SIGND +ASYNCDNS -SECHASH -IPV6 -DEBUG) > 2019-12-11T17:18:50Z System clock wrong by 0.574369 seconds (step) > 2019-12-11T17:18:51Z chronyd exiting > Wed 11 Dec 2019 12:18:51 PM EST > [i660][root][~] ./settime > Wed 11 Dec 2019 12:19:06 PM EST > 2019-12-11T17:19:06Z chronyd version 3.5 starting (+CMDMON +NTP +REFCLOCK > +RTC -PRIVDROP +SCFILTER -SIGND +ASYNCDNS -SECHASH -IPV6 -DEBUG) > 2019-12-11T17:19:12Z System clock wrong by -0.000421 seconds (step) > 2019-12-11T17:19:12Z chronyd exiting > Wed 11 Dec 2019 12:19:12 PM EST > [i660][root][~] ./settime > Wed 11 Dec 2019 12:19:18 PM EST > 2019-12-11T17:19:18Z chronyd version 3.5 starting (+CMDMON +NTP +REFCLOCK > +RTC -PRIVDROP +SCFILTER -SIGND +ASYNCDNS -SECHASH -IPV6 -DEBUG) > 2019-12-11T17:19:23Z System clock wrong by -0.000084 seconds (step) > 2019-12-11T17:19:23Z chronyd exiting > Wed 11 Dec 2019 12:19:23 PM EST > > I'm not totally happy that I have to run it 3 times, but I can do that > in the script. I prefer openrdate's approach where it gets the exact > time once. What's with this "step" fetish? >
As Mick pointed out, it is really intended to be run as a service. You start it and over time it adjusts the time until it is accurate. I don't think it is intended to run as a command and then not run again since most clocks drift which is why things like chrony and *date are needed. It adjusts the time in steps. It's not a fetish, it's how it works. When I used ntpdate, it did the same way. As far as I know, all the programs that set the clocks and keep them from drifting off are done in steps. I don't know how openrdate works but for chrony, set up the config file and then /etc/init.d/chronyd start. After a bit, you can check to see how close it is. If things are working well enough, don't forget to add it to a runlevel so that it starts when you boot up. This is what mine shows and its been running as a service since my last reboot about 13 days ago. root@fireball / # chronyc sources -v 210 Number of sources = 6 .-- Source mode '^' = server, '=' = peer, '#' = local clock. / .- Source state '*' = current synced, '+' = combined , '-' = not combined, | / '?' = unreachable, 'x' = time may be in error, '~' = time too variable. || .- xxxx [ yyyy ] +/- zzzz || Reachability register (octal) -. | xxxx = adjusted offset, || Log2(Polling interval) --. | | yyyy = measured offset, || \ | | zzzz = estimated error. || | | \ MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^+ triangle.kansas.net 3 10 251 64m -36us[ -937us] +/- 132ms ^? B1-66ER.matrix.gs 0 10 0 - +0ns[ +0ns] +/- 0ns ^? eris.kallisti.us 0 10 0 - +0ns[ +0ns] +/- 0ns ^? 204-62-14-98.static.6syn> 0 10 0 - +0ns[ +0ns] +/- 0ns ^? 69.50.219.51 0 10 0 - +0ns[ +0ns] +/- 0ns ^* bindcat.fhsu.edu 2 10 377 445 -433us[-1298us] +/- 75ms root@fireball / # It appears that my clock is accurate somewhere between 75 and 132ms. It also seems I need to update my server list since some are not working. Dale :-) :-)
