LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
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 04-16-2014, 04:38 PM   #1
slack_
Member
 
Registered: Oct 2013
Distribution: Slackware, Arch
Posts: 101

Rep: Reputation: Disabled
BIOS clock, localtime, and UTC are all incorrect


What am I supposed to do if my system localtime, and the system UTC are both incorrect? I check hwclock --utc and hwclock --localtime and both of them are off. The BIOS clock is incorrect as well.

I've never had such massively skewed time issues before. I am not running a dual-boot.
 
Old 04-16-2014, 04:54 PM   #2
moisespedro
Senior Member
 
Registered: Nov 2013
Location: Brazil
Distribution: Slackware
Posts: 1,140

Rep: Reputation: 152Reputation: 152
I assume you can go on the BIOS settings and adjust it?
 
Old 04-16-2014, 05:24 PM   #3
jtsn
Member
 
Registered: Sep 2011
Location: Europe
Distribution: Slackware
Posts: 908

Rep: Reputation: 447Reputation: 447Reputation: 447Reputation: 447Reputation: 447
Quote:
Originally Posted by slack_ View Post
What am I supposed to do if my system localtime, and the system UTC are both incorrect?
You set up NTP time synchronisation and solve that problem forever.
 
Old 04-16-2014, 05:25 PM   #4
turtlebay777
Member
 
Registered: Apr 2014
Posts: 39

Rep: Reputation: 3
It's a symptom of a dead CMOS battery, replace it, they only cost a couple of pounds or dollars.
 
Old 04-17-2014, 10:16 AM   #5
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,121

Rep: Reputation: 819Reputation: 819Reputation: 819Reputation: 819Reputation: 819Reputation: 819Reputation: 819
When you ran timeconfig (during installation of Slackware), you selected your local time zone and whether your hardware clock was UTC or local time; you really want the hardware clock to be UTC.

