If you server's time differs from true time by more than 1000 seconds, NTP will fail to attempt to synchronize. Verify _your_ time with 'date -u'. Remember, NTP uses universal (UTC) time. Your server displays local time according to your TZ setting.
Not too long ago we found our systems getting out of time sync. We had one internal server (serverTime) sync to an external internet-time-server. Hadn't noticed that the external internet-time-server had been removed, so all our other internal servers that sync to(serverTime) began to get farther and farther off.
I'd suggest starting from the beginning to fix time (...that sounds so Isaac Asimov..). Stop xntpd Confirm and assign internal server(s) to external time source. Confirm your primary internal time server(s) are now syncing properly to external time source(s).
Once the above looks good....stop/start time on your secondary servers that sync internally to your internal primary time server(s).
...and like Jim said - if they are too far off, you'll have to manually reset the time to something closer. But if your going forward in time - not so bad. Do NOT go backwards in time, as you could have database issues. Co-ordinate for those situations.
NTP will not correct time differences more than a few hours.
The message is clear: 8 Jun 16:01:32 ntpdate[9603]: no server suitable for synchronization found
The server configured is not suitable for Unix ntp.
I know Windows Server 2000 is not appropriate as a time server without patches.
Most firewalls close the ntp port as well.
SEP
Steven E Protter Owner of ISN Corporation http://isnamerica.com http://hpuxconsulting.com Sponsor: http://hpux.ws Twitter: http://twitter.com/hpuxlinux Founder http://newdatacloud.com
kmsemng1:/>grep -i ntp /var/adm/syslog/syslog.log Jun 28 17:24:04 kmsemng1 xntpd[1318]: tickadj = 625, tick = 10000, tvu_maxslew = 61875 Jun 28 17:24:04 kmsemng1 xntpd[1318]: precision = 6 usec Jun 28 17:28:21 kmsemng1 xntpd[1318]: synchronized to 10.36.126.1, stratum=2 Jun 28 17:28:21 kmsemng1 xntpd[1318]: time reset (step) 0.658318 s Jun 28 17:28:21 kmsemng1 xntpd[1318]: synchronisation lost Jun 28 17:33:41 kmsemng1 xntpd[1318]: synchronized to 10.36.126.1, stratum=2 Aug 31 03:38:06 kmsemng1 xntpd[1318]: synchronisation lost Aug 31 10:06:18 kmsemng1 xntpd[1318]: synchronized to 10.36.126.1, stratum=2 Nov 6 18:10:30 kmsemng1 xntpd[1318]: synchronisation lost Nov 6 18:29:42 kmsemng1 xntpd[1318]: synchronized to 10.36.126.1, stratum=2 Jan 1 01:00:01 kmsemng1 xntpd[1318]: leap second occurred, stepped time back 1 second May 16 21:46:12 kmsemng1 xntpd[1318]: synchronisation lost May 17 00:29:17 kmsemng1 xntpd[1318]: synchronized to 10.36.126.1, stratum=2 May 17 03:50:21 kmsemng1 xntpd[1318]: synchronisation lost May 18 12:45:36 kmsemng1 xntpd[1318]: synchronized to 10.36.126.1, stratum=2 May 18 15:24:00 kmsemng1 xntpd[1318]: synchronisation lost May 22 13:23:07 kmsemng1 xntpd[1318]: synchronized to 10.36.126.1, stratum=2
that means the ntp client is synchronised, if you don't have this entries in your syslog, them the host is not synchronyzing the time.
There's no reason to try anything else. The NTP server listed in /etc/ntp.conf does not exist, is not an NTP server or has locked you out. Until ntpq -p works, xntpd will do nothing.
Start by locating a working NTP server using ntpq. Kill any xntpd process first. ALWAYS use: ntpq -p 12.34.56.78 (the IP address, not the hostname) and keep trying all the NTP servers you have. Also use traceroute 12.34.56.78 to see if you are blocked by routers. Also check with the networking department. Many firewalls and routers are configured as NTP servers but no one ever tells the sysadmins.
Once ntpq is working, then you can configure xntpd. NOTE: The start/stop script for xntpd will 'jump' the time rather then slowly change it. Make sure your time sensitive applications are not running when you try to get xntpd going. ntpdate has an option to slowly move the time to be in sync (ntpdate -B).
