strange system clock issues

[Joshua Judson Rosen]

Ben Scott <dragonhawk at gmail.com> writes:
>
> On Wed, Aug 26, 2009 at 4:08 PM, Paul Lussier<p.lussier at comcast.net> wrote:
> >
> > After the clock gets about an hour (maybe it's 2) out of sync, ntpd
> > fails to sync and gives up.

Not even--1000 seconds, according to the manpage.

[...]
>   You may be able to compensate by having a cron job fire once per
> minute and run "hwclock --hctosys".  That's a kludge at best, but it
> may be okay for some situations.

Or by shutting down ntpd and instead periodically running ntpdate;
I've done this before, though under different circumstances.

The differences between ntpd's and ntpdate's behaviour, which may or
may not matter in your case, are that ntpd's normal mode of operation
is correcting a slightly-errant clock by *gradually* slewing it to the
correct time (e.g.: via adjtime(); so as to avoid causing time to run
backward or jump forward too quickly, either of which can be
problematic) and intentionally panics if time-disparities get too
wild, while ntpdate will just unconditionally reset the clock to the
right time (which may mean jumping ahead, or jumping backward).

-- 
Don't be afraid to ask (Lf.((Lx.xx) (Lr.f(rr)))).