Yes, I have been stopping/starting ntpd as needed to run ntpdate, since the problem is that despite ntpd thinking it is running, the time continually was drifting out of sync. On the order of 3-5 minutes in a week! Doing an ntpdate was usually re-syncing the clocks. I currently have the following in my ntp.conf: (14:58 server:~) grep -v ^# /etc/ntp.conf |grep -v ^$ restrict default nomodify server 192.168.1.50 server 192.168.1.52 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 So now, I wait a few days to see if the clocks will drift out of sync. If not, I will let the list know. :) Regards, Gavin McDonald. PS, I too, like top-posting. *dons fire-proof suit* -----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
