lkml.org 
[lkml]   [1996]   [Nov]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: xntp & 2.0.24 disaster - is anybody listening ?
Date
Short version:
maybe "clock -w"??

Long version:
You may have been bit by Bill Gates on this one, like I was, as well.
Here I thought that "local time" was all well thought out: think
again. If you can, run your CMOS clock in Universal Time, all will be
much easier between boots. Computers are meant to run in (a)
Universal Time. (In RFC822 date timezone format, that's Z, +0000, or UT.)

In a RedHat environment (the part of my system that deals with this is
from RedHat), /etc/sysconfig/clock has CLOCKMODE=LOCAL or
CLOCKMODE=GMT. Well, since GMT is a misnomer and it is more correct
to say "UT", I enhanced it, put CLOCKMODE=UT, and made sure the code
in /etc/rc.d/rc.sysinit was correct: ("rpm -qf /etc/rc.d/rc.sysinit"
says initscripts-2.52-1, and I've changed them a lot:)

# Set the system clock.
echo -n "Setting clock: "
. /etc/sysconfig/clock
if [ ${CLOCKMODE} = "GMT" -o ${CLOCKMODE} = "UT" ]; then
clock -u -a
else
if [ ${CLOCKMODE} = "ARC" ]; then
clock -A -a
else
clock -a
fi
fi
date

Note the extra bit in the fourth line:
-o ${CLOCKMODE} = "UT"

Then, you have to go in, kill off xntpd, do a "ntpdate -b
cesium.clock.org apple.com tick.usno.navy.mil dns.cit.cornell.edu"
until the time is correct, then a "clock -u -w" to write the UT into
the clock. I then rebooted to clear the computer of the aura of
Micro****, but that wasn't necessary.

My xntpd is running fine (kernel 2.0.24). Unfortunately I can't take
advantage of 2.1's eventual better support for NTP for a while as I
want to run stable (i.e., 2.0.25+) (to give myself peace of mind) for
some time. But I still beat the socks off of any other clock I have
access to.

While in the shower, I thought about all this, and there really isn't
much of a way to fix this if your computer has to be in Local Time
Zone and you are going to boot across a time zone change at all
without doing the "clock -u -w" (even if it's in a shutdown script,
what if the machine froze solid?). There are ways the kernel could
make it less likely for this event, but unless a great amount of state
is kept (on disk, bletch, unless all CMOS clocks have an extra bit to
spare), there's almost no way to get it right if the machine was shut
down during reboot. I'd much rather pretend to be in the UK while
using MicroSoft than have to worry about my time going balistic
whenever I reboot across a time zone change. You should get a
seperate computer for your NTOS anyway and not worry about your
Micro**** partitions sharing with Linux, IMO.

Of course, my (Linux software) time zone changed without a flaw, and
exactly as it was supposed to, before the boot, as Unix has for some
time now, so while some who are used to setting clocks whenever the
time zone moves, for me who has not had to pay a single mind to this
matter since over a decade ago, it is absolutely ludicrous to suddenly
have to be re-introduced to it because of some assenine inferiority
imposed by some monolithic mostrosity of a corporation. Hopefully,
they'll fix their bug in their software, too, though (really, that's
how I feel).

\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.392 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site