Re: Time off by -5 hours

(CC: Frank Tegtmeyer and Wayne Marshall, see below)

> > >   We have several servers set up with a hybrid between this:
> > > 
> > > http://fte.tegtmeyer.net/djbware/clockspeed_setup.html
> > > 
> > >   and the very similar information at thedjbway.org, which seems to be
> > > offline right now.
> > > 
> > >   All our servers except two have the correct time; the two that are
> not
> > > correct are both off by -5 hours.  I am guessing (but have no proof)
> that
> > > they lost synch during the DST time change last Sunday.
> > > 
> > >   I am tempted to just restart all the clockspeed stuff and see if it
> > > catches
> > > the right time (we configured the above system to get it from NTP), but
> > I'm
> > > afraid that that will mask the problem, so I am hoping someone might
> have
> > > some pointers of where this might be caused before I just try to reset
> > the
> > > time.
> > > 
> > >   Oh, and the timezone on the machines appears correct.
> > 
> > Looking at the log files, the NTP server we chose to use in our config
> file
> > apparently has changed or is otherwise not available these days:
> > 
> > sntpclock: warning: unable to read clock: timed out
> > sntpclock: warning: unable to read clock: timed out
> > sntpclock: fatal: time uncertainty too large
> > clockadd: fatal: data split across packets
> > 
> > However, all our servers are getting this error; why would only two of
> them
> > have lost five hours?
> 
> Still not found an answer to the five hour loss, but what was interesting
> was
> that when I updated our "clockctl" config file with an active NTP server
> (anyone have an enhanced version of this approach that allows for using a
> list of NTP servers so we can have some fallback?), 

A little bit of an aside, but we just hacked up a solution to this
paranthetical.  Our config file for this setup now looks like this: 

CLOCK_IPS[0]="999.888.777.666"
CLOCK_IPS[1]=`dnsip abc.def.edu | sed 's/ .*//'`
CLOCK_IPS[2]=`dnsip example.com | sed 's/ .*//'`
CLOCK_IPS[3]="666.777.888.999"

We use DNS to resolve the ones that state to use DNS according to their
listing with ntp.isc.org and just IPs for all others.

And our "clockctl" will now start looking for a responsive NTP server
starting at a random point in the array of NTP servers and only try to update
time with a given server if it is currently responding to NTP requests.  We
added this function (and we call it, of course, before we process anything
else in this script):

# choose which CLOCK_IP to use
#
choose_clock_ip()
{
  echo "Looking for an active master server..."

  # start in random place in array
  MAX=${#CLOCK_IPS[@]}
  START=$RANDOM
  let "START %= $MAX"  # gives random number less than $MAX
  J="$START"

  CLOCK_IP=0
  while test 1; do

      echo "Trying ${CLOCK_IPS[$J]}..."
      ${CLOCKSPEED_BIN}/sntpclock "${CLOCK_IPS[$J]}" > /dev/null
      if [ $? = 0 ]; then
          CLOCK_IP="${CLOCK_IPS[$J]}"
          echo "Will use ${CLOCK_IPS[$J]}"
          break
      fi

      # loop control...
      J=`expr $J + 1`

      if [ $J = $START ]; then
          break

      elif [ $J = $MAX -a $START = 0 ]; then
          break

      elif [ $J = $MAX ]; then
          J=0
      fi

  done

  if [ $CLOCK_IP = 0 ] ; then
      echo "$0: server error: no master servers were reachable"
      exit 1;
  fi
}



Still looking for the five hour mystery, however......



> the machine said that
> it
> had the correct time all along.  As shown by the date command run just
> prior,
> that was not the case.  Why/how would this happen?  Here is the actual
> series
> of events:
> 
> # date
> Thu Nov  3 17:15:59 PST 2005
> # /etc/clockspeed/clockctl sync
> Setting system clock with master server at www.xxx.yyy.zzz:
> before: 2005-11-03 22:17:28.182072000000000000
> after:  2005-11-03 22:17:28.182235999833472072
> # date
> Thu Nov  3 22:17:41 PST 2005
> 
> That is rather odd, is it not?




		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com