LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 10-07-2013, 02:44 AM   #31
wildwizard
Member
 
Registered: Apr 2009
Location: Oz
Distribution: slackware64-14.0
Posts: 868

Rep: Reputation: 265Reputation: 265Reputation: 265

Quote:
Originally Posted by GazL View Post
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.
 
Old 10-07-2013, 03:19 AM   #32
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 1,698

Rep: Reputation: 5267Reputation: 5267Reputation: 5267Reputation: 5267Reputation: 5267Reputation: 5267Reputation: 5267Reputation: 5267Reputation: 5267Reputation: 5267Reputation: 5267
Quote:
Originally Posted by wildwizard View Post
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.
 
4 members found this post helpful.
Old 10-08-2013, 05:48 PM   #33
tux_dude
Member
 
Registered: Dec 2008
Distribution: Slackware64 Current
Posts: 251

Original Poster
Rep: Reputation: 34
Quote:
Originally Posted by volkerdi View Post
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.

Last edited by tux_dude; 10-08-2013 at 05:55 PM.
 
Old 10-08-2013, 05:51 PM   #34
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 1,698

Rep: Reputation: 5267Reputation: 5267Reputation: 5267Reputation: 5267Reputation: 5267Reputation: 5267Reputation: 5267Reputation: 5267Reputation: 5267Reputation: 5267Reputation: 5267
Quote:
Originally Posted by tux_dude View Post
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.
 
Old 10-08-2013, 05:56 PM   #35
tux_dude
Member
 
Registered: Dec 2008
Distribution: Slackware64 Current
Posts: 251

Original Poster
Rep: Reputation: 34
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.
 
Old 10-08-2013, 06:13 PM   #36
tux_dude
Member
 
Registered: Dec 2008
Distribution: Slackware64 Current
Posts: 251

Original Poster
Rep: Reputation: 34
Patch...

rc.ntpd.patch
Attached Files
File Type: txt rc.ntpd.patch.txt (928 Bytes, 36 views)
 
Old 10-10-2013, 01:23 PM   #37
GazL
LQ Guru
 
Registered: May 2008
Posts: 5,021
Blog Entries: 16

Rep: Reputation: 2621Reputation: 2621Reputation: 2621Reputation: 2621Reputation: 2621Reputation: 2621Reputation: 2621Reputation: 2621Reputation: 2621Reputation: 2621Reputation: 2621
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.

Last edited by GazL; 12-11-2014 at 11:43 AM.
 
Old 10-12-2013, 05:29 PM   #38
wildwizard
Member
 
Registered: Apr 2009
Location: Oz
Distribution: slackware64-14.0
Posts: 868

Rep: Reputation: 265Reputation: 265Reputation: 265
Quote:
Originally Posted by volkerdi View Post
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.
 
Old 10-16-2013, 08:57 PM   #39
tux_dude
Member
 
Registered: Dec 2008
Distribution: Slackware64 Current
Posts: 251

Original Poster
Rep: Reputation: 34
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.
 
Old 10-17-2013, 03:02 AM   #40
wildwizard
Member
 
Registered: Apr 2009
Location: Oz
Distribution: slackware64-14.0
Posts: 868

Rep: Reputation: 265Reputation: 265Reputation: 265
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.
 
Old 10-22-2013, 07:34 AM   #41
GazL
LQ Guru
 
Registered: May 2008
Posts: 5,021
Blog Entries: 16

Rep: Reputation: 2621Reputation: 2621Reputation: 2621Reputation: 2621Reputation: 2621Reputation: 2621Reputation: 2621Reputation: 2621Reputation: 2621Reputation: 2621Reputation: 2621
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
 
1 members found this post helpful.
Old 12-06-2013, 11:01 PM   #42
tux_dude
Member
 
Registered: Dec 2008
Distribution: Slackware64 Current
Posts: 251

Original Poster
Rep: Reputation: 34
I've conceded, switched my hardware clock on systems not on UPS to UTC.
 
1 members found this post helpful.
Old 01-30-2019, 03:26 PM   #43
rusty_car
LQ Newbie
 
Registered: Jan 2019
Posts: 1

Rep: Reputation: Disabled
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
 
  


Reply

Tags
bios clock, clock, hardware clock, time, utc


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Clock on wrong time (system clock is set to UTC) yanom Debian 6 07-26-2011 11:26 AM
hardware clock time differs from system time after setting maxgsp Linux - Software 2 02-28-2009 07:15 AM
hardware clock time differs from system time after setting maxgsp Linux - Hardware 1 02-27-2009 05:24 AM
Benefit of NOT using UTC on the hardware clock? daihard Linux - General 1 02-09-2008 09:16 AM
Where does RH8 daily set system time to hardware clock time smartnorman Red Hat 1 05-24-2006 02:42 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 02:55 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration