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