Messages in this thread |  | | From | Bradley Ward Allen <> | Subject | Re: xntp & 2.0.24 disaster - is anybody listening ? | Date | 05 Nov 1996 08:13:44 -0500 |
| |
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).
|  |