timekeeping on jail servers

[Bill Moran]

In response to John Webster <jwebster at es.net>:
> 
> --On Friday, December 21, 2007 13:51:29 -0500 Bill Moran <wmoran at potentialtech.com> wrote:
> 
> > In response to John Webster <jwebster at es.net>:
> 
> >> > 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.
> > 
> 
> My suggestions are based on the OP about ntpd binding to everything.
> 
> 
> > 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.
> 
> Just out of curiosity, why run it more that once a day? Or for
> that matter every couple of days?

There is the matter of "how accurate does your time really need to be?"

I worked a place where many computers were used for employees to clock
in/clock out.  Synchronizing time once a day, the clocks would drift
enough that employees who showed up on time and left on time would
appear to have arrived late and/or left early (up to 5 minutes a day
drift).

Of course, this is hardware-dependent and even environmentally dependent
(computers connected to clean power sources with consistent environmental
temperature seem to keep more accurate time in my experience)

Other common applications are even more sensitive.  If you run NFS or
other file sharing, you can run into all sorts of ugliness if time skews
more than a few seconds.  Web applications can be notoriously buggy if
either the server or the client is off by more than a few seconds.

With all those potential problems looming, why would you use anything
other than a full-blown ntp daemon?  I just can't see the excuse for
making up other solutions.

-- 
Bill Moran
http://www.potentialtech.com