[SOLVED] Slackware server - ntp time sync stops after a day
SlackwareThis 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.
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.
Slackware server - ntp time sync stops after a day
I give up and need help. I've been fighting this for over a week now and just can't get my server's time to continue synchronizing.
Code:
# /etc/rc.d/rc.ntpd status
ntpd is running
If I restart ntpd everything works perfectly for a day. Then the synchronization stops and I get:
Code:
# ntpq -p
ntpq: read: Connection refused
Here's my ntp.conf:
Code:
# grep -v "^#" /etc/ntp.conf
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
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
driftfile /etc/ntp/drift
multicastclient # listen on default 224.0.1.1
broadcastdelay 0.008
restrict default noquery nomodify
restrict 127.0.0.1
I opened my wireless routers port 123 udp, thinking that was necessary. Though I don't understand why, since I had a Debian server running on this machine and never needed that.
I even thought my hwclock was messing something up so I did:
Code:
# sh /etc/rc.d/rc.ntpd stop
# ntpdate pool.ntp.org
# hwclock -w
# sh /etc/rc.d/rc.ntpd start
Couldn't help noticing the time difference between hwclock and date is 4:30. Is it possible that hwclock is showing the time w.r.t GMT, while "date" is showing the time w.r.t your time zone.
- Still doesn't explain why ntp would stop syncing. Did you check /var/log/messages or the related log file to see if daemon is crashing for some reason?
- When `ntpq -p` shows "ntpq: read: Connection refused" did you check the status of ntpd process?
Maybe get some helpful information by using the -d (debug) option of ntpd. For starters you could try a single -d and see how much that generates in /var/log/debug messages or syslog.
Did you check /var/log/messages or the related log file to see if daemon is crashing for some reason?
- When `ntpq -p` shows "ntpq: read: Connection refused" did you check the status of ntpd process?
Yes, I've looked at /var/log/messages and /var/log/syslog. I don't see any info.
Yes, the ntpd process was checked when ntpq -p was tested.
Maybe get some helpful information by using the -d (debug) option of ntpd. For starters you could try a single -d and see how much that generates in /var/log/debug messages or syslog.
I tried ntpq -d but don't know how to use it, it gives:
Code:
# ntpq -d ntpq>
I did look at /var/log/debug and say several messages like this:
Code:
Jun 29 14:00:00 localhost ntpd[31319]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
Hopefully it doesn't matter that the messages are not easy to understand, they will show a regular pattern while ntpd is working and ntpq can connect with it, followed by a useful clue around the 24 hour mark when ntpq can no longer connect.
Hopefully it doesn't matter that the messages are not easy to understand, they will show a regular pattern while ntpd is working and ntpq can connect with it, followed by a useful clue around the 24 hour mark when ntpq can no longer connect.
Usually the "ntpq: read: Connection refused" error means ntpd stopped running. If the local clock is significantly off from the real time then ntpd will automatically terminate. Your last post was at 12:50 AM i.e. 06:50 (18:50) MDT and your hardware clock was at 05:49 PM (17:59) so it depends on when you executed the commands vs time posted so could your hardware clock be off an hour? Since system time does not equal +/- 6 hours from UTC then have you noticed any significant drift?
After you run the ntpdate and hwclock -w commands and assuming they complete successfully, does system time and the hardware clock match?
Usually the "ntpq: read: Connection refused" error means ntpd stopped running. If the local clock is significantly off from the real time then ntpd will automatically terminate.
Code:
# ntpq -p
ntpq: read: Connection refused
# /etc/rc.d/rc.ntpd status
ntpd is running.
# sh /etc/rc.d/rc.ntpd stop
Stopping NTP daemon.../etc/rc.d/rc.ntpd: line 16: kill: (31319) - No such process
So, you're probably right even though the status says it's running it's actually not.
Quote:
Originally Posted by michaelk
After you run the ntpdate and hwclock -w commands and assuming they complete successfully, does system time and the hardware clock match?
Code:
# ntpdate time.nist.gov
2 Jul 08:25:21 ntpdate[17034]: adjust time server 192.43.244.18 offset 0.006408 sec
# hwclock -w
# date
Fri Jul 2 08:25:36 MDT 2010
# hwclock -r
Fri 02 Jul 2010 08:25:46 AM MDT -0.961467 seconds
This is what I've already done. I restarted ntpd and once again everything is working fine:
Code:
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) .LOCL. 10 l 93 64 2 0.000 0.000 0.001
-mighty.poclabs. 38.117.195.101 4 u 25 64 3 67.995 -0.311 1.035
*pool-test.ntp.o 204.123.2.72 2 u 25 64 3 35.559 -2.191 0.260
+clock-b.develoo 164.67.62.212 2 u 24 64 3 43.738 -2.896 2.297
+69.50.219.51 192.43.244.18 2 u 20 64 3 57.571 -0.375 1.553
event at 14 0.0.0.0 0617 07 panic_stop +26926 s; set clock manually within 1000 s.
26926 seconds is ~7.5 hours which is the difference between the hardware clock and system clock times from your first post. Maybe be a drift problem does your computer run 24/7?
26926 seconds is ~7.5 hours which is the difference between the hardware clock and system clock times from your first post.
This was because ntpd was not running and my clock was off. I already knew that, but I just ran the ntpdate and hwclock -w commands in my previous post to correct that (like I've done already before posting to the forum). Here's the output now that ntpd is running:
Code:
# ntpd -d
ntpd 4.2.6p1@1.2158-o Sat Apr 24 19:01:14 UTC 2010 (1)
addto_syslog: proto: precision = 0.838 usec
event at 0 0.0.0.0 c01d 0d kern kernel time sync enabled
addto_syslog: line 31 column 19 syntax error, unexpected T_EOC, expecting T_Ipv4_flag or T_Ipv6_flag or T_String
addto_syslog: syntax error in /etc/ntp.conf line 31, column 19
Finished Parsing!!
addto_syslog: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
addto_syslog: unable to bind to wildcard address 0.0.0.0 - another process may be running - EXITING
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
