[SOLVED] Slackware server - ntp time sync stops after a day

tennis_slacker · 07-15-2010, 01:24 PM

Well, it's been 4 days now and ntpd is still running ... this is a good sign!

I'm not entirely sure what the solution was, but it seems that commenting out the local server lines in ntp.conf has helped in my case.

I'm kind of a distro jumper on the desktop. I recently installed Salix OS and it had ntpd running by default so I looked at their ntp.conf file and they have removed the local server lines as well. So, maybe there is something to it.

Not sure if I should mark this thread as solved or not, as others seem to be using the local server lines successfully?? I'm just glad it's finally working. Thanks for everyone's assistance!

tennis_slacker · 07-15-2010, 01:37 PM

Ohhhhhh .... hold on. I checked the clock as I was writing my last post and it was fine. Now there is a difference between the hwclock and sysclock.

Code:

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 time.nist.gov   .ACTS.           1 u   84 1024  377   47.955  2868318 2655547

Code:

# ps ax | grep ntpd | grep -v grep
 3109 ?        Ss     0:10 /usr/sbin/ntpd -g -p /var/run/ntpd.pid

It's still running, but may crash if it can't adjust for this:

Code:

# hwclock
Thu 15 Jul 2010 12:44:44 PM MDT  -0.361595 seconds
root@# date
Thu Jul 15 11:44:45 MDT 2010

The correct current time was 12:32 pm MDT.

I'm worried again, DAMN, just when I thought everything was fine. We'll see if ntpd can recover. If not it may be time for a new hardware clock or motherboard.

Richard Cranium · 07-15-2010, 03:01 PM

I hope you are using more than one remote time server. The ntp docs tell you to use 3 of them.

Mine's still running after 6 days:

Code:

$ /usr/sbin/ntpq -p gateway 
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+153.16.4.136    129.6.15.29      2 u  844 1024   37  153.492   48.943  24.741
*bindcat.fhsu.ed 132.163.4.102    2 u   56 1024  377   40.237    3.031   1.309
+triangle.kansas 128.252.19.1     2 u  506 1024  273   24.877    3.353   0.680
 LOCAL(0)        .LOCL.          10 l   6d   64    0    0.000    0.000   0.000

BTW, are you running a stock system? Or have you installed other software? Maybe something else is resetting your system time.

On the other hand, my hwclock was within a few seconds of the system clock...

Code:

# hwclock
Thu 15 Jul 2010 02:55:26 PM CDT  -0.693103 seconds
# date
Thu Jul 15 14:55:31 CDT 2010

...most of which was probably from typing "date".

dimm0k · 07-15-2010, 04:14 PM

Quote:

Originally Posted by Richard Cranium

On the other hand, my hwclock was within a few seconds of the system clock...

Code:

# hwclock
Thu 15 Jul 2010 02:55:26 PM CDT  -0.693103 seconds
# date
Thu Jul 15 14:55:31 CDT 2010

...most of which was probably from typing "date".

Try "hwclock; date" to stack them so they run right after each other.

tennis_slacker · 07-15-2010, 05:14 PM

Quote:

Originally Posted by Richard Cranium

I hope you are using more than one remote time server. The ntp docs tell you to use 3 of them.

It's my understanding that this is simply to avoid the potential for a time server being down, so that you have a backup. The default ntp.conf for Debian and Ubuntu includes just one time server.

I agree it's probably better to have more servers, but I think one will suffice and you can see from my post that the 'Reach' for time.nist.gov was at 377 meaning it had full connectivity to the server.

Quote:

Originally Posted by Richard Cranium

BTW, are you running a stock system? Or have you installed other software? Maybe something else is resetting your system time.

The only thing I've installed is fail2ban from Slackbuilds, otherwise it's a stock 13.1 system.

Yeah, something strange happens where the hardware clock all of a sudden jumps like 10 minutes into the future and the system clock falls back exactly 1 hour from the hwclock. Then since the system clock is an hour different than the time server ntpd can't recover and fails. Strange??

Code:

# hwclock;date
Thu 15 Jul 2010 04:16:09 PM MDT  -0.563656 seconds
Thu Jul 15 15:16:09 MDT 2010

All I have left to conclude is that the hardware clock is failing. Time for a new motherboard I guess. Unless some has another idea????

disturbed1 · 07-15-2010, 05:47 PM

Are you overclocking your system? This is a common side effect on some motherboards from overclocking.

If you must make this work, simply make a cron job that kills ntpd, runs ntpdate pool.ntp.org periodically, then starts ntpd again. If your not syncing to this machine from other PCs, I wouldn't even bother running ntpd, just do the periodic sync.

ntpd has been running without error here for the last few days on 13.1 x86_64.

Code:

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*clock-a.develoo 164.67.62.212    2 u  657 1024  377   84.404   -4.770   4.090
+point2.adamants 69.93.111.178    3 u  862 1024  377   78.845   -4.933   3.071
-153.16.4.134    129.6.15.29      2 u  902 1024  377  173.397   55.162   3.847
+clock.trit.net  192.12.19.20     2 u  932 1024  377   81.024   -3.642   1.100
 LOCAL(0)        .LOCL.          10 l   15   64  377    0.000    0.000   0.001

Code:

#
restrict default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict 192.168.1.0 mask 255.255.255.0 nomodify

server 0.north-america.pool.ntp.org iburst
server 1.north-america.pool.ntp.org iburst
server 2.north-america.pool.ntp.org iburst
server 3.north-america.pool.ntp.org iburst

## local server
server  127.127.1.0
fudge   127.127.1.0 stratum 10

## NTP drift file - corrects for hardware clock time deviation
driftfile /etc/ntp/drift

## NTP log file
logfile /var/log/ntp.log