The way Slackware does things is that when the system is booted the hardware clock is read and that value is used to set the system clock (which is software). When the system is shut down, the system clock value is written to the hardware clock; the CMOS battery, mentioned above) keeps the hardware clock ticking while the system is powered off. The time is set relative to UTC, taking into account your time zone (set when you installed the system); the switch from standard time to daylight time happens based on your time zone setting (so make sure that's correct, perhaps by, as root, executing /usr/sbin/timeconfig).

So, how to keep them on time? Simple, enable NTPD, the Network Time Protocol daemon (you have it, you just need to a little configuration).

There is file, /etc/ntp.conf that you need to edit; you need to add a few lines.

Out of the box, /etc/ntp.conf looks like this at the top of the file:
Code:
<bunch of line of description>
# modifications are in use and declare an unsynchronized condition.
#
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

#
# NTP server (list one or more) to synchronize with:
server pool.ntp.org iburst
You want to make it look like this -- you need to be root to do this:
Code:
# modifications are in use and declare an unsynchronized condition.
#
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

#
# NTP server (list one or more) to synchronize with:
#server pool.ntp.org iburst
server  0.us.pool.ntp.org
server  1.us.pool.ntp.org
server  2.us.pool.ntp.org
If you're not in the US, use the two character country code for where you live in those three lines; be sure to comment-out the server pool.ntp.org iburst line as above.

Then, enable the NTP daemon so it will start and stop at book and shutdown:
Code:
chmod 755 /etc/rc.d/rc.ntpd
Your system clock needs to be close to "real time," so adjust it if necessary with the date command, get it within a minute or two of the actual time.

Then, start the daemon with
Code:
/etc/rc.d/rc.ntpd start
That will, after, oh, three- to five minutes synchronize your system clock to the correct time. Check that you're synchronized with
Code:
/usr/sbin/ntpq -pn
The display from that will look a lot like this:
Code:
/usr/sbin/ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l   4d   64    0    0.000    0.000   0.000
+108.61.73.244   132.163.4.102    2 u  185 1024  377  709.688   69.374 146.561
*72.14.183.239   216.218.254.202  2 u  366 1024  377  640.947   38.063 140.359
+162.243.243.206 216.218.192.202  2 u  280 1024  377  620.094   -0.390  79.404
The asterisk on one of the servers indicates that you are synchronized; the plus signs indicate that there are two candidates for synchronization if the one you are synchronized to goes away, gets noisy or otherwise is unusable.

The LOCL is there for when your Internet connection goes away for whatever reason. When that happens, NTPD will synchronized to itself, to the system clock, until the Internet connection comes back and it will then synchronize to an external time source.

Once you have your system clock synchronized, reboot. That will write the correct time to the hardware clock on shutdown and read it back to the system clock on reboot, NTPD will start, a few minutes later it will synchronize to one of the three pool servers and will keep both your system clock and hardware clock synchronized to the correct time.

If your system is shut down for an extended period, say, overnight and when it boots the time is way off, that's an indication the the CMOS battery need replacing -- they're typically good for about three to five years, may more, maybe less. As mentioned above, they're cheap and easy to replace (they look like a sliver coin in a holder on your motherboard).

There is a depreciated utility (nptdate) you can use to do a one-time setting of the clock (before you start the NTP daemon). It is depreciated and you shouldn't count on it being there in future upgrade of the NTP software:
Code:
ntpdate pool.ntp.org
Hope this helps some.
 
1 members found this post helpful.
Old 04-17-2014, 03:47 PM   #6
slack_
Member
 
Registered: Oct 2013
Distribution: Slackware, Arch
Posts: 101

Original Poster
Rep: Reputation: Disabled
Thanks very much for all that info. I've gotten up to the part where I run: /usr/sbin/ntpq -pn. However, it's been well over five minutes and the request just keeps timing out and saying nothing receieved. I am able to ping all of the servers, but I cannot receive any information from them when running that command.

EDIT: Herm... for some reason the lo interface was down by default. Once I brought it up the ntpq command worked just fine, and my time is correct on reboot. Thanks very much this was starting to look like a major headache. Now, I just need to hope that tommorrow all is fine and I don't need a new CMOS chip. I was thinking though, even if the CMOS chip is dead, wouldn't running ntp at boot sync to the servers anyway? How exactly does that work? At the very least I could write a script to automate what I just did at boot right?

Last edited by slack_; 04-17-2014 at 04:34 PM.
 
Old 04-17-2014, 06:12 PM   #7
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,121

Rep: Reputation: 819Reputation: 819Reputation: 819Reputation: 819Reputation: 819Reputation: 819Reputation: 819
The CMOS battery (it's not a chip) keep the hardware clock running (along, sometimes, some other other things). When you boot and NTPD starts, power is available everywhere and the system clock (which is software, not a clock chip like the hardware clock is) will get set to the correct time. NPTD periodically also keeps the hardware clock and system clock in synchronization. As long as the power is on, things stay that way.

You don't need to write a script to do anything, that's what NTP is for. There should be no reason that lo goes down (or even matters once NTPD is started at boot time). The local interface is just for a fall back if the Internet is not available -- was your Internet connection running at boot time or do you manually connect (dial-up, wi-fi, whatever)?

Hope this helps some.
 
Old 04-17-2014, 09:33 PM   #8
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.1
Posts: 1,578

Rep: Reputation: 468Reputation: 468Reputation: 468Reputation: 468Reputation: 468
Actually, I can't think of a reason for the lo interface to not be available.

(Good God, that's a horrible way to say it. How about "I think that the lo interface should always be available."?)
 
Old 04-17-2014, 09:59 PM   #9
pcninja
LQ Newbie
 
Registered: Oct 2013
Distribution: Slackware
Posts: 14

Rep: Reputation: Disabled
for me ntp never works in slackware. It doesn't matter if it is UTC or localtime, it just doesn't work ever.
 
Old 04-17-2014, 10:25 PM   #10
slack_
Member
 
Registered: Oct 2013
Distribution: Slackware, Arch
Posts: 101

Original Poster
Rep: Reputation: Disabled
I use wpa_supplicant and enable dhcp on boot with /etc/rc.local. So my internet connection is up when it boots. The ntpq command was timing out until I realized that running ifconfig only showed the wlan0 interface, and once I brought lo up the ntpq command worked just fine. Time is almost exactly syncronized now(my computer is a handful of seconds off from my phone), hopefully that doesn't become too much of a problem.

Sorry if I'm being thick, but if ntpd is configured and working properly(which it is) then time should be correct tommorrow morning regardless of if my CMOS battery is dead or not correct?

Thanks.
 
Old 04-18-2014, 09:10 AM   #11
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,121

Rep: Reputation: 819Reputation: 819Reputation: 819Reputation: 819Reputation: 819Reputation: 819Reputation: 819
Quote:
Originally Posted by slack_ View Post
Sorry if I'm being thick, but if ntpd is configured and working properly(which it is) then time should be correct tommorrow morning regardless of if my CMOS battery is dead or not correct?
Yup (as long as you didn't shut it down overnight and the CMOS battery is not dead). You're not being thick, NTP fall into the class of weird science now and again.

NTP does a little magic for you. If you look in /etc/ntp there will be a file there, named drift with a numeric value stored in it that represents the amount of drift of your software clock from the external time source. NTP will walk your software/system clock into synchronization over time, might be a few hours, may be a couple of days, but it will get there. It will also, once in a while, update your hardware clock to bring it into synchronization.

As previously mentioned, when you shut the system down the system time is written to the hardware clock and, when the system is powered back on, the software clock is initialized from the hardware clock (which is why that battery is kind of important). Also at start up, NTP will perform a first adjustment that can be large; normally, NTP will exit if if the system clock is more than 1,000 seconds off (and write a message to that effect in the system log). That get done in /etc/rc.d/rc.M:
Code:
# Start the Network Time Protocol daemon:
if [ -x /etc/rc.d/rc.ntpd ]; then
  sh /etc/rc.d/rc.ntpd start
fi
and
Code:
# Start ntpd:
ntpd_start() {
  CMDLINE="/usr/sbin/ntpd -g"
  echo -n "Starting NTP daemon:  $CMDLINE"
  $CMDLINE -p /var/run/ntpd.pid
  echo
  # The kernel is now mocking around with the the hardware 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
}
Up at the top of the above, the CMDLINE="/usr/sbin/ntpd -g" is what will do that when it is executed -- it's the -g argument that allows the large adjustment. As you look through the above, notice that it checks for localtime and for UTC and acts accordingly.

You do not want to mess with either rc.M or rc.ntpd, they work just fine as is.

If you think your CMOS battery might be a problem, simply shut the system off for an hour or so then start it up in the BIOS and look at the time. If it's off by an hour, the battery is gone. If it's close to wall time, that battery is OK.

Once again, you'll want to let NTP run for some period of time before it gets completely synchronized with the external time source; "some time" may be a few days or a few hours. Just let 'er go for a while and see. Once it's synchronized, it's going to stay that way.

Hope this helps some.
 
Old 04-18-2014, 09:48 AM   #12
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,121

Rep: Reputation: 819Reputation: 819Reputation: 819Reputation: 819Reputation: 819Reputation: 819Reputation: 819
Quote:
Originally Posted by pcninja View Post
for me ntp never works in slackware. It doesn't matter if it is UTC or localtime, it just doesn't work ever.
Have you tried doing the things described above?

One thing that may affect NTP starting and running is your network connection -- if it's not connected at boot; e.g., you have to manually connect, there is a way around that.

I have a friend who is running Slackware with dial-up access (and that's about as manual as you can get). We live in the boonies and our only option is satellite (and she won't pay the cost of that). So, I have her get booted, get logged in, get connected to her ISP, and execute a little shell program that executes /etc/rc.d/rc.ntpd start. That shell program is owned by root and has the so-called "su bit" set (with chmod 4755 prog) so she can get NTP started. Works fine for her.

Dial-up is worst case, wi-fi is second worst (if it doesn't automatically connect at boot), Ethernet is best case because the interface will come up at boot.

My stuff is 24/7 with a satellite dish, all my boxes are connected with Ethernet cables to a router or a switch and I serve time to the intranet from one of them. The only time I have problem is when I take the laptop somewhere that I can't plug into a router and have to use wi-fi. I open wich, get connected and then restart NTPD. Simple.

Frankly, doing as little as possible with /etc/ntp.conf is a good approach; simply editing the file and making the server section look like this:
Code:
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

#
# NTP server (list one or more) to synchronize with:
#server pool.ntp.org iburst
server  0.us.pool.ntp.org
server  1.us.pool.ntp.org
server  2.us.pool.ntp.org
will, in every case I've ever seen or worked with, result in a working NTP (in every release of Slackware for a lot of years). You don't really need iburst, you don't need to fiddle with keys (unless you're serving time to the internet), you don't need to edit anything else.

If you want to add logging, that's easy, too. Below the driftfile section, add
Code:
# Log file
logconfig=allclock +allpeer +allsys +allsync
logfile /var/log/ntp.log
And, because the log file build up, add this file (ntpd) to /etc/logrotate.d:
Code:
cat ntpd
/var/log/ntp.log {
  rotate 10
  notifempty
  missingok
  compress
  delaycompress
  sharedscripts
  postrotate
    /etc/rc.d/rc.ntpd restart
  endscript
}
All that presupposes that you have 24/7 Internet access.

Hope this helps some.
 
Old 04-18-2014, 10:33 AM   #13
slack_
Member
 
Registered: Oct 2013
Distribution: Slackware, Arch
Posts: 101

Original Poster
Rep: Reputation: Disabled
Well it's confirmed. This morning I booted up and the time is still correct. Well almost completely, it's off sync by around 20 seconds but you say that will fix over time so I'm not worried. Thanks a lot for your help.

Last edited by slack_; 04-18-2014 at 10:34 AM.
 
Old 04-18-2014, 11:51 AM   #14
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,121

Rep: Reputation: 819Reputation: 819Reputation: 819Reputation: 819Reputation: 819Reputation: 819Reputation: 819
Some of that "off by" will be your internet connection and the values reported by ntpq -pn. NTP tries to account for delay, offset and jitter but you won't get "dead nuts" for quite a while, if ever, particularly with large values of those parameters (which are milliseconds). In my case, because I have HugesNet, there is a built-in delay from getting up to the satellite, down to the server, server fiddling around, back up to the satellite and down to me -- the satellite is 22,500 miles (or so) up and the speed of light being what it is, there's a delay in there (which, in some cases, like remote VPN, will cause problems). A second or so one way or the other doesn't matter too much and I keep all my servers synchronized from the primary system (and there is no perceptual delay on the LAN, no delay, no offset, no jitter. If you really want rock-solid, dead nuts, you can buy a GPS receiver and hook that on your LAN (there are also other types of NTP compatible time sources, all of them are expensive, varying from hundreds to thousands of dollars).

If you really want to pick nits, ask yourself where the phone company gets it's time? Answer: the same place you are, a stratum one or stratum two server though a bunch of electronics running NTP. Radio clocks are working off, in the US, WWV and, depending on where you are physically from the WWV tower, there's a propagation delay, the time it takes for the signal to get to you (and weather and type of soil and all kinds of stuff). You apply a pfudge pfactor to account for the delay (or the really expensive radio clock does that for you from your latitude and longitude). Same with GPS, there's a delay and pfudge pfactor. NTP is really good at walking your computer time into synchronization by using the delay, offset and jitter values to apply a... phudge pfactor to get your clock ticking on time.

It's all relative.

Hope this helps some.
 
Old 04-18-2014, 02:51 PM   #15
slack_
Member
 
Registered: Oct 2013
Distribution: Slackware, Arch
Posts: 101

Original Poster
Rep: Reputation: Disabled
I'm just glad I don't need to buy a new CMOS battery. I've had enough hardware problems for the year. Thanks again tronayne you certainly are quite knowledgeable.
 
  


Reply


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
Arch Linux insists on reading localtime from the hardware clock. CamTheSaxMan Linux - Newbie 2 01-23-2014 05:49 PM
Clock on wrong time (system clock is set to UTC) yanom Debian 6 07-26-2011 12:26 PM
LXer: ABLEconf streaming starts at 10:00 localtime (UTC-7) LXer Syndicated Linux News 0 04-02-2011 09:21 AM
Change from localtime to UTC (GTM+2) not working Samppa72 Linux - Software 1 12-09-2005 09:13 PM
GUI clocks show UTC instead of localtime awu72 Linux - Newbie 2 05-09-2005 01:40 AM


All times are GMT -5. The time now is 01:37 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
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration