Re: F8 & F9: Date & Time

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux