I guess this is why it would be good to specify what version of Linux is involved. I am using RedHat. We install from a local server with some customizations, but I believe that the code I am about to show is standard RedHat....

On the way up the system clock is synced in /etc/rc.d/rc.sysinit via:

Code:

[ -x /sbin/hwclock ] && /sbin/hwclock $CLOCKFLAGS

On the way down there seems to be two opportunities to sync in the other direction:

Code:

# cd /etc/init.d
# grep hwclock *
halt:[ -x /sbin/hwclock ] && action $"Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
ntpd:sync_hwclock() {
ntpd:   action $"Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
ntpd:           [ "$SYNC_HWCLOCK" = "yes" ] && sync_hwclock
#

I would be very surprised in some distro moved this into the kernel. But then again I am frequently very surprised.

And while we are discussing Linux NTP configurations, our standard /etc/ntp.conf came with this abomination:

Code:

# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. The
# default stratum is usually 3, but in this case we elect to use stratum
# 0. Since the server line does not have the prefer keyword, this driver
# is never used for synchronization, unless no other other
# synchronization source is available. In case the local host is
# controlled by some external source, such as an external oscillator or
# another protocol, the prefer keyword would cause the local host to
# disregard all other synchronization sources, unless the kernel
# modifications are in use and declare an unsynchronized condition.
#
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

I wonder how widespread that is. That is a very bad idea. Undisciplined means that NTP keeps its hands off the system clock. It was intended for use on a system where the system clock is being disciplined by other software which has comminication with a very accurate clock. Also, as a kludge, it is suggested that with a cluster of computers with no way to contact a real NTP server, you could pick a system with a relatively accurate local clock, make it an NTP server, set the time and best you can, and use the above code to syncronize all the systems to your selected clock.

We were recently devestated by this collection of misfeatures. Our NTP server had all of these configuration settings. It locked up. I could not ssh in or access via the system console. It was no longer providing NTP service. So I rebooted it. It came right back up with no problems. It synced the system clock to the bios clock. But are now in EDT and bios clock still had EST, so the system time was off by one hour. NTP started and the NTP server contacted our master NTP server which is an appliance that gets its time fro the GPS satellites. When NTP first contacts an NTP server it does not instantly believe it. It takes several contacts over the space of several minutes to insure the NTP server is self-consistent before it will be accepted as a truechimer. Meanwhile the local clock is immediately accepted and selected as the primary peer. Now our NTP server sent out the wrong time to our entire campus. Other sites continued to have the correct time. Things went downhill pretty fast.