Path: utzoo!attcan!uunet!wuarchive!mailrus!umich!terminator!pisa.ifs.umich.edu!rees
From: rees@pisa.ifs.umich.edu (Jim Rees)
Newsgroups: comp.sys.apollo
Subject: Re: Problem with registry date
Message-ID: <1990Aug7.185644.15553@terminator.cc.umich.edu>
Date: 7 Aug 90 18:56:44 GMT
References: <247@rangkom.MY> <1990Aug6.193047.25822@terminator.cc.umich.edu> <9032@ubc-cs.UUCP>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rees@citi.umich.edu (Jim Rees)
Organization: University of Michigan IFS Project
Lines: 37

In article <9032@ubc-cs.UUCP>, pphillip@cs.ubc.ca (Peter Phillips) writes:
  This sounds great.  However, is it really safe to be adjusting the system
  clock time while the machine is running?  The clock is used a seed for
  assigning identifiers (UIDs in Domain/OS parlance (no UNIX UIDs)) to
  objects.  If the clock is set back, two identifiers can coincide causing
  disaster.  I know ntp implementations use adjtime(2) which shouldn't move
  the clock backward at all but the manual page for adjtime(2) in Domain/OS
  is not clear if the use of adjtime is safe.  So, does anyone out there
  with "kernel" knowledge know if running NTP-related time synchronization
  software is safe/reliable on Apollos?

Actually, ntpdate uses adjtime() only if the clock is within some reasonable
threshold of being right (a few seconds?).  If the clock is out of
tolerance, it uses settimeofday() instead.

Turns out that both of these are relatively safe.  You can never get
duplicate uids within a single boot of Domain/OS, because the kernel ensures
that uids are always monotonically increasing regardless of any gyrations in
the time-of-day clock.  The only danger is if the clock is set back so that
it overlaps a previous boot of Domain/OS; for example:

1. set time to 1:00
2. boot Domain/OS
3. shut down
4. set time to 1:00
5. boot Domain/OS

So setting the clock back by less time than you will be shut down is safe.
This is why 'calendar' doesn't complain unless you are setting back by more
than 5 minutes.  In normal operation, xntp won't be adjusting your clock by
more than a few seconds, so no problem.

There may be other problems associated with a vacillating clock.  This
discussion applies to duplicate uids only.

By the way, don't try this at home but I have set node clocks back by an
hour, followed by immediate reboot, without noticing any ill effects.