From owner-freebsd-hackers Fri Jun 23 05:19:09 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA04410 for hackers-outgoing; Fri, 23 Jun 1995 05:19:09 -0700 Received: from mpp.com (mpp.Minn.Net [204.157.201.242]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id FAA04404 for ; Fri, 23 Jun 1995 05:19:07 -0700 Received: (from mpp@localhost) by mpp.com (8.6.11/8.6.9) id HAA00301; Fri, 23 Jun 1995 07:00:24 -0500 From: Mike Pritchard Message-Id: <199506231200.HAA00301@mpp.com> Subject: Re: Check the date and time at boot To: bde@zeta.org.au (Bruce Evans) Date: Fri, 23 Jun 1995 07:00:24 -0500 (CDT) Cc: hackers@freebsd.org In-Reply-To: <199506230502.PAA25911@godzilla.zeta.org.au> from "Bruce Evans" at Jun 23, 95 03:02:32 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1694 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. 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. 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. -- Mike Pritchard mpp@legarto.minn.net "Go that way. Really fast. If something gets in your way, turn"