Timezone problems on -current

[Ian Lepore]

On Tue, 2021-05-04 at 08:42 -0700, bob prohaska wrote:
> On Tue, May 04, 2021 at 08:42:14AM -0600, Ian Lepore wrote:
> > On Mon, 2021-05-03 at 18:52 -0700, bob prohaska wrote:
> > > 
> > > 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
> > 
> > You don't need to be running ntpdate at all.  ntpd_sync_on_start
> > gives
> > you the same effect... it allows ntpd to step the clock any
> > required
> > amount, one time at startup.  It's useful for systems that don't
> > have a
> > battery-backed clock.
> > 
> 
> It seems clear that ntpd_sync_on_start is a better choice than
> ntpdate.
> Clock drift on the Pi seems fairly slow, a couple seconds a month,
> but
> staying right on can't hurt and doesn't cost much. 
> 
> > I like to set kern.timecounter.stepwarnings=1 in /etc/sysctl.conf
> > so I
> > have a record in syslog of when ntpd steps the clock.
> 
> Most of my trouble seems to have been caused by timesetting not
> running at
> startup and me not noticing promptly. A combination of
> ntpd_sync_on_start 
> and a -g flag will set the clock and make a fuss in the logfiles if 
> time drifts too far off. Is there a way to make a fuss if ntpd fails
> to start in the first place or quits in mid-flight?
> 
> Thanks for writing!
> 
> bob prohaska
> 

Setting ntpd_sync_on_start=yes sets the -g flag for you, you don't also
have to set ntpd_flags yourself.

-- Ian