[1086] in Athena Bugs

home help back first fref pref prev next nref lref last post

re: possible clock bug

daemon@ATHENA.MIT.EDU (geer@ATHENA.MIT.EDU)
Fri Sep 30 11:06:03 1988

From: <geer@ATHENA.MIT.EDU>
To: bugs@ATHENA.MIT.EDU
Date: Fri, 30 Sep 88 11:05:47 EDT
in the following messages, one to me, one to jerry,
one to hotline, i think there is a valid question
raised as to whether there is a problem with clocks
that is software related.

--dan


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\


------- Forwarded Message

Date: Wed, 28 Sep 88 17:28:47 EDT
To: geer@ATHENA.MIT.EDU
Subject:  possible clock bug
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>

The message below, from Tom Coppeto, is the tail end of a string of
messages which began with a proposal from him for adding a
cron-triggered daily warping of the clock on all workstations.
Pushing back, I found the motivation was that he had recently
encountered several 6.0 workstations that were getting
expired-authenticator errors, and that resetting the clock with
gettime generally fixed the problem.  So he wanted to make it a
standard procedure.

Warping clocks around tends to screw up UNIX, so the idea isn't a
good one.  But it may be that the right way to look at this is as a
bug report.

I tried to find out whether there was a common server whose clock was
way out of line, but the question almost got lost in the noise; Tom
apparently didn't understand why it mattered.

But looking over the list of different workstations that he had
trouble with, I wonder if we have a bug in the 6.0C kernel that is
causing the VS clocks to lose time.  The average workstation clock
should keep time as well as a quartz watch, which means that it
should really be quite unusual to find one that is 5 minutes off so
soon after the release, which guaranteed that every machine's clock
was properly set the first week of September.  It might be
interesting if someone in sysdev checked all the clocks in W20, say,
to see how far (and in what direction) they have drifted since last
reboot.

  ----- Begin Forwarded Message -----
  
  From tjcoppet@ATHENA.MIT.EDU  Sat Sep 17 15:14:54 1988
  Subject: Re: workstation time out of bounds wrt Kerberos
  From: Tom Coppeto <tjcoppet@ATHENA.MIT.EDU>
  
  I noticed the problem with bldg. 11 machines when attaching from aphrodite.
  I noticed picasso (was just rebooted a week before) was off when doing a
  msgchk (e40-po). I do not recall how I noticed the bldg 66. machine was
  off. Carla had mentioned to me (in passing) that she encountered two users
  in the past week whose machine clocks were off. Maybe she can supply more
  information.
  
  If you like I can inform consultants to take note of the particular server
  (if any) that may be at fault if this should arise again.
  
  ------- End of Forwarded Message


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\


[2749] daemon@TELECOM.MIT.EDU  Hotline  09/29/88 14:42 (11 lines)
Subject: clock needs adjustment:  M66-080-24
From: <brlewis@ATHENA.MIT.EDU>
To: hotline@ATHENA.MIT.EDU

Having been up only 12 days, the clock was off by almost 7 minutes.
This made kerberos tickets invalid, so NFS lockers could not be
attached.

Bruce

--[2749]--


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\


home help back first fref pref prev next nref lref last post