The time diference is too great between the server your running ntpq -p on and the server your trying to sync to. use the command ntpdate -d -v to see how great the difference is. You need to set the field NTPDATE_SERVER= in /etc/rc.config.d/netdaemons and reboot, then the time will be sync'd in one go between the 2 servers and now ntpq -p will work.
Im from Palmerston North, New Zealand, but somehow ended up in London...
Check to make sure that you have a valid address in the ntp.conf file. If a modification has been made or is going to be made, stop/start the ntp process to have the ntp.conf file reread.
You will want to ensure that you can resolve the address in the ntp.conf file. Can it be pinged? cvan you nslookup by hostname as well as IP?
Is the server you are sync-ing to in a DMZ? If so, you probably have a routing issue but be careful, adding routes to make ntp work may defeat the purpose of the DMZ.
The University of Delaware has a ntpfaq that you may find useful. I do not have the address right not but you can search the forums for 'ntp' and in a couple of the previous posts will be the address.
address already in use sounds like the xntpd process is already running. Can you do a ps -ef | grep xntp to see if its running ? If you need to stop and restart it use /sbin/init.d/xntpd stop (or start). Once its running ntpq -p should work.
Im from Palmerston North, New Zealand, but somehow ended up in London...
This is kind of an old thread, so writing this may be futile, but I'm having the same problem as Rakotoarison. The reason that ntpq is unhappy is that the xntpd daemon isn't even running? His last post shows essentially the same error I'm getting.
It isn't because there is already an ntp daemon running. I checked for that. I thought perhaps something else was using that port and used netstat and lsof to confirm that that wasn't the case either. Does anyone know how to see what might be going on with the address mentioned in the error? Because, the real problem here is that xntpd refuses to start because it thinks that the address it wants to bind is already taken. It isn't taken by another ntp process because there aren't any running. I just don't know how to check the address and find out what did grab it.
Seems that if you can't find reference to the port with 'netstat -an', 'lsof', and if neither 'xntpd' nor 'ntpdate' is running, then I would guess that the socket is in some limbo state from a previous instance that is no longer viable. Does a reboot cure the problem?
I've yet to try that. This machine is at the core of the production environment and it usually requires much coordination and an act of congress to be allowed a reboot. I puzzled over the address it was complaining about (C001FFFF) until I broke it into four pieces and converted the hex to 192.1.255.255, which WOULD be a broadcast address for one of the networks on this host. Is that valid?
