In response to John Webster <[EMAIL PROTECTED]>:
> 
> --On Friday, December 21, 2007 13:24:40 -0500 Bill Moran <[EMAIL PROTECTED]> 
> wrote:
> 
> > In response to John Webster <[EMAIL PROTECTED]>:
> >> 
> >> --On December 21, 2007 11:23:03 AM -0500 Bill Moran <[EMAIL PROTECTED]> 
> >> wrote:
> >> 
> >> > In response to shinny knight <[EMAIL PROTECTED]>:
> >> > 
> >> > The reason that is not recommended is that it results in sudden steps
> >> > of the clock.  Occasionally, these steps go backwards.  Software that
> >> > is very sensitive to time changes (make processes, database servers,
> >> > anything doing calculations WRT time) can break, crash, or work
> >> > inaccurately.
> >> 
> >> ntpdate -B should slew the time slowly.  (According to the manpage.)
> > 
> > Not generally suitable for cron because it can take longer to slew
> > than it does for the next cron execution to occur, which would then
> > result in multiple ntpdate programs fighting each other (not sure
> > what the effect of this would be).
> 
> If I were doing it I would write a script with locking in order
> to ensure multiple jobs don't fight.  Simple.

Umm ....

At that point, why not just run ntpd?  You've basically replaced it
with a script anyway.

Besides, it's not that easy.  As Chuck pointed out, ntpdate calls
adjtime() and exits, which means an adjustment might already be in
progress when you you call it again.  I don't know if ntpdate checks
the return pointer from adjtime() to avoid multiple adjustment
requests.

-- 
Bill Moran
http://www.potentialtech.com
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to