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.

I assume you can go on the BIOS settings and adjust it?

You set up NTP time synchronisation and solve that problem forever.

It's a symptom of a dead CMOS battery, replace it, they only cost a couple of pounds or dollars.

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:
You want to make it look like this -- you need to be root to do this:
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:
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
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:
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:
Hope this helps some.

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?

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.

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."?)

for me ntp never works in slackware. It doesn't matter if it is UTC or localtime, it just doesn't work ever.

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.

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:
and
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.

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:
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
And, because the log file build up, add this file (ntpd) to /etc/logrotate.d:
All that presupposes that you have 24/7 Internet access.

Hope this helps some.

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.

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.

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.