NTP System time different from hardware time

Question

on a centos 6.5 server I've just executed ntp with:

service ntpd start

It has fixed system time, but hardware time is still wrong. Is this normal? How can i fix it?

ntpstat reports:

unsynchronized
polling server every 64s

Answer 1

First of all: Hardware time on a Linux system is stored in UTC, so an offset relating to your timezone is to be expected. And yes, this does make problems when dual-booting.

In Addition to that, a Linux system will not always and immediately propagate the NTP time to the RTC ("Hardware clock"), but it should do so at least on shutdown.

Answer 2

It is possible that the NTP is actually correcting the time, but slowly. It normally does that to avoid programs getting worked up about having passed N seconds in a fraction of a second. Many program use the time to order their work internally.

So the clock is change to increment or decrement seconds just slightly, say 0.1 second each second (or even less). It can take a time to get both clocks synced.

Check the time difference and see if it decreases over time.

If the difference persists after an 'orderly' power-off (i.e. a shutdown, not a hardware power-off), the you should check if the system is programmed correctly. In my system, this is done in a command file run at shutdown:

/etc/rc.d/rc.0 contains:

# 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

You can try the command manually: sudo hwclock --systohc. If that doesn't work, you might have a hardware problem.

The importance of having both clocks synced? Depends on which software you are running. The hardware clock is used to set sysclock on startup. Until NTP kicks in, your machine uses that time. Any file used during that lapse is marked with the incorrect time. This could be important for some...

Answer 3

As the existing answers miss the most important fact, I'm telling you: NTP adjusts the system clock (software clock). However adjusting the system clock in Linux does not adjust the hardware clock (Actually I had written a patch about 20 years ago that fixes that issue, but that was never accepted).

What current systems typically do is update the hardware clock from the system time either during clean shutdown, or in a periodic job.

The problem with updating the hardware clock is that the kernel does not know whether the hardware clock is set to local time or to UTC, so it has to apply some unknown offset when updating the hardware clock. The other issue is that Linux had some broken code (I didn't check the last 20 years) to update the hardware clock's minutes and seconds from the system clock if the latter is marked as "synchronized".

The ancient code once was:

     * If we have an externally synchronized Linux clock, then update
     * CMOS clock accordingly every ~11 minutes. Set_rtc_mmss() has to be
     * called as close as possible to 500 ms before the new second starts.
     */
    if ((time_status & STA_UNSYNC) == 0 &&
        xtime.tv_sec > last_rtc_update + 660 &&
        xtime.tv_usec >= 500000 - ((unsigned) tick) / 2 &&
        xtime.tv_usec <= 500000 + ((unsigned) tick) / 2) {
        if (set_rtc_mmss(xtime.tv_sec) == 0)
            last_rtc_update = xtime.tv_sec;
        else
            last_rtc_update = xtime.tv_sec - 600; /* do it again in 60 s */