Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!lll-winken!arisia!sgi!shinobu!odin!bananaPC!ciemo
From: ciemo@bananaPC.sgi.com (Dave Ciemiewicz)
Newsgroups: comp.sys.sgi
Subject: Re: fsck
Message-ID: <1365@odin.SGI.COM>
Date: 10 Nov 89 02:24:20 GMT
References: <89313.153421W0L@PSUVM.BITNET>
Sender: news@odin.SGI.COM
Reply-To: ciemo@bananaPC.sgi.com (Dave Ciemiewicz)
Organization: Silicon Graphics, Inc.
Lines: 38

In article <89313.153421W0L@PSUVM.BITNET>, W0L@PSUVM.BITNET (Bill
Lasher) writes:

> Our most recent problem (the RPC timeout) I think was caused by the way
> we implemented the nightly reboot.  We scheduled them 5 minutes apart,
> figuring that would be enough time.  I found out today that one machine
> was still in the process of restarting when the YP server he was
> communicating with started to reboot.  This caused the system to hang.
> Rebooting did in fact clear things up, but it took some time.  Part of
> the problem is that the time on each machine is not exactly the same (a
> diference of a couple of minutes).  We are going to set all machines to
> the same time, and change the reboot interval to 10 minutes.
>
You might consider running timed on all of your machines which have it.
Timed will average the network time of all other machines on your local
area network which are running timed.  Timed will then make incremental
time adjustments to your machine's time to bring it into line with the
network average.

You can configure your 4D to run timed after rebooting by doing:

	su
	/etc/chkconfig timed on
	exit

You can manually run timed by doing

	su
	timed -M
	exit

This should help prevent the drift problem you are currently seeing.
Unfortunately, if you only have one machine running timed, it won't
do you much good to timed.
 
See the timed manual page for more information.

							--- Ciemo