LinuxQuestions.org - [SOLVED] Hardware clock being forced to UTC time

Page 3 of 3

Show 50 post(s) from this thread on one page

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Hardware clock being forced to UTC time (https://www.linuxquestions.org/questions/slackware-14/hardware-clock-being-forced-to-utc-time-4175477525/)

wildwizard

10-07-2013 02:44 AM

Quote:

Originally Posted by GazL (Post 5040098)

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 (Post 5041339)

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 (Post 5041358)

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 (Post 5042420)

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

Patch...

1 Attachment(s)

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 (Post 5041358)

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

How to force cmos clock to LOCALTIME - at least for me it worked.

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

All times are GMT -5. The time now is 07:04 AM.

Page 3 of 3

Show 50 post(s) from this thread on one page