Here's a nice, confusing little treatise about time... well, about keeping time.
You have two clocks: the hardware clock and the software clock. The hardware clock is a chip (or part of a chip) on your motherboard kept running by the CMOS battery when the system is powered off (some motherboards will keep it running if the system is plugged in and turned off; I have a couple of those). The system clock is software managed by the kernel with interrupts (pretty much).
When Slackware boots, the hardware clock is read by some code in
/etc/rc.d/rc.S:
Code:
# Set the system time from the hardware clock using hwclock --hctosys.
if [ -x /sbin/hwclock ]; then
# Check for a broken motherboard RTC clock (where ioports for rtc are
# unknown) to prevent hwclock causing a hang:
if ! grep -q -w rtc /proc/ioports ; then
CLOCK_OPT="--directisa"
fi
if grep -wq "^UTC" /etc/hardwareclock ; then
echo -n "Setting system time from the hardware clock (UTC): "
/sbin/hwclock $CLOCK_OPT --utc --hctosys
else
echo -n "Setting system time from the hardware clock (localtime): "
/sbin/hwclock $CLOCK_OPT --localtime --hctosys
fi
date
fi
Note that the above looks at
/etc/hardwareclock to see if the hardware clock is UTC or local time and acts accordingly. A hardware clock running UTC looks like this:
Code:
cat /etc/hardwareclock
# /etc/hardwareclock
#
# Tells how the hardware clock time is stored.
# You should run timeconfig to edit this file.
UTC
You're in the central time zone in North America? OK, that's six hours difference from UTC during standard time and five hours from UTC in daylight time; that "difference" is X hours less than UTC.
For example, I'm in the eastern time zone, daylight time is in effect and my local time is four hours less than UTC (it's five hours when standard time is in effect):
Code:
date
Sat Aug 2 12:45:29 EDT 2014
date -u
Sat Aug 2 16:45:36 UTC 2014
Now, NTP, when synchronized, keeps your system clock on time (it doesn't mess with the hardware clock).
As during start up -- boot -- when the system is shut down
/etc/rc.0 has code to save the system time to the hardware clock:
Code:
# Save the system time to the hardware clock using hwclock --systohc.
if [ -x /sbin/hwclock ]; then
# Check for a broken motherboard RTC clock (where ioports for rtc are
# unknown) to prevent hwclock causing a hang:
if ! grep -q -w rtc /proc/ioports ; then
CLOCK_OPT="--directisa"
fi
if grep -q "^UTC" /etc/hardwareclock 2> /dev/null ; then
echo "Saving system time to the hardware clock (UTC)."
/sbin/hwclock $CLOCK_OPT --utc --systohc
else
echo "Saving system time to the hardware clock (localtime)."
/sbin/hwclock $CLOCK_OPT --localtime --systohc
fi
fi
Note that both
/etc/rc.0 and
/etc/rc.S check to see how the hardware clock is set, either UTC or local time, to write the "correct" value to the hardware clock.
If you're just rebooting, all that writing to the hardware clock is done by
/etc/rc.d/rc.6 but the reading from the hardware clock and setting of the system clock is the same (handled by
/etc/rc.d/rc.S).
Should you keep your hardware clock on UTC? Well, yeah, you probably ought to (there's some movement afoot in kernel development to default all hardware clocks to UTC and be done with it -- hasn't happened yet but it just might so why fool around).
NTP will keep your system clock on time (they're notorious for drifting all over the place). You configuration looks pretty much OK, but I'd recommend that you only use three servers and delete the
iburst from them (they're not really necessary).
You need to be root do the following.
Others have recommended that you run
timeconfig, setting your hardware clock to UTC and picking the correct time zone, which would be US central time. Yup, do that (be sure and stop NTPD first).
The
ntpdate utility is depreciated and you should use
ntpd instead to set the system time correctly:
That will use the servers you have defined in
/etc/ntp.conf to set the system time (it will pick the best one) and exit.
Then you set the hardware clock:
(the above is from @astrogeek's post).
That should do it.
You can start NTPD, wait about 5-10 minutes and run
Code:
/usr/sbin/ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
127.127.1.0 .LOCL. 10 l 5h 64 0 0.000 0.000 0.000
+69.50.219.51 173.44.32.10 3 u 197 1024 377 648.346 71.386 81.450
*199.102.46.75 .GPS. 1 u 278 1024 377 662.432 76.805 74.333
+209.118.204.201 10.55.5.56 2 u 154 1024 377 728.621 57.467 125.183
(you use
-pn so you're not going through DNS to get the addresses).
When you see a display like this, with the + and *, you're synchronized and you'll stay that way (the one with the asterisk is the external server you're synchronized to).
When you reboot or shut down, the correct time will be written to the hardware clock (then read from the hardware clock to set the software clock on the next boot). If that time drifts, you most likely have a bad battery (hey, it happens that you buy a new battery that's no good you know). You can check the next time you start the box from powered off by entering the BIOS (or UEFI) and see what time it is -- it should not have drifted more than 1,000 seconds even if powered off for a week or two.
Over time, NTPD will "walk" your system clock into synchronization by using the drift value found in
/etc/ntp/drift and keep it there; it takes a while for that to happen (like days, sometime a week or two) but it will get there if you leave the system running 24/7.
Anyway, hop this helps some.
