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.
...and if it works, great! If not, leave it like that and start looking at other things. Again, be sure that you can reach out to the Internet on port 123/udp. After reading this thread several times, I wonder what the network-related files looked like when everything worked. If the old settings are lost, I'm not sure how a full reinstall would help. I've used DHCP only for PXE booting, so someone else will have to point out the subtle nuances of networking with ntpd.
I agree with mlslk31's assessment here. The fact that ntpdate itself was failing to find a server is telling, as the contents of the config file shouldn't matter in this case.
I'd be inclined to try "ntpdate -d ca.pool.ntp.org" and see if the additional diagnostics give you a clue as to the nature of the failure. (make sure ntpd isn't running when you run ntpdate, or you'll get a socket in use error)
The orphan mode v local clock discussion that tron and I have been having is probably confusing the issue, and you're probably better off without either of them in there until you get the thing to work with just a basic server or pool definition as mlslk31 suggests.
I'll step aside now, as I think there's a "too many cooks" issue going on here and its not helping your plight.
Installed from another dvd burnt with growisofs, and file browser behaves differently but I still get: format error frequency file /etc/ntp/drift from /var/log/syslog so I think that this dvd is also corrupt.
Downloaded another 14.1 and burnt to dvd with growisofs speed=4, but before it install again, can anyone tell me what this means?
Looking at that, ntpdate looks to be working correctly, which is different than you described before as you were reporting:
Quote:
29 Apr 09:36:53 ntpdate[1397]: no server suitable for synchronization found
I'd be inclined to ignore the error about the drift file for now (it might just be because it was empty/uninitialised), ntpd will most likely re-write it with something meaningful before too long.
Just do a /etc/rc.d/rc.ntpd start to restart ntpd and keep an eye on it with 'ntpq -pn' for now and see what happens.
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
Quote:
Originally Posted by WilliamS
Tronayne, content of /etc/resolv.conf is
# Generated by dhcpcd from eth0
# /etc/resolv.conf.head can replace this line
nameserver 192.168.175.250
nameserver 192.168.175.251
# /etc/resolv.conf.tail can replace this line
Then: # ntpdate 0.ca.pool.ntp.org
29 Apr 23:38:22 ntpdate[13055]: no server suitable for synchronization found
When you execute that line and get that result, can you ping that address; e.g.,
Code:
ping -c 5 0.ca.pool.ntp.org
PING 0.ca.pool.ntp.org (206.108.0.132) 56(84) bytes of data.
64 bytes from ntp2.torix.ca (206.108.0.132): icmp_seq=1 ttl=239 time=931 ms
64 bytes from ntp2.torix.ca (206.108.0.132): icmp_seq=2 ttl=239 time=640 ms
64 bytes from ntp2.torix.ca (206.108.0.132): icmp_seq=3 ttl=239 time=634 ms
64 bytes from ntp2.torix.ca (206.108.0.132): icmp_seq=4 ttl=239 time=631 ms
64 bytes from ntp2.torix.ca (206.108.0.132): icmp_seq=5 ttl=239 time=617 ms
--- 0.ca.pool.ntp.org ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4656ms
rtt min/avg/max/mdev = 617.673/691.265/931.836/120.525 ms
If that does not work -- you can't ping it and get a response similar to the above -- then you have a DNS problem.
If you can ping and get a similar response but ntpdate still says that no server can be found, the port may not enabled (it is enabled by default in Slackware in the file /etc/services entries for Network Time Protocol). If the DNS addresses in your /etc/resolv.conf file are a local router and the router has port 123/tcp or 123/udp closed, you would want to enable NTPD, port 123 to port 123, protocol UDP in your router if necessary, routers don't always pass those ports by default (my Linksys BEFSR41 does not, I had to enable it in the Applications & Gaming section of the router set up).
Note that if you have a router connected to your network interface that it's recommended that you use a fixed-IP address for your system; e.g., 192.168.1.10 or something less than 192.168.1.100 (which is where DHCP starts addressing). The default gateway address, for a Linksys, is 192.168.1.1 (it's the base address of the router, other routers use different addresses). That's not me, that's Linksys' advice. The router uses DHCP to connect to the network interface, but your system connects to the router with a fixed address. Of course if you don't have a router connected between the system and the network interface, that's irrelevant.
Quote:
Originally Posted by WilliamS
and
# ls /var/log/packages/ntp*
/var/log/packages/ntp-4.2.6p5-i486-5_slack14.1
That's the correct version of NTP.
Quote:
Originally Posted by WilliamS
I'm thinking that ntp always worked before 14.1, I always did the servers and driftfile and commented out the fudge, as others, and nobody else complains.
So I intend to reinstall 14.1 from a different DVD.
You probably don't need to do that, but check your router set up and whether your DNS server is finding a pool server; all NTP pool servers are pingable.
For right now, tos orphan may not be a Real Good Idea; you can go read information about orphan mode at http://support.ntp.org/bin/view/Support/OrphanMode. I will admit that I don't totally understand precisely what the difference is between an end-user (such as you, me, and most other folks that don't serve time to the Internet) using an undisciplined local clock (as in the above example) and orphan mode which is mostly about preventing reflected denial of server (DRDoS) attacks.
Orphan mode is better explained at http://www.eecis.udel.edu/~mills/ntp/html/orphan.html. Also, the current documentation for the undisciplined local clock states about itself, "This is not recommended for new installations."
LOCAL was great in the days of intermittent dial-up Internet. Those days are mostly gone. Orphan mode is a way for the NTP developers to admit they were wrong the first time without admitting they were wrong; that maybe it was a bad idea to risk having fake UTC sources getting mixed up with real sources. The difference seems to be that with LOCAL, it's a simulated UTC refclock that can compete with the other refclocks. With orphan, you work with legitimate refclocks, and when they don't work, the server refid turns to 127.0.0.1 when sources of time have been lost. After that, it seems like only other explicit orphans will play with this orphan scheme...though orphan is confusing, and I could be wrong about this last part.
Otherwise, you're right. Orphan is rather tricky and evil, giving unexpected results until everything is setup perfectly for server and clients. It should be configured after normal time service has been set up. Leave orphan out for now.
Just curious, WilliamS, does CHU come in loud and clear on any of 3330, 7850, or 14670 kHz? You had some coordinates in your info, and they seemed rather close to the CHU transmitters in Ottawa...just didn't know if you were in CHU's skip zone. I use CHU here in Florida when WWV has propagation issues.
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
Quote:
Originally Posted by GazL
Looking at that, ntpdate looks to be working correctly, which is different than you described before as you were reporting:
I'd be inclined to ignore the error about the drift file for now (it might just be because it was empty/uninitialised), ntpd will most likely re-write it with something meaningful before too long.
Just do a /etc/rc.d/rc.ntpd start to restart ntpd and keep an eye on it with 'ntpq -pn' for now and see what happens.
Yup it does!
Ta-da!
You can
Code:
cat /etc/ntp/drift
any you should see a floating-point number (it could be zero, too).
For example, mine looks like (your will not be the same):
Code:
cat /etc/ntp/drift
-11.857
There is only one line, no comments, no blank lines, only one value on the line and it is numeric.
NTP will walk your clock into synchronization to the point that it will be a few milliseconds off (it's never going to be dead nuts unless you've got an expensive GPS or radio timeserver connected to your network). A millisecond here, a millisecond there, you're talking nits. That 9 seconds off you're seeing will, after a few days, become almost nothing, just wait a while.
Tried this, still the same:
# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
192.95.20.208 .INIT. 16 u - 1024 0 0.000 0.000 0.000
142.137.247.109 .INIT. 16 u - 1024 0 0.000 0.000 0.000
208.81.2.13 .INIT. 16 u - 1024 0 0.000 0.000 0.000
206.108.0.131 .INIT. 16 u - 1024 0 0.000 0.000 0.000
bash-4.2#
I have no router. Direct satellite connection.
# ping -c 3 0.ca.pool.ntp.org
PING 0.ca.pool.ntp.org (67.215.197.151) 56(84) bytes of data.
64 bytes from swordfish.hopcount.ca (67.215.197.151): icmp_seq=1 ttl=54 time=707 ms
64 bytes from swordfish.hopcount.ca (67.215.197.151): icmp_seq=2 ttl=54 time=674 ms
64 bytes from swordfish.hopcount.ca (67.215.197.151): icmp_seq=3 ttl=54 time=645 ms
Remember, ping and NTP are two different issues. The net is not as friendly as it used to be--can't just use `ntpq -p hostname` any more and expect it to work--so I had to resort to this method to see which hosts were up:
Code:
root:~# ntpq -np
remote refid st t when poll reach delay offset jitter
==============================================================================
-69.172.212.61 142.54.181.202 3 u 746 1024 377 90.414 -8.290 5.853
+38.229.71.1 172.16.32.4 2 u 423 512 377 69.731 -0.363 3.173
-173.230.158.30 199.102.46.73 2 u 127 512 337 101.367 2.431 3.780
+71.19.149.98 204.123.2.72 2 u 344 512 377 95.606 -1.690 1.382
*137.190.2.4 .GPS. 1 u 474 512 377 70.180 2.825 4.049
# I use those number addresses from above and feed them to nmap...
root:~# nmap -p123 -sU 137.190.2.4 38.229.71.1 71.19.149.98
Starting Nmap 6.01 ( http://nmap.org ) at 2014-04-30 13:10 EDT
Nmap scan report for tedc-gps1.weber.edu (137.190.2.4)
Host is up (0.10s latency).
PORT STATE SERVICE
123/udp open ntp
Nmap scan report for clock.team-cymru.org (38.229.71.1)
Host is up (0.087s latency).
PORT STATE SERVICE
123/udp open ntp
Nmap scan report for rcloran.xen.prgmr.com (71.19.149.98)
Host is up (0.11s latency).
PORT STATE SERVICE
123/udp open ntp
Nmap done: 3 IP addresses (3 hosts up) scanned in 0.31 seconds
Also, should debugging be in your ntpd (I think), you can stop ntpd and try this:
Code:
root:~# ntpd -Nndg -c whatever_ntp_conf_you_want_to_use
# comments are mine
ntpd 4.2.6p5@1.2349-o Tue Apr 8 23:14:07 UTC 2014 (1)
# ... much internal setup snipped ...
# setup remote "server"
key_expire: at 0 associd 57333
peer_clear: at 0 next 1 associd 57333 refid INIT
event at 0 199.19.167.36 8011 81 mobilize assoc 57333
newpeer: 192.168.0.129->199.19.167.36 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000
# setup remote "server"
key_expire: at 0 associd 57334
peer_clear: at 0 next 2 associd 57334 refid INIT
event at 0 199.182.221.110 8011 81 mobilize assoc 57334
newpeer: 192.168.0.129->199.182.221.110 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000
# setup remote "server"
key_expire: at 0 associd 57335
peer_clear: at 0 next 3 associd 57335 refid INIT
event at 0 208.80.96.70 8011 81 mobilize assoc 57335
newpeer: 192.168.0.129->208.80.96.70 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000
key_expire: at 0 associd 57336
# setup remote "server"
peer_clear: at 0 next 4 associd 57336 refid INIT
event at 0 198.245.49.187 8011 81 mobilize assoc 57336
newpeer: 192.168.0.129->198.245.49.187 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000
# internal state
event at 0 0.0.0.0 c016 06 restart
event at 0 0.0.0.0 c012 02 freq_set kernel 0.000 PPM
event at 0 0.0.0.0 c011 01 freq_not_set
# good receive
transmit: at 1 192.168.0.129->199.19.167.36 mode 3 len 48
auth_agekeys: at 1 keys 1 expired 0
receive: at 1 192.168.0.129<-199.19.167.36 mode 4 len 48
event at 1 199.19.167.36 8024 84 reachable
clock_filter: n 1 off 0.007866 del 0.083710 dsp 7.937502 jit 0.000001
# good receive
transmit: at 2 192.168.0.129->199.182.221.110 mode 3 len 48
receive: at 2 192.168.0.129<-199.182.221.110 mode 4 len 48
event at 2 199.182.221.110 8024 84 reachable
clock_filter: n 1 off 0.008942 del 0.105870 dsp 7.937501 jit 0.000001
# good receive
transmit: at 3 192.168.0.129->208.80.96.70 mode 3 len 48
receive: at 3 192.168.0.129<-208.80.96.70 mode 4 len 48
event at 3 208.80.96.70 8024 84 reachable
clock_filter: n 1 off 0.007138 del 0.076863 dsp 7.937502 jit 0.000001
# good receive
transmit: at 4 192.168.0.129->198.245.49.187 mode 3 len 48
receive: at 4 192.168.0.129<-198.245.49.187 mode 4 len 48
event at 4 198.245.49.187 8024 84 reachable
clock_filter: n 1 off 0.005559 del 0.082381 dsp 7.937501 jit 0.000001
# good transmit to client
receive: at 13 192.168.0.129<-192.168.0.134 mode 3 len 48
transmit: at 13 192.168.0.129->192.168.0.134 mode 4 len 48
ntpd[15545]: ntpd exiting on signal 2
If not, maybe you should think about putting debugging in there. Sorry for the long cut-and-paste.
9 seconds should be well within what ntpd can correct, so I've stopped short of asking you to use the date command to set the time, then start ntpd.
BTW, satellite makes things a little different. I hope they haven't filtered out port 123. My only experience with satellite has been HughesNet. It seemed like ntpd took longer to work well over satellite, and that it was best to choose servers closest to whatever building HughesNet used to uplink to the satellite. Memory is hazy...
What I don't get is why, when they both use the same protocol, ntpdate managed to work when ntp isn't managing to get past INIT.
But perhaps the debugging options will reveal something interesting.
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
OK, thought I'd give tos orphan a shot so I shut down one of my LAN servers (that is normally synchronized with my main work station with NTP).
I copied /etc/ntp.conf to /etc/ntp.conf.bak
I copied /etc/ntp.conf.new to /etc/ntp.con
I edited /etc/ntp.conf with these changes:
Code:
# Comment the local clock out to enable tos orphan
#server 127.127.1.0 # local clock
#fudge 127.127.1.0 stratum 10
#
# Enable tos orphan
tos orphan
#
# 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
I made no other changes in the configuration.
I immediately ran ntpq -pn
Code:
ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
142.54.185.82 216.229.0.49 3 u 1 64 1 615.862 12.121 0.001
208.75.89.4 .INIT. 16 u - 64 0 0.000 0.000 0.000
134.121.64.62 .INIT. 16 u - 64 0 0.000 0.000 0.001
Result as expected, no synchronization, three candidates.
I then decided to see how long it would take to get synchronized and did
Code:
snafu-root-/etc: while true
> do
> ntpq -pn
> sleep 60
> done
remote refid st t when poll reach delay offset jitter
==============================================================================
*142.54.185.82 216.229.0.49 3 u 2 64 3 574.522 11.046 7.418
208.75.89.4 134.121.64.86 2 u 4 64 3 596.296 17.907 20.648
134.121.64.62 .GPS. 1 u 1 64 3 594.460 6.778 11.397
remote refid st t when poll reach delay offset jitter
==============================================================================
*142.54.185.82 216.229.0.49 3 u 62 64 3 574.522 11.046 7.418
208.75.89.4 134.121.64.86 2 u 64 64 3 596.296 17.907 20.648
134.121.64.62 .GPS. 1 u 61 64 3 594.460 6.778 11.397
remote refid st t when poll reach delay offset jitter
==============================================================================
*142.54.185.82 216.229.0.49 3 u 54 64 7 574.522 11.046 9.373
208.75.89.4 134.121.64.86 2 u 55 64 7 596.296 17.907 58.949
134.121.64.62 .GPS. 1 u 54 64 7 594.460 6.778 13.137
remote refid st t when poll reach delay offset jitter
==============================================================================
*142.54.185.82 216.229.0.49 3 u 46 64 17 574.522 11.046 9.624
208.75.89.4 134.121.64.86 2 u 49 64 17 597.221 0.980 67.293
134.121.64.62 .GPS. 1 u 44 64 17 594.460 6.778 140.104
remote refid st t when poll reach delay offset jitter
==============================================================================
*142.54.185.82 216.229.0.49 3 u 38 64 37 558.553 5.681 11.736
+208.75.89.4 134.121.64.86 2 u 42 64 37 615.788 23.223 57.660
+134.121.64.62 .GPS. 1 u 37 64 37 615.222 6.495 140.291
remote refid st t when poll reach delay offset jitter
==============================================================================
+142.54.185.82 216.229.0.49 3 u 32 64 77 558.553 5.681 12.241
+208.75.89.4 134.121.64.86 2 u 36 64 77 615.967 5.863 89.746
*134.121.64.62 .GPS. 1 u 31 64 77 611.150 0.776 142.894
Took five minutes to get synchronized with additional candidates identified and one more minute to switch from the original synchronized server to the GPS reference server.
Conclusion: looks like it works as advertised.
I did not specify a value for orphan (the default is 16, that's good enough, methinks). The recommended value for N is 2 less than the worst-case externally-reachable source of time. Normally, the reason for either Undisciplined Local Clock (the old method) or Orphan (the new method) is that NTP continues running when the Internet (or a local time reference) is unavailable; NTP would fall back to synchronizing with the local (system) clock with no external source of time then resynchronize with an external reference when the Internet comes back and one or more are available. It would do the same thing on my LAN if the time server becomes unavailable (shut down for some reason or other).
An examination of the ntpq displays indicates that the recommended value (which is also an example value in the documentation) be 6; i.e., stratum 1 - 5 servers (I have never seen a stratum 4 server being used, the normal in my installation is stratum 2 or 3 and the GPS server in the examples above being referenced to a stratum 1 server is the first I've ever seen).
I'm inclined to edit /etc/ntp.conf and add the value 6 as the N argument to the tos orphan line. Ought to cover pretty much everything.
But, what happens when the Internet goes away? Supposed to go into orphan mode and wait until an external server becomes available.
OK, pull the plug, wait a while (like 5 minutes) and plug it back in.
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
Quote:
Originally Posted by mlslk31
BTW, satellite makes things a little different. I hope they haven't filtered out port 123. My only experience with satellite has been HughesNet. It seemed like ntpd took longer to work well over satellite, and that it was best to choose servers closest to whatever building HughesNet used to uplink to the satellite. Memory is hazy...
It does a little longer, like a couple of minutes, just because of the 22,500 miles up, down, back up, back down delay. Had the laptop attached to one of Merit's fiber optic connections a couple of weeks ago and it took about two- or three minutes to synchronize (there's a lot of mumbling to itself that goes on in NTP).
Seem like, if the OPs provider was filtering out port 123, probably wouldn't be able to get a time setting from ntpdate -- but I really don't know that for absolute certain.
2# ntpq -np
remote refid st t when poll reach delay offset jitter
==============================================================================
192.95.20.208 .INIT. 16 u - 1024 0 0.000 0.000 0.000
142.137.247.109 .INIT. 16 u - 1024 0 0.000 0.000 0.000
208.81.2.13 .INIT. 16 u - 1024 0 0.000 0.000 0.000
206.108.0.131 .INIT. 16 u - 1024 0 0.000 0.000 0.000
bash-4.2# nmap -p123 -sU nmap -p123 -sU 206.108.0.131
Only 1 -p option allowed, separate multiple ranges with commas.
QUITTING!
bash-4.2# nmap -p1 -sU nmap 206.108.0.131
Starting Nmap 6.40 ( http://nmap.org ) at 2014-04-30 16:23 EDT
Failed to resolve "nmap".
Nmap scan report for ntp1.torix.ca (206.108.0.131)
Host is up (0.0019s latency).
PORT STATE SERVICE
1/udp open|filtered tcpmux
Nmap done: 1 IP address (1 host up) scanned in 3.00 seconds
bash-4.2# nmap -p1 -sU nmap 142.137.247.109
Starting Nmap 6.40 ( http://nmap.org ) at 2014-04-30 16:24 EDT
Failed to resolve "nmap".
Nmap scan report for ntp.lanets.ca (142.137.247.109)
Host is up (0.0011s latency).
PORT STATE SERVICE
1/udp open|filtered tcpmux
Nmap done: 1 IP address (1 host up) scanned in 2.85 seconds
bash-4.2# /etc/rc.d/rc.ntpd stop
Stopping NTP daemon...
bash-4.2# 142.137.247.109
and
# ntpd -Nndg -c /etc/ntp.conf
ntpd 4.2.6p5@1.2349-o Mon Oct 14 08:03:28 UTC 2013 (1)
30 Apr 16:26:19 ntpd[15539]: proto: precision = 0.208 usec
event at 0 0.0.0.0 c01d 0d kern kernel time sync enabled
Finished Parsing!!
30 Apr 16:26:19 ntpd[15539]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
30 Apr 16:26:19 ntpd[15539]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
30 Apr 16:26:19 ntpd[15539]: Listen and drop on 1 v6wildcard :: UDP 123
30 Apr 16:26:19 ntpd[15539]: Listen normally on 2 lo 127.0.0.1 UDP 123
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00003000 flags 00000001
30 Apr 16:26:19 ntpd[15539]: Listen normally on 3 eth0 192.95.192.36 UDP 123
restrict: op 1 addr 192.95.192.36 mask 255.255.255.255 mflags 00003000 flags 00000001
30 Apr 16:26:19 ntpd[15539]: Listen normally on 4 lo ::1 UDP 123
restrict: op 1 addr ::1 mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff mflags 00003000 flags 00000001
30 Apr 16:26:19 ntpd[15539]: Listen normally on 5 eth0 fe80::1e6f:65ff:fe4c:79cd UDP 123
restrict: op 1 addr fe80::1e6f:65ff:fe4c:79cd mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff mflags 00003000 flags 00000001
30 Apr 16:26:19 ntpd[15539]: peers refreshed
30 Apr 16:26:19 ntpd[15539]: Listening on routing socket on fd #22 for interface updates
restrict: op 1 addr 0.0.0.0 mask 0.0.0.0 mflags 00000000 flags 000000c0
restrict: op 1 addr :: mask 0.0.0.0 mflags 00000000 flags 000000c0
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00000000 flags 00000000
30 Apr 16:26:19 ntpd[15539]: format error frequency file /etc/ntp/drift
key_expire: at 0 associd 652
peer_clear: at 0 next 1 associd 652 refid INIT
event at 0 206.108.0.131 8011 81 mobilize assoc 652
newpeer: 192.95.192.36->206.108.0.131 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000
key_expire: at 0 associd 653
peer_clear: at 0 next 2 associd 653 refid INIT
event at 0 208.80.96.70 8011 81 mobilize assoc 653
newpeer: 192.95.192.36->208.80.96.70 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000
key_expire: at 0 associd 654
peer_clear: at 0 next 3 associd 654 refid INIT
event at 0 198.50.145.138 8011 81 mobilize assoc 654
newpeer: 192.95.192.36->198.50.145.138 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000
key_expire: at 0 associd 655
peer_clear: at 0 next 4 associd 655 refid INIT
event at 0 198.50.209.202 8011 81 mobilize assoc 655
newpeer: 192.95.192.36->198.50.209.202 mode 3 vers 4 poll 6 10 flags 0x1 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 0.000 PPM
event at 0 0.0.0.0 c011 01 freq_not_set
transmit: at 1 192.95.192.36->206.108.0.131 mode 3 len 48
auth_agekeys: at 1 keys 1 expired 0
transmit: at 2 192.95.192.36->208.80.96.70 mode 3 len 48
transmit: at 3 192.95.192.36->198.50.145.138 mode 3 len 48
transmit: at 4 192.95.192.36->198.50.209.202 mode 3 len 48
transmit: at 66 192.95.192.36->208.80.96.70 mode 3 len 48
transmit: at 68 192.95.192.36->206.108.0.131 mode 3 len 48
transmit: at 68 192.95.192.36->198.50.145.138 mode 3 len 48
transmit: at 71 192.95.192.36->198.50.209.202 mode 3 len 48
transmit: at 130 192.95.192.36->208.80.96.70 mode 3 len 48
transmit: at 132 192.95.192.36->198.50.145.138 mode 3 len 48
transmit: at 134 192.95.192.36->206.108.0.131 mode 3 len 48
transmit: at 136 192.95.192.36->198.50.209.202 mode 3 len 48
That should be `nmap -p123 -sU hosts-to-check`. "-p123" means "check port 123." "-sU" means "scan UDP." It should work, but it's worth that extra try, in case it doesn't work.
Your ntpd debug output is showing that has sent out trasmit packets to the external time servers. However, it has not received any replies from any of them. It keeps re-sending those packets every 64s, which is expected. Hopefully, all of your restrict lines have been removed from ntp.conf for that test.
I'd be looking to see where the round trip from PC to time server and back has been broken. In case multiple devices on your network can be the gateway, be sure that the correct device is chosen. In case there's a mix of IPv4 and IPv6 PCs, try using `server -4 whatever-pc` instead of `server whatever-pc`.
This is the part where I'd be looking at a backup of /etc from your previous system to see what's different, or compare settings with another PC on your network that's working just fine.
Hardware clocks are, any more, fairly accurate. System clocks are notorious for drifting all over the place without something (like NTP) keeping them on time...
It is possible for an offline Linux Box to keep good datetime. I have been working to make this true in Slackware.
While System Clocks typically need to have their rate set, they are also typically more stable than the RTC. For example, the System Clock rate can be set in /etc/rc.d/rc.local like this:
Code:
/sbin/adjtimex --tick 10000 --freq 1838292
Of course, you must first figure out the correct values for your machine.
Quote:
Originally Posted by tronayne
Others prefer both the hardware and software clocks to use local time.
System Clock always ticks in UTC. That is why hwclock must be told what RTC is ticking in, so that it can covert it to UTC as necessary for --hctosys.
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
OK, let's stop screwing around.
There was a fumble finger in an earlier post about looking for UTC in two files in /etc; this is the correction:
Code:
grep UTC /etc/* 2>/dev/null
adjtime:UTC
hardwareclock:UTC
You should have that if for no other reason than eliminating any possible goofy (technical term) stuff.
I used the standard Slackware /etc/ntp.conf file as installed (no edits whatsoever in it).
I edited and added the server section:
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.ca.pool.ntp.org
server 1.ca.pool.ntp.org
server 2.ca.pool.ntp.org
I stopped my running NTP daemon and started it using this /etc/ntp.conf file (remember, I'm in the US but I used Canadian pool servers).
After about five minutes,
Code:
remote refid st t when poll reach delay offset jitter
==============================================================================
127.127.1.0 .LOCL. 10 l 774 64 0 0.000 0.000 0.000
+198.50.145.138 206.108.0.131 2 u 46 128 377 621.634 21.428 81.650
+198.27.65.66 142.3.100.2 2 u 106 128 377 650.440 36.507 125.289
*142.165.36.190 142.3.100.2 2 u 117 128 377 649.398 -3.896 37.421
I'm synchronized. It works.
The working ntp.conf.txt file is attached for you to try -- do not edit it in any way.
To use it, as root
Stop the NTP daemon: /etc/rc.d/rc.ntpd stop
Create a clean, empty NTP log file (if it does not already exist): rm /var/log/ntp.log; touch /var/log/ntp.log
Back up your existing conf file: cp /etc/ntp.conf /etc/ntp.conf.bak
Save the attachment on your system.
Copy the attached file to /etc: cp ntp.conf.txt /etc/ntp.conf
Note: the following line will set the clock using the servers in /etc/ntp.conf it might take a couple of minutes to do so because it will sample the three pool servers, set the clock and exit.
Set the clock: ntpd -g -q
Start the NTP daemon: /etc/rc.d/rc.ntpd start
If you immediately execute ntpq -pn, you should see the .LOCL. and three external servers. At this point you're not synchronized (there will be an asterisk at the head of the .LOCL. line.
Wait about five minutes (maybe a little longer) and you should see something similar to this:
Code:
ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
127.127.1.0 .LOCL. 10 l 774 64 0 0.000 0.000 0.000
+198.50.145.138 206.108.0.131 2 u 46 128 377 621.634 21.428 81.650
+198.27.65.66 142.3.100.2 2 u 106 128 377 650.440 36.507 125.289
*142.165.36.190 142.3.100.2 2 u 117 128 377 649.398 -3.896 37.421
After a while, if you view the log, you should see something similar to this:
Code:
cat /var/log/ntp.log
1 May 07:51:17 ntpd[768]: LOCAL(0) 8011 81 mobilize assoc 60152
1 May 07:51:17 ntpd[768]: 198.50.145.138 8011 81 mobilize assoc 60153
1 May 07:51:20 ntpd[768]: 198.27.65.66 8011 81 mobilize assoc 60154
1 May 07:51:21 ntpd[768]: 142.165.36.190 8011 81 mobilize assoc 60155
1 May 07:51:21 ntpd[768]: 0.0.0.0 c016 06 restart
1 May 07:51:21 ntpd[768]: 0.0.0.0 c012 02 freq_set kernel -12.214 PPM
1 May 07:51:21 ntpd[768]: LOCAL(0) 8024 84 reachable
1 May 07:51:21 ntpd[768]: LOCAL(0) 903a 8a sys_peer
1 May 07:51:21 ntpd[768]: 0.0.0.0 c515 05 clock_sync
1 May 07:51:23 ntpd[768]: 198.50.145.138 8024 84 reachable
1 May 07:51:24 ntpd[768]: 198.27.65.66 8024 84 reachable
1 May 07:51:25 ntpd[768]: 142.165.36.190 8024 84 reachable
1 May 07:54:41 ntpd[768]: 142.165.36.190 903a 8a sys_peer
1 May 07:56:53 ntpd[768]: 198.50.145.138 943a 8a sys_peer
1 May 07:59:05 ntpd[768]: 142.165.36.190 941a 8a sys_peer
1 May 08:03:05 ntpd[768]: LOCAL(0) 8043 83 unreachable
1 May 08:21:13 ntpd[768]: 198.27.65.66 943a 8a sys_peer
The line above
Code:
1 May 08:03:05 ntpd[768]: LOCAL(0) 8043 83 unreachable
is where the daemon synchronized to, on the line below that
Code:
1 May 08:21:13 ntpd[768]: 198.27.65.66 943a 8a sys_peer
This all presupposes that you have not edited /etc/rc.d/rc.ntpd; if you did, you might want to remove any edits before starting the daemon.
If this works, we can change /etc/ntp.conf to use tos orphan if you want to, just don't do that right now, let's start with a know good configuration file, eh?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
