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.
|
Quote:
|
Quote:
The philosophy is that it's up to you to decide what you want running rather than jamming everything down your throat whether you want it or not; it's your system, your way. Hope this helps some. |
Based on my experience with 12.0 and ntp, I'm almost sure I chose ntp. Somewhere I wrote down the default selections and the options such as I finally left them. I was about to pass these notes to some file, but I have not done it yet and the paper will have to wait till I find it. I like your "Oh".
|
1 Attachment(s)
OK. This is from /var/log/ntp.log (see attachment). The output speaks for itself. The daemon was running while logging (now it does not), it was started by someone, hence it's executable, and post #1 shows the configuration file. Any diagnostics possible?
|
Your /etc/ntp.conf looks fine -- one thing you might want to change, though, is add or edit this to allow multicasting (it's not absolutely necessary but may help):
Code:
multicastclient 224.0.1.1 Code:
22 Jan 14:37:41 ntpd[2003]: Listen normally on 5 multicast 224.0.1.1 UDP 123 Code:
cat /etc/npt/drift Code:
su - Code:
/usr/sbin/ntpq -pn Code:
date Code:
su - Code:
su - If your system was rebooted at some point (it looks as if it was given the log entry) Code:
22 Jan 03:20:47 ntpd[1588]: ntpd exiting on signal 15 Anyway, what happens when you shut the system down is that the system clock time is written to the hardware clock, which is kept running by a small battery on the motherboard. When the system is booted, that time is read from the hardware clock and the system clock is set to that time. The system clock is not an actual "clock;" it's timer executed by the kernel. The hardware clock is an actual clock chip (something like the ones in a wristwatch) that is kept running by the battery (system time is independent of the hardware clock after the system boots). You've said that you were running Slackware 12? On the same hardware? It's quite possible that you've got a dead battery (Slackware 12 goes back a few years). If that's the case, the hardware clock isn't keeping time and, when the system boots, the system clock gets set to some who-knows-what time. You can tell if this is a problem by running date, write that down, reboot but enter the BIOS instead of letting the system boot. Check the hardware clock time in the BIOS and compare the time to what the date utility showed you. Hope this helps some. |
tronayne: thank you very much. Some points:
LOCAL(0) MMMM NN unreachable. A few more entries and then, it panics. That is, all this within a machine session, I mean, before turning off the machine. So, any battery problem is out of question. This is all i can say for now. |
Those LOCAL unreachable messages aren't an error -- they frequently appear in the log:
Code:
grep LOCAL ntp.log Code:
23 Jan 06:47:49 ntpd[2003]: ntpd exiting on signal 1 The whole thing about the battery is, of course, moot (new hardware, should be a good battery one would think). By the way, what's the value stored in /etc/ntp/drift? |
Nothing odd in /var/log/messages.
Code:
semoi@darkstar:~/sma_/info/clear/cl1/correo/lvb$ cat /etc/ntp/drift |
OK, so what happens if you stop the daemon and let the clock free run for, say, 24 hours?
Just do Code:
su - Also, just a thought here, do your Ethernet connections go down at night? And, those LOCAL(0) 8043 83 unreachable messages? Those appear when you're synchronized to the three external time sources you have defined. When you run /usr/sbin/ntpq -pn the LOCALHOST line is displayed without an asterisk or plus sign when the external timeservers are active, that's why the message. Hope this helps some. |
So LOCAL(0) is the hardware clock, or some interrupt driven by the hardware clock (aka hardware timer).
Quote:
Quote:
|
Local(0) is the fudge server defined in the ntp.conf and is the system clock. It is a used as fallback when the all other NTP servers (as defined in ntp.conf) or the network become unusable or unreachable. While NTP is running it will update the hardware clock periodically but it not used for anything else.
|
Ahhh!
|
If you have the same situation in ntpq and version is 4.2.6p5.
Maybe is ipv6 port is disabled. I don't know why ntpq check ipv6 first in this version. you have 2 options. 1.turn on ntp listen ipv6, you can modify /etc/sysconfig/ntp and remove -4 parameter. 2.use ntpq -4pn |
I had a very similar problem, all the same symptoms - server not starting, clock 1 hour out and nothing in the logs. The only difference was that it was intermittent. I power up my desktop every morning and the problem would occur once maybe twice a week. After a couple of months the problem disappeared as if by magic. The only thing I could think of was there was a faulty time server out there as I was using pool servers. Maybe commenting out the servers in your ntp.conf in turn may help to diagnose your fault.
|
Keep in mind that NTP throws out "bad" time servers. It constantly evaluates the pool servers and will replace one or more if they're deemed unusable. If you have defined your pool servers as simply pool.ntp.org NTP will evaluate looking for those electrically close to you and will use the best one it can find.
It's a good idea to specify three (that's all out need) pool servers in /etc/ntp.conf like this: Code:
# NTP server (list one or more) to synchronize with: Make sure your locale is correct -- see what it is with locale: Code:
locale The US goes on stupid time... uh, daylight time... much earlier than other countries an stays on daylight time longer than any other countries (that I know of anyway). The US went off daylight on 2 November. If you happen to be in the UK and your locale is US, well, there's your one hour off. It's also a Good Idea to set your hardware clock to UTC and get it set to the correct time in the BIOS. You want to run timeconfig to get things in order. On boot, your hardware clock is read to initialize the system (software) clock prior to when NTP starts. It typically takes about five minutes for NTP to synchronize to a "good" pool server, that's normal. It even takes about five minutes when you have one system severing time to others on your LAN (I have two data base servers that synchronize with my main work station which serves time to them and it still takes about five minutes for them to synchronize when they or the main server is rebooted for some reason or other). You really do want the LOCL server specified. The comments at the top of /etc/ntp.conf tell you why: Code:
# Undisciplined Local Clock. This is a fake driver intended for backup Once NTP is synchronized, where you get Code:
/usr/sbin/ntpq -pn On system shutdown, the system time is written to the hardware clock (keeping that up to date as it were). And the CMOS battery keeps that running while the power is off for the next boot initializing the system (software) clock. It seems to me, I can't remember exactly what or why, that IPv6 should not be used (really for anything if I remember correctly). Can't prove that right now (I'll look it up though) but it just rings bells about not using IPv6. [EDIT] Forgot to mention that NTP will not synchronize if your time (either the hardware clock when booted or the software clock that has drifted before you start NTP) more than 1,000 seconds (roughly 16 minutes). If NTP does not synchronize, check your software clock and your hardware clock and set them close to real time before starting NTP. After it synchronizes, both clock will be set correclty. [/EDIT] Hope this helps some. |
All times are GMT -5. The time now is 12:58 AM. |