On Sat, Oct 19, 2019 at 08:52:05PM +0000, Toby Betts wrote:
> Theo de Raadt wrote:
> > Please show:
> >
> >
> > ntpctl -s all
>
> 5/5 peers valid, 1/1 sensors valid, constraint offset -1571440683s, clock
> unsynced, clock offset is -1571441369829.345ms
>
> peer
> wt tl st next poll offset delay jitter
> 162.159.200.123 time.cloudflare.com
> 1 10 3 12s 33s 87842.951ms 12.481ms 5.154ms
> 13.52.173.55 from pool pool.ntp.org
> 1 10 2 147s 3118s -5.110ms 30.866ms 2.534ms
> 171.66.97.126 from pool pool.ntp.org
> 1 10 2 31s 34s 702718.884ms 29.842ms 2.039ms
> 204.2.134.164 from pool pool.ntp.org
> 1 10 3 7s 34s 702717.855ms 30.802ms 3.925ms
> 52.6.160.3 from pool pool.ntp.org
> 1 10 2 14s 30s 702712.046ms 94.353ms 9.340ms
>
> sensor
> wt gd st next poll offset correction
> hyperv0
> 1 1 0 5s 15s 702687.839ms 0.000ms
> $
>
> I've left this VM running overnight, so it continues to try to adjust
> the time.
>
>
> Toby
>
So it looks like the hyperv0 sensor is giving wrong information occasionally.
As a workaround, you can try to disable the sensor line in ntpd.conf.
After that, set the time to something a bit behind the real time and
reboot. That should give you proper time (in automatic mode, ntpd will
only jump the clock forward).
I like your suggestion to also subject sensors to constrainst, I'll put
in on my todo list.
Having said that, a sensor providing rogue time is bad, so can you
tell more about yout VM host? I might try to reproduce (and fix) the
sensor bug before doing the constraint thing.
-Otto
