[SOLVED] Hardware clock being forced to UTC time

wildwizard · 10-07-2013, 02:44 AM

Quote:

Originally Posted by GazL

This whole area looks like a big mess. Maybe the latest util-linux might help?

Finally got around to testing this (util-linux is not for the faint hearted) and the problem still occurs so it's not solved with that.

volkerdi · 10-07-2013, 03:19 AM

Quote:

Originally Posted by wildwizard

Finally got around to testing this (util-linux is not for the faint hearted) and the problem still occurs so it's not solved with that.

The kernel developers believe that this isn't a problem, and I don't think that util-linux could do anything to change it. Well, that wouldn't be a cheap hack.

So, I'll give you the cheap hack here. What activates this kernel feature is starting ntpd. So, if your hardware clock is not using UTC, add a line to the start section of rc.ntpd so that after ntpd is started, the system clock is saved to the hardware clock:

hwclock --localtime --systohc

After that the kernel won't mess with the hardware clock again.

tux_dude · 10-08-2013, 05:48 PM

Quote:

Originally Posted by volkerdi

The kernel developers believe that this isn't a problem, and I don't think that util-linux could do anything to change it. Well, that wouldn't be a cheap hack.

So, I'll give you the cheap hack here. What activates this kernel feature is starting ntpd. So, if your hardware clock is not using UTC, add a line to the start section of rc.ntpd so that after ntpd is started, the system clock is saved to the hardware clock:

hwclock --localtime --systohc

After that the kernel won't mess with the hardware clock again.

Will this be a standard part of the ntp package?

Here is what I did. I simply copy the entry from rc.0/rc.6 to rc.ntpd to update the hardware clock only if it set to 'localtime'.

Code:

# The kernel is now mocking around with the the hardware clock (wall clock) if
# ntpd is running, so if the hardware clock (wall clock) is set to 'localtime'
# execute hwclock --localtime --systohc to disable the 11 minute mode kernel
# function.
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 (localtime)."
    /sbin/hwclock  $CLOCK_OPT --localtime --systohc
  fi
fi

Patch available if anyone needs it.

volkerdi · 10-08-2013, 05:51 PM

Quote:

Originally Posted by tux_dude

Here is what I did. I simply copy the entry from rc.0/rc.6 and only update the hardware clock if it set to 'localtime'.

I don't think that will help. The problem isn't with the system clock, it's with the hardware clock. If you have a power failure with the hardware clock set wrong, rc.{0,6} won't have a chance to run and your clock will be wrong on reboot.

tux_dude · 10-08-2013, 05:56 PM

I updated my earlier post for clarity. I updated the start section of rc.ntpd as suggested by adding hwclock update from rc.0/rc.6, with minor tweaks.

tux_dude · 10-08-2013, 06:13 PM

rc.ntpd.patch

GazL · 10-10-2013, 01:23 PM

While we're on the subject of the system clock, I believe the clock setting code in rc.S can be simplified significantly with modern kernels and util-linux. The following seems to be all that is needed:

Code:

# Time-warp the system clock to correct for a CMOS/Hardware Clock
# that is running in 'localtime'.  It's just a jump to the left...
echo "Time-warp the system clock: /sbin/hwclock --systz"
/sbin/hwclock --systz
echo "System Time: $(date)"

It appears that on x86 the kernel automatically loads the CMOS clock even without CONFIG_RTC_HCTOSYS.

From what I've read this is particularly desirable to those who run VM instances as hwclock --hctosys calls can be slow in a VM (or so I've read).

Anyway, seems to work for me, but someone with a slightly greater offset from UTC might want to give it a test.

wildwizard · 10-12-2013, 05:29 PM

Quote:

Originally Posted by volkerdi

After that the kernel won't mess with the hardware clock again.

Well after trying this for a few days it seems that that wont even stop it.

tux_dude · 10-16-2013, 08:57 PM

After leaving this for a few days, it seem running hwclock does not disable to 11 minute mode. The only way I found to turn this off was to shut down NTP. IMO, disabling NTP is not an option. I have since removed the rc.ntp patch.

wildwizard · 10-17-2013, 03:02 AM

tux_dude the patch I provided earlier for the kernel does remove the offending code and fixes the problem properly.

This is the way I'm now running and will continue to do so.

GazL · 10-22-2013, 07:34 AM

Do we have a better feel for this yet? In testing my experience was the same as tux_dude: that the rc.ntpd change has had no effect on 11 minute mode. If this code is indeed not making any difference then it's probably best to revert it and strip out some unneeded complexity in the rc.ntpd file.

If the new code is indeed working for some people, then may I suggest a minor reordering for the sake of efficiency in the case that the hardware clock is running UTC.

Code:

--- rc.ntpd.orig        2013-10-22 13:15:07.026378761 +0100
+++ rc.ntpd     2013-10-22 13:19:30.217014427 +0100
@@ -11,13 +11,13 @@
   # ntpd is running, so if the hardware clock (wall clock) is set to
   # 'localtime' execute hwclock --localtime --systohc to disable the
   # 11 minute mode kernel function:
-  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 
+  if ! grep -q "^UTC" /etc/hardwareclock 2> /dev/null ; then 
+    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
       echo "Saving system time to the hardware clock (localtime)."
       /sbin/hwclock  $CLOCK_OPT --localtime --systohc
     fi

tux_dude · 12-06-2013, 11:01 PM

I've conceded, switched my hardware clock on systems not on UPS to UTC.

rusty_car · 01-30-2019, 03:26 PM

I know this is an old thread, however it took me 3 years (yes, YEARS) to finally find the solution. In my case, Mint 18.2. I'm hoping that if someone needs this in the future, they'll find this and it will save them a lot of time...

Short version:

Make sure /etc/adjtime has 'LOCAL' and not 'UTC' (in my case, it was the last line of the file).
Make sure /etc/hardwareclock has 'localtime' in it (in my case, this was a new file and only had that line in it).

Doing the above seems to have turned off the 'NTP synch' flag in the kernel, which keeps the kernel from writing the UTC time into the CMOS clock upon shutdown. So it is highly likely that the kernel won't save the system time in the CMOS clock (I've not verified this). However, the above 2 changes appear to have turned off '11-minute mode'.

Here's the output of 'timedatectl':

rusty@quigon2 ~ $ timedatectl
Local time: Wed 2019-01-30 14:18:53 MST
Universal time: Wed 2019-01-30 21:18:53 UTC
RTC time: Wed 2019-01-30 14:18:50
Time zone: America/Phoenix (MST, -0700)
Network time on: yes
NTP synchronized: no
RTC in local TZ: yes

Warning: The system is configured to read the RTC time in the local time zone.
...blah blah...

(Note the 'NTP synchronized' info in red above).

Make sure you have some way to get time synch from NTP (in my case, every 30 minutes I run rdate (as root, with the slew mode and not the 'jump' mode)).
Make sure you have something setting the CMOS clock to the correct time (again, in my case that 30 minute cron job also runs 'hwclock --systohc')

As I say, I've not verified that I need that cron job yet, you may find out that I've overkilled it badly....

Keywords: 11-minute mode, UTC, localtime, CMOS