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

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Slackware server - ntp time sync stops after a day (https://www.linuxquestions.org/questions/slackware-14/slackware-server-ntp-time-sync-stops-after-a-day-817516/)

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

Here is what I get right now.

Code:

# date

Thu Jul  1 10:19:00 MDT 2010

# hwclock -r

Thu 01 Jul 2010 05:49:07 PM MDT  -0.586056 seconds

This didn't help either. I just don't understand why it works for a day or so, then stops.

Help. Thanks.

Which Slackware version are you running?

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.

Quote:

Originally Posted by Richard Cranium (Post 4021269)

Which Slackware version are you running?

I'm using 13.1.

Quote:

Originally Posted by chiragrk (Post 4021360)

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.

Quote:

Originally Posted by catkin (Post 4021403)

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

Quote:

Originally Posted by tennis_slacker (Post 4021683)

I tried ntpq -d but don't know how to use it, ...

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.

Quote:

Originally Posted by catkin (Post 4021689)

Should I restart ntpd then so ntpq can connect?

Quote:

Originally Posted by tennis_slacker (Post 4021741)

Should I restart ntpd then so ntpq can connect?

Yes -- I suggested the -d (debug) option of ntpd not ntpq (although it wouldn't do any harm to use it on ntpq in the search for clues).

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?

Quote:

Originally Posted by catkin (Post 4021742)

Yes -- I suggested the -d (debug) option of ntpd not ntpq (although it wouldn't do any harm to use it on ntpq in the search for clues).

Oops. Sorry. Here's the output from ntpd -d:

Code:

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: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123

addto_syslog: Listen and drop on 1 v6wildcard :: UDP 123

addto_syslog: Listen normally on 2 lo 127.0.0.1 UDP 123

restrict: addr 7f000001 mask ffffffff mflags 00003000 flags 00000001

addto_syslog: Listen normally on 3 eth1 192.168.1.100 UDP 123

restrict: addr c0a80164 mask ffffffff mflags 00003000 flags 00000001

addto_syslog: Listen normally on 4 lo ::1 UDP 123

addto_syslog: Listen normally on 5 eth1 fe80::21b:21ff:fe67:b261 UDP 123

restrict: addr 00000000 mask 00000000 mflags 00000000 flags 000000c0

restrict: addr 7f000001 mask ffffffff mflags 00000000 flags 00000000

key_expire: at 0 associd 27580

peer_clear: at 0 next 1 associd 27580 refid INIT

event at 0 LOCAL(0) 8011 81 mobilize assoc 27580

newpeer: 127.0.0.1->127.127.1.0 mode 3 vers 4 poll 6 6 flags 0x9 0x1 ttl 0 key 00000000

key_expire: at 0 associd 27581

peer_clear: at 0 next 2 associd 27581 refid INIT

event at 0 38.117.195.101 8011 81 mobilize assoc 27581

newpeer: 192.168.1.100->38.117.195.101 mode 3 vers 4 poll 6 10 flags 0x101 0x1 ttl 0 key 00000000

key_expire: at 0 associd 27582

peer_clear: at 0 next 3 associd 27582 refid INIT

event at 0 63.240.161.99 8011 81 mobilize assoc 27582

newpeer: 192.168.1.100->63.240.161.99 mode 3 vers 4 poll 6 10 flags 0x101 0x1 ttl 0 key 00000000

key_expire: at 0 associd 27583

peer_clear: at 0 next 4 associd 27583 refid INIT

event at 0 173.45.238.221 8011 81 mobilize assoc 27583

newpeer: 192.168.1.100->173.45.238.221 mode 3 vers 4 poll 6 10 flags 0x101 0x1 ttl 0 key 00000000

key_expire: at 0 associd 27584

peer_clear: at 0 next 5 associd 27584 refid INIT

event at 0 149.20.68.17 8011 81 mobilize assoc 27584

newpeer: 192.168.1.100->149.20.68.17 mode 3 vers 4 poll 6 10 flags 0x101 0x1 ttl 0 key 00000000

event at 0 0.0.0.0 c016 06 restart

event at 0 0.0.0.0 c012 02 freq_set kernel 101.017 PPM

refclock_transmit: at 1 127.127.1.0

refclock_receive: at 1 127.127.1.0

event at 1 LOCAL(0) 8024 84 reachable

refclock_sample: n 1 offset 0.000000 disp 0.010000 jitter 0.000001

clock_filter: n 1 off 0.000000 del 0.000000 dsp 7.937500 jit 0.000001

select: combine offset 0.000000000 jitter 0.000000954

event at 1 LOCAL(0) 963a 8a sys_peer

clock_update: at 1 sample 1 associd 27580

event at 1 0.0.0.0 c515 05 clock_sync

local_clock: offset 0.000000000 jit 0.000000954 freq 101.017 stab 0.000 poll 6

auth_agekeys: at 1 keys 1 expired 0

write_stats: wander 0.000001 thresh 0.000000, freq 101.016998

transmit: at 2 192.168.1.100->38.117.195.101 mode 3 len 48

receive: at 2 192.168.1.100<-38.117.195.101 mode 4 len 48

event at 2 38.117.195.101 8024 84 reachable

clock_filter: n 1 off 26925.698385 del 0.105877 dsp 7.937502 jit 0.000001

transmit: at 3 192.168.1.100->63.240.161.99 mode 3 len 48

receive: at 3 192.168.1.100<-63.240.161.99 mode 4 len 48

event at 3 63.240.161.99 8024 84 reachable

clock_filter: n 1 off 26925.691417 del 0.068591 dsp 7.937501 jit 0.000001

transmit: at 4 192.168.1.100->38.117.195.101 mode 3 len 48

transmit: at 4 192.168.1.100->173.45.238.221 mode 3 len 48

receive: at 4 192.168.1.100<-173.45.238.221 mode 4 len 48

event at 4 173.45.238.221 8024 84 reachable

clock_filter: n 1 off 26925.689954 del 0.067811 dsp 7.939454 jit 0.000001

receive: at 4 192.168.1.100<-38.117.195.101 mode 4 len 48

clock_filter: n 2 off 26925.697962 del 0.104984 dsp 3.937510 jit 0.000423

transmit: at 5 192.168.1.100->149.20.68.17 mode 3 len 48

transmit: at 5 192.168.1.100->63.240.161.99 mode 3 len 48

receive: at 5 192.168.1.100<-149.20.68.17 mode 4 len 48

event at 5 149.20.68.17 8024 84 reachable

clock_filter: n 1 off 26925.689135 del 0.036886 dsp 7.937501 jit 0.000001

receive: at 5 192.168.1.100<-63.240.161.99 mode 4 len 48

clock_filter: old sample 2

transmit: at 6 192.168.1.100->38.117.195.101 mode 3 len 48

transmit: at 6 192.168.1.100->173.45.238.221 mode 3 len 48

receive: at 6 192.168.1.100<-173.45.238.221 mode 4 len 48

clock_filter: old sample 2

receive: at 6 192.168.1.100<-38.117.195.101 mode 4 len 48

clock_filter: old sample 2

transmit: at 7 192.168.1.100->149.20.68.17 mode 3 len 48

transmit: at 7 192.168.1.100->63.240.161.99 mode 3 len 48

receive: at 7 192.168.1.100<-149.20.68.17 mode 4 len 48

clock_filter: n 2 off 26925.689883 del 0.035512 dsp 3.937509 jit 0.000749

receive: at 7 192.168.1.100<-63.240.161.99 mode 4 len 48

clock_filter: old sample 4

transmit: at 8 192.168.1.100->38.117.195.101 mode 3 len 48

transmit: at 8 192.168.1.100->173.45.238.221 mode 3 len 48

receive: at 8 192.168.1.100<-173.45.238.221 mode 4 len 48

clock_filter: old sample 4

receive: at 8 192.168.1.100<-38.117.195.101 mode 4 len 48

clock_filter: old sample 4

transmit: at 9 192.168.1.100->149.20.68.17 mode 3 len 48

transmit: at 9 192.168.1.100->63.240.161.99 mode 3 len 48

receive: at 9 192.168.1.100<-149.20.68.17 mode 4 len 48

clock_filter: old sample 2

receive: at 9 192.168.1.100<-63.240.161.99 mode 4 len 48

clock_filter: old sample 6

transmit: at 10 192.168.1.100->38.117.195.101 mode 3 len 48

transmit: at 10 192.168.1.100->173.45.238.221 mode 3 len 48

receive: at 10 192.168.1.100<-173.45.238.221 mode 4 len 48

clock_filter: old sample 6

receive: at 10 192.168.1.100<-38.117.195.101 mode 4 len 48

clock_filter: old sample 6

transmit: at 11 192.168.1.100->149.20.68.17 mode 3 len 48

transmit: at 11 192.168.1.100->63.240.161.99 mode 3 len 48

receive: at 11 192.168.1.100<-149.20.68.17 mode 4 len 48

clock_filter: old sample 4

receive: at 11 192.168.1.100<-63.240.161.99 mode 4 len 48

clock_filter: old sample 8

transmit: at 12 192.168.1.100->38.117.195.101 mode 3 len 48

transmit: at 12 192.168.1.100->173.45.238.221 mode 3 len 48

receive: at 12 192.168.1.100<-173.45.238.221 mode 4 len 48

clock_filter: old sample 8

receive: at 12 192.168.1.100<-38.117.195.101 mode 4 len 48

clock_filter: old sample 8

transmit: at 13 192.168.1.100->149.20.68.17 mode 3 len 48

transmit: at 13 192.168.1.100->63.240.161.99 mode 3 len 48

receive: at 13 192.168.1.100<-149.20.68.17 mode 4 len 48

clock_filter: old sample 6

receive: at 13 192.168.1.100<-63.240.161.99 mode 4 len 48

clock_filter: old sample 10

transmit: at 14 192.168.1.100->173.45.238.221 mode 3 len 48

receive: at 14 192.168.1.100<-173.45.238.221 mode 4 len 48

clock_filter: n 6 off 26925.690990 del 0.066533 dsp 0.191399 jit 0.001470

select: combine offset 26925.690879581 jitter 0.001589211

event at 14 173.45.238.221 963a 8a sys_peer

clock_update: at 14 sample 14 associd 27583

event at 14 0.0.0.0 0617 07 panic_stop +26926 s; set clock manually within 1000 s.

Quote:

Originally Posted by michaelk (Post 4021745)

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 (Post 4021745)

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

But I guarantee in a day or so it will quit.

Quote:

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?

Quote:

Originally Posted by michaelk (Post 4021775)

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