Re: [gentoo-user] [SOLVED] What ntp/sntp client do people use?

[Dale]

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

:-)  :-)