[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bizarre Clock Problem



John Carline wrote:
> 
> Judith Elaine Bush wrote:
> 
> > I have three identical new thin clients with as identical a set-up as i
> > can manage to create -- and one shows this problem. It's particularly
> > annoying as i had the system set to reboot at a certain time every day
> > (mainly to clean up any flakiness from Netscape) -- and the system
> > would set itself 30 minutes or so before the actual time at boot --
> > which meant that it would reboot again 30 minutes later.
> >
> > Ack.
> >
> > I'll check on Monday on the deleting /etc/adjtime solution.
> 
> I tried deleting /etc/adjtime today - it worked.
> 
> I noticed that the system created a new /etc/adjtime file with different numbers
> (system timing adjustments, I guess). Since then, I've booted several times and the
> clock is working fine.
> 
I had a similar problem recently, solved the same way.

It may actually be due to the *documented* behavior of adjtime.  

Suppose that you have rebooted your machine *once* with the time on the
hardware clock off by some large amount.

1. When you noticed it, you used 'hwclock --set' or 'hwclock --systohc'
to set it to the proper time.  At this point, /etc/adjtime would get
written with some huge drift rate.  

2. The next time 'hwclock --adjust' is run, typically at boot, that
drift rate would be applied to set the system clock, probably setting
the clock wrong by some large amount.

Loop back to 1.

The net effect would be having your clock swing back and forth wildly at
each boot.

The moral is, the /etc/adjtime stuff only works right with small drifts,
not large discontinuities introduced by you setting the hardware clock
from the shell.  If you need to change the hardware clock by a lot, it
probably should be done from the BIOS menu.

Actually, the documentation to 'hwclock' mentions that setting large
discontinuities in system time is bad, and this may be one reason why.


Reply to: