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.
Reinstalled slackware-14.1 last night, and did slackpkg upgrade-all.
Put your .conf file in ( I use the mv command )and did ntpq -pn twice, waiting 8 minutes.
Got this: # ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
*127.127.1.0 .LOCL. 10 l 33 64 377 0.000 0.000 0.000
206.186.121.125 .INIT. 16 u - 64 0 0.000 0.000 0.000
142.137.247.109 .INIT. 16 u - 64 0 0.000 0.000 0.000
208.80.96.70 .INIT. 16 u - 64 0 0.000 0.000 0.000
bash-4.2#
I did not do
grep UTC * 2>/dev/null
adjtime:UTC
hardwareclock:UTC
so used
because I know not how or where.
So I used timeconfig to set hardware clock to UTC (which I still think of as GMT).
Then
# /etc/rc.d/rc.ntpd restart
Stopping NTP daemon...
Starting NTP daemon: /usr/sbin/ntpd -g
bash-4.2#
and 8 minutes later
# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
*127.127.1.0 .LOCL. 10 l 18 64 377 0.000 0.000 0.000
198.27.65.66 .INIT. 16 u - 128 0 0.000 0.000 0.000
206.108.0.131 .INIT. 16 u - 128 0 0.000 0.000 0.000
205.204.93.138 .INIT. 16 u - 128 0 0.000 0.000 0.000
bash-4.2#
Starting Nmap 6.40 ( http://nmap.org ) at 2014-05-01 11:13 EDT
Nmap scan report for 0.ca.pool.ntp.org (129.128.5.211)
Host is up (0.0018s latency).
Other addresses for 0.ca.pool.ntp.org (not scanned): 199.182.221.110 208.80.96.96 72.51.27.50
rDNS record for 129.128.5.211: time2.srv.ualberta.ca
PORT STATE SERVICE
123/udp open|filtered ntp
Nmap scan report for 1.ca.pool.ntp.org (208.80.96.70)
Host is up (0.0012s latency).
Other addresses for 1.ca.pool.ntp.org (not scanned): 67.215.197.151 199.182.221.110 206.108.0.132
rDNS record for 208.80.96.70: ellen.linuxgeneration.org
PORT STATE SERVICE
123/udp open|filtered ntp
Nmap done: 2 IP addresses (2 hosts up) scanned in 2.51 seconds
bash-4.2#
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
On my (working) 14.1 system:
Code:
nmap -p123 -sU 0.ca.pool.ntp.org 1.ca.pool.ntp.org
Starting Nmap 6.40 ( http://nmap.org ) at 2014-05-01 11:43 EDT
Nmap scan report for 0.ca.pool.ntp.org (198.50.145.138)
Host is up (0.0038s latency).
Other addresses for 0.ca.pool.ntp.org (not scanned): 206.186.121.118 206.108.0.131 206.108.0.132
rDNS record for 198.50.145.138: srv4.hrtech.de
PORT STATE SERVICE
123/udp open|filtered ntp
Nmap scan report for 1.ca.pool.ntp.org (206.108.0.132)
Host is up (0.0034s latency).
Other addresses for 1.ca.pool.ntp.org (not scanned): 142.137.247.109 198.27.65.66 206.108.0.131
rDNS record for 206.108.0.132: ntp2.torix.ca
PORT STATE SERVICE
123/udp open|filtered ntp
Nmap done: 2 IP addresses (2 hosts up) scanned in 1.02 seconds
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
Code blocks are, on a new line a left bracket ([), the string code, and a right bracket (]) to start. To stop a code block, on a new line, a left bracket ([), a slash (/), the string code, and a right bracket (]). The string can be either code or CODE. It's similar to what "wrap [QUOTE] tags around select text," that yellow-page symbol at the top of the reply window. The tags, code or QUOTE, don't have to be on a new line, but it's a little easier to paste select text that way (for me, maybe not for you, do what you're comfortable with).
Looking at your log entries, it looks like you are getting synchronized to LOCAL (lines like these):
Code:
1 May 13:30:37 ntpd[4436]: 0.0.0.0 c016 06 restart
1 May 13:30:37 ntpd[4436]: 0.0.0.0 c012 02 freq_set kernel 0.000 PPM
1 May 13:30:38 ntpd[4436]: LOCAL(0) 8024 84 reachable
1 May 13:30:38 ntpd[4436]: LOCAL(0) 903a 8a sys_peer
1 May 13:30:38 ntpd[4436]: ntpd: time slew +0.000000 s
1 May 13:31:11 ntpd[4448]: LOCAL(0) 8011 81 mobilize assoc 40671
1 May 13:31:11 ntpd[4448]: 208.80.96.70 8011 81 mobilize assoc 40672
1 May 13:31:11 ntpd[4448]: 199.85.124.148 8011 81 mobilize assoc 40673
1 May 13:31:11 ntpd[4448]: 199.182.221.110 8011 81 mobilize assoc 40674
1 May 13:31:11 ntpd[4448]: 0.0.0.0 c016 06 restart
1 May 13:31:11 ntpd[4448]: 0.0.0.0 c012 02 freq_set kernel 0.000 PPM
1 May 13:31:12 ntpd[4448]: LOCAL(0) 8024 84 reachable
1 May 13:31:12 ntpd[4448]: LOCAL(0) 903a 8a sys_peer
1 May 13:31:12 ntpd[4448]: 0.0.0.0 c515 05 clock_sync
It also looks like you reset the clock (with ntpd -b -g -q) each time you stopped it -- don't really need to do that every time.
Now, what you should be seeing is this:
Code:
1 May 11:27:17 ntpd[20263]: 0.0.0.0 c016 06 restart
1 May 11:27:17 ntpd[20263]: 0.0.0.0 c012 02 freq_set kernel -19.244 PPM
1 May 11:27:18 ntpd[20263]: LOCAL(0) 8024 84 reachable
1 May 11:27:18 ntpd[20263]: LOCAL(0) 903a 8a sys_peer
1 May 11:27:18 ntpd[20263]: 0.0.0.0 c515 05 clock_sync
1 May 11:27:20 ntpd[20263]: 142.54.185.82 8024 84 reachable
1 May 11:27:21 ntpd[20263]: 54.235.96.196 8024 84 reachable
1 May 11:27:21 ntpd[20263]: 173.208.234.242 8024 84 reachable
1 May 11:30:37 ntpd[20263]: 173.208.234.242 903a 8a sys_peer
1 May 11:31:40 ntpd[20263]: 54.235.96.196 943a 8a sys_peer
1 May 11:32:48 ntpd[20263]: 173.208.234.242 941a 8a sys_peer
1 May 11:39:02 ntpd[20263]: LOCAL(0) 8043 83 unreachable
You're not seeing these lines in the log:
Code:
1 May 11:27:18 ntpd[20263]: LOCAL(0) 903a 8a sys_peer
1 May 11:27:18 ntpd[20263]: 0.0.0.0 c515 05 clock_sync
1 May 11:27:20 ntpd[20263]: 142.54.185.82 8024 84 reachable
1 May 11:27:21 ntpd[20263]: 54.235.96.196 8024 84 reachable
1 May 11:27:21 ntpd[20263]: 173.208.234.242 8024 84 reachable
1 May 11:30:37 ntpd[20263]: 173.208.234.242 903a 8a sys_peer
1 May 11:31:40 ntpd[20263]: 54.235.96.196 943a 8a sys_peer
1 May 11:32:48 ntpd[20263]: 173.208.234.242 941a 8a sys_peer
1 May 11:39:02 ntpd[20263]: LOCAL(0) 8043 83 unreachable
Don't pay any attention to the addresses in the above, they're from my system log.
What does
Code:
ntpq -pn
show you? Do you see .LOCL. and three numeric addresses? Perhaps, leaving the NTP daemon running for now, do that and post the output, please.
What do these two commands show you:
Code:
date
hwclock -r
date shows the system clock time (the software clock), hwclock -r show you the hardware clock time. The output will look like this:'
Code:
date
Thu May 1 14:52:11 EDT 2014
hwclock -r
Thu 01 May 2014 02:52:42 PM EDT -0.256338 seconds
Yeah, one's in 24-hour and the other is in 12-hour but don't worry about that -- are they the same time?
xfce weirdness - permissions mysteriously changed for /etc/rc.d/rc.ntpd so root was denied access. I did a chmod +x and installed shorewall; if I've been listening to audio file and it ends and I don't close the player .txt files have all shown as image files that must be opened with xine, gets nonsense. Trying to open them with kwrite results in nonsense.
There was nothing wrong with the installed setup of time or ntp or anything else, so I think the problem must be elsewhere, and know not what to look for.
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
It sure does look like a communications problem -- NTP doesn't seem to be able to reach those external time servers. Can you
Code:
ping -c 5 206.108.0.132
There is one other possibility; your hardware clock is too far off for NTP to sync to it. Recall that, when NTP is started, it reads the time from the hardware clock and uses that to set the system clock (and vice-versa on shutdown)? That "too far off" is 1,000 seconds (generally) but can be as little as 5- 6 or so minutes. When you set the clock with ntpd -b -g -q, you're setting the system (software) clock to the correct time and the hardware clock will overwrite that when the daemon starts (dang it).
So, here might be a good test:
Stop NTP
Set the system clock: ntpq -g -q
Check the system clock: date
Check the hardware clock: hwclock -r
What is the difference between the two?
And, let's see, Shorwall is a firewall? Do you have to explicitly open ports (like 123)?
All the files in /etc/rc.d are owned and group root.
/etc/rc.d/rc.ntpd is owned and group root and it is executable (as are some, not all, others).
Your might want to
Code:
su -
chown root.root /etc/rc.d/rc.ntpd
chmod 755 /etc/rc.d/rc.ntpd
I do not know anything about Shorewall and don't know why I would want to.
You may want to do the "secret fix" (read: kludge) for Xfce problems. Logged in as you, in your home directory,
Code:
rm -r .cache
Fixes a lot of Xfce weirdness (but don't do it all the time).
# ping -c 5 206.108.0.132
PING 206.108.0.132 (206.108.0.132) 56(84) bytes of data.
64 bytes from 206.108.0.132: icmp_seq=1 ttl=246 time=1316 ms
64 bytes from 206.108.0.132: icmp_seq=2 ttl=246 time=657 ms
64 bytes from 206.108.0.132: icmp_seq=3 ttl=246 time=678 ms
64 bytes from 206.108.0.132: icmp_seq=4 ttl=246 time=668 ms
64 bytes from 206.108.0.132: icmp_seq=5 ttl=246 time=677 ms
--- 206.108.0.132 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3997ms
rtt min/avg/max/mdev = 657.957/799.651/1316.252/258.406 ms, pipe 2
Code:
# date
Thu May 1 19:07:02 EDT 2014
bash-4.2# hwclock -r
Thu 01 May 2014 07:07:06 PM EDT -0.719191 seconds
so there is no significant difference between clocks.
I'm used to the look of ntp in gkrellm/eth0 when it is working right, and this looks like ntpd is sending a command that gets no reply from server(s), except for when ntpd is first started.
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
So, when you ran date and hwclock it was 19:07, yet the time stamp on your post is 19:21, a 14 minute difference (which may be significant). NTP probably won't initialize with that much difference, and it may explain why your don't see any refid in the ntpq -pn display. Might want to do
date
hwclock -r
and post it immediately just to see.
Just for grins, how are you connected to your satellite interface box? I mean, you're using a wi-fi connection, is that provided by the interface or is there a box connected to the Ethernet port on the interface? If so, can you look at settings in the wi-fi gadget?
I'm asking because routers (and, possibly wi-fi) don't always pass every port and you have to enable the one's you want (I have to in my Linksys router). If the gadget (if there is one) is not passing port 123 UDP, that's going to be the problem.
The other potential problem is if your network connections are defaulting to IPv-6. But I don't know how to determine that (gotta do some looking-up).
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.
Regret late reply -- yes, I am too close to CHU transmitters to hear it clearly.
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
Quote:
Originally Posted by WilliamS
I can't see that ntp could know or care when I post results of shell commands?
Nothing to do with NTP, has to do with whether your hardware clock is close enough to the correct time for NTP to synchronize (recall that when the system starts the system time is initialized from the hardware clock). The only reason I questioned was the time difference from your running date and hwclock to the time-stamp on the post. Sorry if there was any confusion.
Something you may want to check is boot your system into the BIOS and check that the time is correct referenced to CHU, WWV or whatever time service. If I remember correctly those radio broadcasts are UTC and that's what your hardware clock should be set to. What the heck, can't hurt to check it just in case.
Quote:
Originally Posted by WilliamS
No wifi here, just cable through a modem.
If you can get to the modem control panel and check to see if port 123 UDP is being passed or blocked. From all the ntpq displays it looks like that is the problem; you're not seeing the time transmission from the pool servers.
Do you have a IPTABLES or some other form of firewall running? Is there any settings having to do with port 123 UPD?
Never referenced time to WWV or CHU, just set it during installation of the OS and no problems.
I have no access to the modem control.
nmap scan of port 123 shows as it should be, same as before.
I found a macro for ntp in my firewall and enabled it to make sure that port is working; no difference in anything detected.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
