timekeeping on jail servers

[Bill Moran]

In response to John Webster <jwebster at es.net>:
> 
> --On Friday, December 21, 2007 13:24:40 -0500 Bill Moran <wmoran at potentialtech.com> wrote:
> 
> > In response to John Webster <jwebster at es.net>:
> >> 
> >> --On December 21, 2007 11:23:03 AM -0500 Bill Moran <wmoran at potentialtech.com> wrote:
> >> 
> >> > In response to shinny knight <sh1nny_kn1ght at yahoo.com>:
> >> > 
> >> > 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