That's from a MythTV Backend. Time is very important there. Hate having a program end 2 mintues early

dimm0k · 07-15-2010, 06:08 PM

You never mentioned what happens to the clock if you do not run NTP... just curious, but it is probably worse without NTP?

I did a quick little search on Google and came up with this answer from yahoo! Answers, which sound a lot like your issue of time going forward. http://answers.yahoo.com/question/in...3170505AATktiJ

If you have a spare CMOS battery somewhere, it might be a quick and cheap fix rather than replacing a whole board.

tennis_slacker · 07-15-2010, 11:02 PM

Quote:

Originally Posted by disturbed1

Are you overclocking your system? This is a common side effect on some motherboards from overclocking.

Not on purpose, this is a server I don't care about overclocking. I'll check sometime soon.

tennis_slacker · 07-15-2010, 11:05 PM

Quote:

Originally Posted by dimm0k

You never mentioned what happens to the clock if you do not run NTP... just curious, but it is probably worse without NTP?

Not sure. I haven't really tried this. The hwclock ran about 10-12 minutes in the future and the sysclock 1 hour behind that for about 6 hours.

Quote:

Originally Posted by dimm0k

If you have a spare CMOS battery somewhere, it might be a quick and cheap fix rather than replacing a whole board.

I don't have a spare, but I was thinking I would get a new one just to test if that helped or not before making a drastic change to a new motherboard.

tennis_slacker · 07-17-2010, 07:16 PM

I'm drawing straws at this point hoping this is going to work, one step at a time I guess.

I've replaced the CMOS battery, reset the CMOS, and reset the date and time. The CMOS does not even have any sort of overclocking parameters so that shouldn't be an issue.

I've copied disturbed1's ntp.conf from post #66.

I'll just let it run and see how it goes ... crosses fingers ... knocks on wood ... prays to the sun god ... hoping he doesn't have to replace the motherboard.

So far so good ...

Code:

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-no-ptr.set      204.9.54.119     2 u  136  256  377   70.950  -14.380   5.984
+mirror          128.233.154.245  2 u  129  256  377   70.309    2.913   6.168
+153.16.4.139    192.5.41.40      2 u  200  256  377  116.312  -13.705   6.360
*white.web-ster. 198.60.22.240    2 u  214  256  377   36.923    3.762   0.825
 LOCAL(0)        .LOCL.          10 l 150m   64    0    0.000    0.000   0.000

# hwclock;date
Sat 17 Jul 2010 06:15:17 PM MDT  -0.040621 seconds
Sat Jul 17 18:15:17 MDT 2010

disturbed1 · 07-18-2010, 12:00 AM

Quote:

Originally Posted by tennis_slacker

I've copied disturbed1's ntp.conf from post #66.

I'll just let it run and see how it goes ... crosses fingers ... knocks on wood ... prays to the sun god ... hoping he doesn't have to replace the motherboard.

So far so good ...

Noticed my config is quite similar to Richard Cranium's. We must have consulted the same articles.

Can't say I've ever experienced or noticed the effects of a dying / weak CMOS battery. I know what happens when one is dead though. Keep us updated on the situation. It's interesting.

tennis_slacker · 07-18-2010, 10:51 AM

So much for CMOS battery theories ...

Code:

# ntpq -p
ntpq: read: Connection refused

# hwclock;date
Sun 18 Jul 2010 09:22:34 AM MDT  -0.090434 seconds
Sun Jul 18 04:22:34 MDT 2010

The only theory I have left is that the motherboard hardware clock is failing. Not sure how that affects the system clock.

I read this, "Bizarre results from the system clock may mean there is a problem with interrupts" from here. I think they were referring to the motherboard.

I'm not sure what to do. Either set the date in a cron job (a workaround and I don't really like workarounds) or start looking at used computer stores or ebay for a replacement motherboard.

Anyone have any other ideas or theory's???

tennis_slacker · 07-18-2010, 12:12 PM

Ok ... there's a 99% chance that this is a motherboard problem.

Started looking for replacements, then I needed to know what memory I had so I started looking at the computer with a flashlight.

Saw four capacitors that are bulging with dried up gunk on top of them. No bueno

.

catkin · 07-19-2010, 06:05 AM

Quote:

Originally Posted by tennis_slacker

Saw four capacitors that are bulging with dried up gunk on top of them. No bueno

.

No bueno indeed but at least it simplifies the decision about replacing the motherboard.

In the interim my earlier workaround suggestion about setting the hwclock from the system clock might buy some time.

BTW the version of ntpd in 13.1 allows use of the pool command in ntp.conf as documented at file:///usr/share/doc/ntp-4.2.6p1/html/manyopt.html#pool

Here's my ntp.conf

Code:

# Configuration file for ntpd.

# Time sources
# ~~~~~~~~~~~~
# Using pool method from /usr/share/doc/ntp-4.2.6p1/html/manyopt.html#pool
# also at http://www.eecis.udel.edu/~mills/ntp/html/manyopt.html#pool

# For India
# (Asia also required because India is inadequate)
#pool in.pool.ntp.org
#pool asia.pool.ntp.org

# For UK
pool uk.pool.ntp.org

# Local, for use when not connected to the Internet
server 127.127.1.0
fudge 127.127.1.0 stratum 10

# Drift file
# ~~~~~~~~~~
driftfile /etc/ntp/drift

lord-fu · 07-19-2010, 01:45 PM

Almost exact same thing happened to me a few years back, I tried to no avail (much like you) for weeks to try and fix. I replaced motherboard with el cheapo I had laying around and then bam time kept perfect. Mine I can only deduce came from power spikes (old wiring in house and faulty surge protector) nothing ever fried completely but once I had motherboard out I saw all sorts of gooked up resistors.