From owner-freebsd-hackers  Fri Jun 23 10:21:36 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id KAA17491
          for hackers-outgoing; Fri, 23 Jun 1995 10:21:36 -0700
Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA17485
          for <hackers@freebsd.org>; Fri, 23 Jun 1995 10:21:31 -0700
Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id KAA10860; Fri, 23 Jun 1995 10:20:43 -0700
From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
Message-Id: <199506231720.KAA10860@gndrsh.aac.dev.com>
Subject: Re: Check the date and time at boot
To: mpp@legarto.minn.net (Mike Pritchard)
Date: Fri, 23 Jun 1995 10:20:43 -0700 (PDT)
Cc: bde@zeta.org.au, hackers@freebsd.org
In-Reply-To: <199506231200.HAA00301@mpp.com> from "Mike Pritchard" at Jun 23, 95 07:00:24 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2416      
Sender: hackers-owner@freebsd.org
Precedence: bulk

> 
> > >What I did was write a small program to check/record the system
> > >date in a file in the root file system.  At boot time, the
> > 
> > Use the timestamp in the super block of the root file system.
> > 
> > Bruce
> 
> I would rather not.  What happens if I boot single user after
> some type of maintenance (likely after fiddling with CMOS settings) 
> and mount the root file system rw and make changes?  I've now updated the 
> super-block timestamp, and anything in /etc/rc will never detect that 
> the date may be be off when the system is booted multi-user.  I've seen 
> this exact same situation on another Unix system I used to manage that 
> was checking the super-block time, and we re-did the program to use its 
> own data file for just this reason.   
> 
> Plus, running the update program once an hour on its own data file lets 
> it check that the clock has stayed sane since the last run.  If the
> clock gets corrupted while the system is running, the super-block 
> timestamp will now track this bogus time and thus be undetectable
> by /etc/rc.

Won't this cron job get just as confused since it is scheduled by cron
who uses the system time for scheduling jobs.  If I recall correctly
cron does some really strange things when the system time is changed
radically with respect to scheduling jobs.
 
> Also, do we support NFS mounted root file systems for diskless
> machines?  If so, then this is another reason why the super-block 
> timestamp couldn't be used.

Now that is a good point!   But diskless clients should ask the
server for the time IMHO anyway.  If you running diskless machines
there is not really an argument that you don't have good network
connections.  (At least between the server and the client, make the
server the master time keeper for the site).

> Re: Rod's comments
> 
> As some other people have already pointed out, not everyone is
> connected to the net, or has a reliable enough connection to
> depend on ntpdate & friends to fix the time at boot time if it is 
> in error.  Even if you do have a good connection, network problems 
> may prevent the time programs from correcting the date until long
> after the system has been up and running for a while.

I have already responded on that point.


-- 
Rod Grimes                                      rgrimes@gndrsh.aac.dev.com
Accurate Automation Company                 Reliable computers for FreeBSD