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 _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"