Daniel B. Thurman wrote, On 08/01/2008 12:30 PM:
i386 (i686)
In F8, on every reboot, the date and/or time settings get really
messed up. I am not allowed to set the 'adjust Date & Time'
settings via the "tool" (upper-right corner) even when I log
in as root - the Calendar/Time dialog is greyed-out, meaning
it is not available so I have to resort to the date command-line
setting to get it right. Even tho, a reboot screws it up all over
again. The screwed up date/time setting is not fixed via the
ntp setting I think because it is so far out of date/time?
In F9, same as in F8, except that I am allowed to set the date/time
via the GUI interface.
What gives?
Assuming your hardware clock is working REASONABLY, i.e., battery backed
quartz accuracy and it is not so old a BIOS that it jumps back years[4].
<WarmButton>
You've hit an area that has bugged me for years with RH and Fedora (actually I
think ALL distro's do this), but I have not had/taken the time to properly
document and submit a patch.
Summary: A) syncing the hardware clock from the system clock when the system
clock sync with real time state is unknown is a bad thing. B) rewriting
/etc/adjtime[0] with data that has been confused by running ntpd is not good.
issue with (A): even if the clock has been set by the admin during this
uptime, use of the computer IO interfaces can make the system clock drift
quite radically, i.e., by seconds per hour[1]. The system clock can not be
trusted to be a reliable source of time longer than the ADMIN of the machine
knows about.
issue with (B): because of some code in the kernel, every 11 minutes while
ntpd has declared the system in sync, the hardware clock is set to the system
clock. This is OK in a machine that is always up, or ALWAYS on a network with
a decent time server available. If on the other hand you are operating a
laptop that moves from network to network or network to stand alone for long
periods of time, then when the halt script drives the (ntp good) time to the
hardware clock the /etc/adjtime data will have the hardware clock's drift
zero'ed out.
What should be done:
1) When the system boots:
read hardware clock to system clock (done already in current config)
hwclock --adjust (new)
read hardware clock to system clock (new [3])
[if ntpd service is running]
ntpdate (done already in current
/etc/rc.d/init.d/ntpd)
#immediately after a _successful_ ntpdate
hwclock --systohc ( [2] done already in current
/etc/rc.d/init.d/ntpd)
3) When the system is shutdown:
[if ntpd service is *NOT* running]
DON'T MESS WITH THE HWCLOCK!
[if ntpd service is running]
#either determine that the system has been in
#sync for the last 11 minutes or
#use a _successful_ ntpdate[2].
##grab the good /etc/adjtime data
hwclock --systohc
##replace the bogus drift data in the
## new /etc/adjtime with the reasonable
## drift data from the old /etc/adjtime
On, one of my home systems I had built up the scripting in halt to do the
above, but I have not had time to even play with that system for a while.
On most of my systems I just beat halt into submission with:
--- /etc/rc.d/init.d/halt 2007/10/08 19:18:54 1.1
+++ /etc/rc.d/init.d/halt 2007/12/03 21:23:43
@@ -126,7 +126,10 @@
;;
esac
-[ -x /sbin/hwclock ] && action $"Syncing hardware clock to system time"
/sbin/hwclock $CLOCKFLAGS
+#the system time should only be synced to the hardware clock
+#when the admin KNOWS they set the time correctly or when NTP knows
+#it set the time correctly.
+#[ -x /sbin/hwclock ] && action $"Syncing hardware clock to system time"
/sbin/hwclock $CLOCKFLAGS
# Try to unmount tmpfs filesystems to avoid swapping them in. Ignore
failures. tmpfs=$(awk '$2 ~ /^\/($|proc|dev)/ { next; }
</WarmButton>
[0] man hwclock
read the "The Adjust Function" section for the format of the file.
[1] I have used a laptop with a PCMCIA network interface and it would drift by
10's of seconds per hour when the network was being used heavily. NTP even
had trouble (multiple syncs per hour) keeping it synced when the network was
in use.
[2] we know that immediately after a _successful_ ntpdate the system has
EXCELLENT time, so using it is OK. If this was the only time that the HW clock
was being messed with, we would have very good drift data in /etc/adjtime to
adjust the clock with in the future.
[3] if NTP is not being used, and a reasonable /etc/adjtime exists, AND the
halt script is not messing with the hardware clock, I have seen the
/etc/adjtime drift data keep a computer within 10 seconds per year.
[4] man hwclock
read the info with the --badyear option.
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
