Timezone problems on -current

Mark Millard marklmi at yahoo.com
Tue May 4 02:22:31 UTC 2021


On 2021-May-3, at 19:18, Mark Millard <marklmi at yahoo.com> wrote:

> On 2021-May-3, at 18:52, bob prohaska <fbsd at www.zefox.net> wrote:
> 
>> On Tue, May 04, 2021 at 02:13:55AM +0100, tech-lists wrote:
>>> 
>>> # ntpd
>>> ntpdate_enable="YES"
>>> ntpdate_flags="-b"
>>> ntpdate_hosts="uk.pool.ntp.org"
>>> ntpd_enable="YES"
>>> ntpd_sync_on_start="YES"
>>> 
> 
> Warning from the ntpdate man page:
> 
> QUOTE
>     The ntpdate utility will decline to set the date if an NTP server daemon
>     (e.g., ntpd(8)) is running on the same host.
> END QUOTE
> 
> The above enables both and possibly makes the two
> compete with each other depending on how they race
> at the start. I'd avoid the mix.
> 
>> Up to now I've used only the line 
>> ntpdate_enable="YES"
>> and it's been enough to keep the clock sane. On the last reboot
>> it appears ntpdate either didn't run or failed silently. The most
>> obvious suspect is a wireless ethernet bridge that might be saying
>> it's up before the access point is responsive.
>> 
>> I'll have to do a few test reboots when the machine becomes idle.
>> I know ntpdate works sometimes, but perhaps not always.  
> 
> I'll note that I use ntpd instead of ntpdate in
> my /etc/rc.conf files:
> 
> ntpd_enable="YES"
> ntpd_sync_on_start="YES"
> ntpd_user="root"
> 
> Such might be an alternative. But I do not know the
> detailed tradeoffs for this or other alternatives.
> 

Another quote from "man ntpdate":

QUOTE
     Note: The functionality of this program is now available in the ntpd(8)
     program.  See the -q command line option in the ntpd(8) page.  After a
     suitable period of mourning, the ntpdate utility is to be retired from
     this distribution.
END QUOTE


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)



More information about the freebsd-arm mailing list