[13074] in Athena Bugs
Re: [daemon@ATHENA.MIT.EDU : sun4 7.7K: afsd]
daemon@ATHENA.MIT.EDU (jhawk@MIT.EDU)
Wed Jan 4 20:31:20 1995
From: jhawk@MIT.EDU
Date: Wed, 4 Jan 95 20:31:01 -0500
To: cfields@MIT.EDU
Cc: bugs@MIT.EDU, jhawk@MIT.EDU, testers@MIT.EDU, jweiss@MIT.EDU
In-Reply-To: "[2756] in testers"
> > *4*) afsd does not seem to correctly set the time. It
> > should (since it is not invoked with -nosettime) attempt to do so
[...]
> AFS doesn't set the time at all; it only adjusts it, and that in
> finite increments. There's not a bug here. I assume that AFS will
> continue to adjust time as usual on the Sparc 5...
My bug report was claiming that that adjustment was not taking place.
Further testing (setting the time back and leaving it idle for 20 minutes
and observing that afsd does indeed adjust the time) indicates that afsd
does *indeed* set the time forward, so I think it's safe to assume that
(4) was a false alarm, and that the clocks on those 3 sparc 5s were
VERY far off, such that 6 days of continuous afsd adjustments would not
bring it in synch.
However, on a sparc IPX (deathtongue), I observe that
afsd will set the clock forward by VERY large intervals
(I changed the date to February 1993, a date I remember seeing in
last output, and it reset it one jump:
[deathtongue!jhawk] ~# date 0201000092
Sat Feb 1 00:00:00 EST 1992
[deathtongue!jhawk] ~# /bin/athena/fs checks
afs: setting clock ahead 92348890 seconds (via 18.183.0.22 in cell athena.mit.edu).
All servers are running.
[deathtongue!jhawk] ~# date
Wed Jan 4 20:28:18 EST 1995
)
So I suppose there still is a bug, but perhaps only on sparc 5s with large
dates? (?!?!)
This is cc-ed back to bugs as it provides new information on the bug...
--jhawk
