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

Richard S. Shuford shuford at list.stratagy.IGN0RE-THlS-PART.com
Thu May 31 22:35:35 UTC 2007


In message <465EB2CF.2050700 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.231040 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




More information about the questions mailing list