The Thursday 2003-12-04 at 22:15 -0600, Donn aka n5xwb Washburn wrote:
Well I have zeroed the /etc/adjtime
Simply delete it.
and made sure the last line was set to localtime before I shutdown this machine.
Almost useless. The file is recreated on certain circumstances; for example, if you delete it, the '/etc/init.d/boot.clock' will recreate it this way: echo -n Setting up the CMOS clock test -f /etc/adjtime || echo "0.0 0 0.0" > /etc/adjtime /sbin/hwclock --adjust $HWCLOCK rc_status /sbin/hwclock --hctosys $HWCLOCK rc_status rc_status -v -r The variable $HWCLOCK is defined in '/etc/sysconfig/clock', and that is the place to define UTC or local time. I have as UTC, thus: # Set to "-u" if your system clock is set to UTC, and to "--localtime" # if your clock runs that way. # HWCLOCK="-u" So, simply deleting the '/etc/adjtime' file will recreate it correctly next time you boot. And, when you power off, the script '/etc/init.d/halt' executes this: if test "$HWCLOCK_ACCESS" != "no" ; then if rc_active xntpd ; then echo -n "Set Hardware Clock to the current System Time" # write back to hardware clock and calculate adjtime /sbin/hwclock --systohc $HWCLOCK rc_status -v -r fi fi (rc_active is a function that tests for the existence of the given script on any runlevel) Meaning: if the network time daemon was set to be activated (and therefore, the clock can be assumed to be correct) the system time is copied to the CMOS clock.
I set the time with "netdate navobs1.wustl.edu now.cis.okstate.edu"
The SuSE way is "rcxntpd ntptimeset" - you only need to put the servers in '/etc/ntp.conf' for it to work.
and then ran "/sbin/hwclock --adjust --localtime ; hwclock --systohc"
Correct... :-? Well, no, not the adjust, see below. But ensure you have 'HWCLOCK="-u"' in '/etc/sysconfig/clock'.
I just got home and fired this system up and the time/date is 22:02 PM 12/04/2003. However, "date" shows Thu Dec 4 16:02:12 CST 2003.
Who says it is 22.02? Kde perhaps? That is a very different problem, ignore it. The "date" command is the important one. It appears to be the UTC time. Notice that "netdate" adjusts to UTC time, but it knows what is the difference between your local time and UTC, so there should be no problem.
I just ran both of the above commands and now the time is Thu Dec 4 22:04:39 CST 2003
It is a screwed up /etc/init.d file that is causing the problem. /etc/adjtime and/or /etc/localtime is the result of the headache. This only happens at bootup so it must be a boot script problem.
Something like "date -u" would cause the problem because it is 6 hours wrong every boot time. So, reboot in one day 4 times and the DAY will even be wrong.
Ok, try this. Ensure the HWCLOCK variable is correct, and that your system is set to the proper timezone. Delete the adjtime file and reboot when you like. Enter the Bios, and adjust the clock there (this is the safest way, or at least, most intuitive). Continue booting (that day, the next, doesn't matter). Then use the adjusting procedure you used: rcxntpd ntptimeset hwclock --systohc skipping the --adjust, because the boot script did it for us, and, most important, because it will adjust the CMOS clock by what it assumes will have drifted - and thus undoing the network time adjust. That option is meant (IMO) to be used when not having a network clock for reference. In other words. When you are booting up, the line: /sbin/hwclock --adjust $HWCLOCK corrects the CMOS clock by the amount stored in '/etc/adjtime'. Then the line: /sbin/hwclock --hctosys $HWCLOCK copies the CMOS clock to the system. Thus, you should not use "--adjust" after adjusting the clock with a network reference: you compound the error. If the clock is updated by six hours, and you do it improperly, that may be stored in the adjtime file... Mmmm... I don't know if I manage to explain it, or to muddle it up more for you - it's late here O:-) -- Cheers, Carlos Robinson