[ale] NTP/Chrony time zone persistence

[warlord at MIT.EDU (Derek Atkins)]

Hi,

"Edward O. Holcroft" <eholcroft at mkainc.com> writes:

> hwclock?Wed 14 Sep 2016 06:47:15 AM PDT ?-0.896088 seconds
> date Wed Sep 14 06:47:23 PDT 2016
>
> Then if I reboot, note how server drops back 3 hrs:
> hwclock Wed 14 Sep 2016 06:49:07 AM PDT ?-0.364745 seconds
> date Wed Dec 14 03:50:17 PST 2016

This seems to imply to me that setting the runtime clock from the
hwclock isn't happening properly when the system is rebooted.
This doesn't seem to be a timezone issue, as both hwclock and system
clock are both showing America/Pacific (based on the PDT/PST for Sep 14
and Dec 14 respectively).

So I would go look at how/when the system clock gets set from the
hwclock..

> Then if I run ntpdate 192.168.50.246 (the IP of the AD DC), I am back to the
> correct time:
> hwclock Wed 14 Sep 2016 06:51:06 AM PDT ?-0.302285 seconds
> ?date ?Wed Sep 14 06:51:14 PDT 2016

Sure, because ntp updates the system (runtime) clock.

> ?In ntp.conf and in chrony.conf I have:
>
> ?server 192.168.50.246
>
> ?But it lacks persistence. Chronyd service shows as loaded and active, but
> it's not updating against the DC.

See above -- looks like the initial setting of the system clock isn't
happening from the hwclock.  Most likely this is something from
systemd-timedated.

> ?ed?

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available