Just to summarize the problem I had been having with NTP; It did turn out to be a configuration issue; I made several suggested changes to the ntp.conf file, and time has been in sync on all 4 servers ever since. My final, working config is as follows: (09:54 server1:~) grep -v ^$ /etc/ntp.conf|grep -v ^# restrict default nomodify server <ip of local NTP1> server <ip of local NTP2> server 0.ca.pool.ntp.org server 1.ca.pool.ntp.org server 2.ca.pool.ntp.org driftfile /var/lib/ntp/drift broadcastdelay 0.008 authenticate no I think that the time server was trying unsuccessfully to authenticate the NTP servers, since all I did was remove the 'keys' directive, and add 'authenticate no'. Thanks for everyone who offered their advice, regardless of how they positioned their posting. ;) -G -----Original Message----- From: redhat-list-bounces@xxxxxxxxxx [mailto:redhat-list-bounces@xxxxxxxxxx] On Behalf Of James Cooley Sent: Monday, April 11, 2005 1:44 PM To: General Red Hat Linux discussion list Subject: Re: rh-l] NTP Problems Redux Also, try to keep in mind that if you are running ntpd, you do not need to manually run ntpdate. ntpd will slowly sync your clock to the remote time server clock so as to avoid a drastic time change. Also, ntpd needs to be running for about 15 minutes before your computer will trust its time sources for synchronization. To see the status of the ntp synching, use the command ntptrace. You shouldn't really ever have to run ntpdate manually if ntpd is running. --James Cooley P.S. I like top-posting :) R P Herrold wrote: > On Mon, 11 Apr 2005, Gavin McDonald wrote: > >> I stop the ntpd service, and run ntpdate to check the configs: >> # ntpdate >> 11 Apr 09:52:36 ntpdate[31314]: no servers can be used, exiting >> >> But If I manually specify the servers, it works fine. >> # ntpdate 0.ca.pool.ntp.org 1.ca.pool.ntp.org 2.ca.pool.ntp.org >> 11 Apr 09:52:49 ntpdate[31316]: adjust time server 142.179.100.217 >> offset >> 0.0177 63 sec > > > a manual vs an initscript variance sounds like something in your path > mungeing may be in play, although it may be a drop userid permissions > issue, or that the resolver setup is somehow having issues. I think I > would add the strace package to your server, and wrap the initscript, > capturing the strace and seeing where it falls apart. > > -- Russ Herrold > -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list