ntpq -p: Connection refused
1 Attachment(s)
Slackware 14.0
Hi: The system time is always lagging by a multiple of one hour. But see this: Code:
root@darkstar:~# ntpq -p |
Sounds like the server isn't running -- do you get something like this:
Code:
fubar-root-/root: ps -ef | grep ntpd |
Code:
root@darkstar:~# ps -ef|grep ntp |
|
Quote:
Code:
root: chmod 755 /etc/rc.c/rc.ntpd Code:
root: /etc/rc.d/rc.ntpd start Oop! Forgot. Paste this into your browser: /usr/doc/ntp-4.2.6p5/html/ntpdate.html if you don't already know how to use ntpdate. Hope this helps some. |
Oh yes, dear Sir. I have used ntpdate before, to set the time, but thank you, thank you very much for the link. Now, I think the problem ought to be somewhere else. Because look at this:[quote]
root@darkstar:/etc# ls -l /etc/rc.d/rc.ntpd -rwxr-xr-x 1 root root 804 2012-07-04 13:38 /etc/rc.d/rc.ntpd* root@darkstar:/etc# [/code] The execute bit is on. On the other hand, I copied rc.ntpd from my 12.0 install to this one (14.0). It's impossible that all of the servers listed there are out of service (I gave a link to it in post #1). |
Either ntp is not starting at boot time or your local clock is off by more then is acceptable and ntp is just quitting. Have you checked the logs? Have you tried manually starting ntpd?
With the current version of ntp the -g option should force the time to be set first prior to the daemon actually trying to synch with a server. This is the same as running ntpdate first then ntpd. If ntp is starting and can't find a time server to synch,it will revert back to the local clock. This is the purpose of the fudge server in the ntp.conf file. |
1) Proceed to an initial adjustement with 'ntpdate' while 'ntpd' is NOT running.
2) Configure /etc/ntp.conf. 3) Activate and start rc.ntpd. Everything is explained in the HOWTO (see link above). Here's my original documentation: http://www.microlinux.fr/slackware/L.../NTP-HOWTO.txt |
Quote:
This is the last line in /var/log/ntp.log: Code:
19 Jan 00:34:58 ntpd[1621]: 0.0.0.0 0617 07 panic_stop +10803 s; set clock manually within 1000 s. Code:
dmesg -s 32000|grep ntpd So, sometimes, at startup, it starts and sometimes not? As it says "set clock manually within 1000 s but the clock lags by double that quantity, I set the clock (date) at 00:34:58 + 1000s (not really now, but in the past). I'll do this: set the clock with ntpdate at current local time and then start the script and watch for at least 24hs to see what happens. |
Quote:
This might be a silly question, but can you ping the servers you specified in ntp.conf? That would tell you that whatever DNS server you use can resolve the addresses and that those time servers are active (eliminating two potential problems). I notice in your atachment that you're logging -- does the log show you anything? Oh, yeah, did you manually create the log file (it doesn't exist by default) with something like Code:
root: touch /var/log/ntp.log |
Quote:
Quote:
|
The ping utility sends echo requests to network hosts. For example, I pinged one of your time servers:
Code:
ping -c 5 3.ar.pool.ntp.org You do need to create that log file. Hope this helps some. |
I'll skim through ping's manual and use it. I do have a log file created, /var/log/ntp.log and I'm watching its contents now, as I have done in the past. I did:
In my past tries to fix the problem, I skipped the second step above. I do not say things are OK now. I have to keep an eye on it and see what happens. And of course, to thank you. Cheers. |
If you give ntpd at least five minutes of run time, it should sync up with one of the servers you have defined in ntp.conf; if you execute
Code:
fubar-trona-/home/trona: /usr/sbin/ntpq -pn In the display above, the asterisk indicates the time server ntpd has synchronized with and the other two are candidates for connection if that server goes away for whatever reason. If you don't see something similar to the above (where a server has synchronized) after 5- to 10 minutes, then you've got a problem to deal with. Once NTP synchronizes, it's going to stay synchronized as long as your network connection remains alive and there are pool servers to connect with. Periodically, NTP will get a batch of new pool servers if the ones it already has start to go bad; it will also occasionally evaluate the connections and drop one that's not good enough and request another from the pool server. Hope this helps some. |
My output to ntpq -pn is quite like yours. Now, I do not understand what happened just after 14.0 installation. All should have worked out of the box, I mean this problem should never have happened.
|
All times are GMT -5. The time now is 10:01 AM. |