[CentOS] Chrony vd NTP

Sun Feb 5 16:58:25 UTC 2017
J Martin Rushton <martinrushton56 at btinternet.com>

On 05/02/17 16:15, Richard wrote:
> 
>> Date: Sunday, February 05, 2017 10:26:05 -0500
>> From: Robert Moskowitz <rgm at htt-consult.com>
>>
>> I have read:
>> http://thegeekdiary.com/centos-rhel-7-chrony-vs-ntp-differences-bet
>> ween-ntpd-and-chronyd/
>>
>> My server is up all the time and will serve time to internal
>> systems (via DHCP options).
>>
>> Caveat is that my server is an armv7 (Cubieboard2) which does not
>> have an RTC (no battery).  So whenever the system boots, the time
>> is ZERO (Dec 31, 1969 or some such).
>>
>> Chrony fixes this really fast; shortly after boot the time is good.
>> Chrony CAN be configed as an internal time server.  But chrony does
>> not seem to step the clock for any adjustments needed.  It is more
>> important that this systems time be right all the time than to
>> avoid clock steps.
>>
>> This brings me back to NTP, which normally takes hours to bring the
>> time from ZERO to current, but keeps the time correct.
>>
>> So:
>>
>> Can Chrony check the time, say once a day?
>>
>> Or can NTP make a BIG time jump all at once (on system restart)?
> 
> Where I have somewhat similar issues, I have historically used a
> crontab "@reboot" entry to call ntpdate which gets the clock set
> correctly. From there ntp keeps it in sync.
> 
> This can now be accomplished with ntpd, and ntpdate is threatened
> with depreciation/retirement. See the top of the ntpdate man page for
> more details.
> 
The NTP configuration option you may be after is "tinker panic 0" which
allows NTP to make big jumps as often as required.  See ntp_misc(5).
There is a related discussion with making VMs take big jumps at
https://www.centos.org/forums/viewtopic.php?f=16&t=61186&p=258254#p258254

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos/attachments/20170205/5cad9399/attachment-0004.sig>