[ntp:questions] galaxy node reboot after ntp time reset

adirtymindisajoyforever getridofthespam at yahoo.com
Mon Jun 4 09:05:13 UTC 2007


On 1 jun, 00:35, "Richard S. Shuford" <shuf... at list.stratagy.IGN0RE-
THlS-PART.com> wrote:
> In message <465EB2CF.2050... at comcast.net>, Richard B. Gilbert wrote:
> |
> | FWIW, xntpd 3-5.93e is ten or twelve years out of date.  The current
> | version of ntpd (the "x" was dropped years ago) is 4.2.4!
>
> The stated version of "xntpd" is what Sun supplies with Solaris 9.
>
> If you look closer at the original posting, you'll see that the version
> string reported by the NTP daemon is precisely "xntpd 3-5.93e+sun".  The
> suffix "+sun" indicates that the code is no longer identical to the original
> UDel "3-5.93e" release, but also contains fixes and private enhancements
> performed by Solaris developers.  (The "sendmail" releases included with
> Solaris show a similar versioning.)
>
> Whereas previously, "adirtymindisajoyforever" had written in message
> <1180599658.144941.231... at u30g2000hsc.googlegroups.com>:
>
>
>
>
>
> > During tests with ntp we ran into the following problem:
> > after [desynchronizing] cluster node clocks 37 seconds, the
> > node reboots after time [adjustment]. An external ntp server
> > is defined.
>
> > The following messages at the time of reboot do not indicate
> > any reason:
> > May 30 14:10:03 krypton xntpd[14642]: [ID 702911 daemon.notice]
> >     xntpd 3-5.93e+sun 03/08/29 16:23:05 (1.4)
> > May 30 14:10:03 krypton xntpd[14642]: [ID 301315 daemon.notice]
> >     tickadj = 5, tick = 10000, tvu_maxslew = 495, est. hz = 100
> > May 30 14:10:04 krypton xntpd[14642]: [ID 266339 daemon.notice]
> >     using kernel phase-lock loop 0041, drift correction 0.00000
> > May 30 14:10:04 krypton xntpd[14642]: [ID 266339 daemon.notice]
> >     using kernel phase-lock loop 0041, drift correction -23599.98047   <<
> > May 30 14:14:46 krypton xntpd[14642]: [ID 774427 daemon.notice]
> >    time reset (step) -37.989807 s
>
> > This behaviour cannot reproduced on other "identical", i.e. same
> > hardware, same jumpstart machine.
>
> Note the large drift correction.  The machine showing the problem
> has on it somewhere a "drift" file, in which xntpd stores a value to
> help it remember how fast or slow the hardware clock of that machine
> may be expected to run.  Apparently some wild tick perturbation put
> a large-magnitude negative number in that file.  The path to the
> driftfile should appear in the "/etc/inet/ntp.conf" configuration,
> but a typical path might be "/var/ntp/drift" or "/etc/ntp.drift".
>
> So, delete the drift file and see if things work better.
>
> BTW, Sun's xntpd often logs more than one "notice" message about a
> drift correction because the ordering of configuration commands in
> the "/etc/inet/ntp.conf" file is freeform.
>
> In other news...
>
> Although not giving explicit advice on the above problem, a lot of
> explanation of how to use NTP in a Unix environment was published
> by Sun Microsystems in a three-part Blueprint:
>
>     "Using NTP to Control and Synchronize System Clocks"
>
>     Part I: Introduction to NTP
>    http://www.sun.com/blueprints/0701/NTP.pdf
>
>     Part II: Basic NTP Administration and Architecture
>    http://www.sun.com/blueprints/0801/NTPpt2.pdf
>
>     Part III: NTP Monitoring and Troubleshooting
>    http://www.sun.com/blueprints/0901/NTPpt3.pdf
>
> Other sources of information on the Network Time Protocol:
>
>    http://www.ntp.org/
>    http://www.isc.org/sw/ntp
>    http://dan.drydog.com/ntp.html
>
> Hope this helps.
>
> --
> Richard S. Shuford


thanks for all replies; I tried again after having deleted the
driftfile but the
result is the same. the node reboots for no obvious reason.

could dtrace be of any help?




More information about the questions mailing list