On 1 jun, 00:35, "Richard S. Shuford" <[EMAIL PROTECTED]
THlS-PART.com> wrote:
> In message <[EMAIL PROTECTED]>, 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
> <[EMAIL PROTECTED]>:
>
>
>
>
>
> > 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?

_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions

Reply via email to