Slackware This Forum is for the discussion of Slackware Linux.
|
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
|
04-16-2014, 04:38 PM
|
#1
|
Member
Registered: Oct 2013
Distribution: Slackware, Arch
Posts: 105
Rep:
|
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.
|
|
|
04-16-2014, 04:54 PM
|
#2
|
Senior Member
Registered: Nov 2013
Location: Brazil
Distribution: Slackware
Posts: 1,223
Rep:
|
I assume you can go on the BIOS settings and adjust it?
|
|
|
04-16-2014, 05:24 PM
|
#3
|
Member
Registered: Sep 2011
Posts: 925
|
Quote:
Originally Posted by slack_
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.
|
|
|
04-16-2014, 05:25 PM
|
#4
|
Member
Registered: Apr 2014
Posts: 39
Rep:
|
It's a symptom of a dead CMOS battery, replace it, they only cost a couple of pounds or dollars.
|
|
|
04-17-2014, 10:16 AM
|
#5
|
Senior Member
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
|
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
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.
|
04-17-2014, 03:47 PM
|
#6
|
Member
Registered: Oct 2013
Distribution: Slackware, Arch
Posts: 105
Original Poster
Rep:
|
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.
|
|
|
04-17-2014, 06:12 PM
|
#7
|
Senior Member
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
|
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.
|
|
|
04-17-2014, 09:33 PM
|
#8
|
Senior Member
Registered: Apr 2009
Location: McKinney, Texas
Distribution: Slackware64 15.0
Posts: 3,860
|
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."?)
|
|
|
04-17-2014, 09:59 PM
|
#9
|
Member
Registered: Oct 2013
Location: SE Wisconsin, USA
Distribution: Arch Linux
Posts: 93
Rep:
|
for me ntp never works in slackware. It doesn't matter if it is UTC or localtime, it just doesn't work ever.
|
|
|
04-17-2014, 10:25 PM
|
#10
|
Member
Registered: Oct 2013
Distribution: Slackware, Arch
Posts: 105
Original Poster
Rep:
|
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.
|
|
|
04-18-2014, 09:10 AM
|
#11
|
Senior Member
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
|
Quote:
Originally Posted by slack_
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.
|
|
|
04-18-2014, 09:48 AM
|
#12
|
Senior Member
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
|
Quote:
Originally Posted by pcninja
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.
|
|
|
04-18-2014, 10:33 AM
|
#13
|
Member
Registered: Oct 2013
Distribution: Slackware, Arch
Posts: 105
Original Poster
Rep:
|
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.
|
|
|
04-18-2014, 11:51 AM
|
#14
|
Senior Member
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
|
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.
|
|
|
04-18-2014, 02:51 PM
|
#15
|
Member
Registered: Oct 2013
Distribution: Slackware, Arch
Posts: 105
Original Poster
Rep:
|
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.
|
|
|
All times are GMT -5. The time now is 10:33 AM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|