On Tue, Apr 29, 2003 at 04:36:32PM +0100, Gavin Kelman wrote:
We're using rdate to keep our Filer's clock in sync to prevent clock skew errors when compiling things on NFS mounts.
I don't know why this was sent 6 times to the list :(
There seems to be a bug in OnTap 6.3.1R1. The clock works it's way out of sync, (hence why we use rdate), and we get:
Tue Apr 29 15:25:18 BST [Java Thread:notice]: TimeDaemon: Rdate (rfc868) server 'dali.lionbio.co.uk' reports that the time is Tue Apr 29 15:25:21 BST 2003, but the filer thinks the time is Tue Apr 29 15:25:18 BST 2003. This time offset is too large to cause us to modify the time automatically (max allowable skew: 1.000 secs). If the time reported by the time server is correct, set the filer time using the 'date' command.
So, to clear this, I set the time by hand using "date". This works fine and we occasionally see:
Tue Apr 29 16:04:06 BST [Java Thread:info]: TimeDaemon: Time offset within tolerance [dali.lionbio.co.uk]: actual -0.640 secs, tolerance 1.500 secs, not changing time.
And after a time we get the first out-of-sync message. In effect, rdate is doing nothing at all to change the time, as the Max Skew rdate will change over is 1 second, but won't bother changing until it's at least 1.5 seconds out of sync. Surely, this is broken?
options timed.max_skew 30m
will update it to have a skew difference of 30 minutes.
And that should help you.
Type 'options' from the command line to see the different items available.