ntp issue on Linux

[AVV]

Hello All,

I have a linux server RHEL 5.3 64 bit running on BL 460c blade and which is in sysnc with the time server. Few other servers are also synchronised with the time server and those works well. I am facing an issue in this blade that the time is changing 2-3 min ahead and when I am restarting the ntpd service it come back to normal and our application is affected with this now. I get only the below error at log file. Can you please guide me here.

=========
ntpd exiting on signal 15
=========
Synchronize system clock before starting the service is checked and unchecked the Use local time source in the system.

[Matti_Kurkela]

> ntpd exiting on signal 15

Signal 15 is SIGTERM = the signal sent by the regular "kill" command.
This would be a normal message when stopping the ntpd service.

> unchecked the Use local time source in the system.

Good. If you have only one external time source, the local timesource can confuse ntpd. Only if you have 2 or more external time sources _that agree with each other_, they can out-vote the local timesource.

When ntpd has been running for a while, what does your "ntpq -p" output look like? Is there a "*" symbol in the first column (indicating that ntpd has successfully synchronized with a time source)? Are the "delay" and "jitter" values fairly small?

You might also install the "adjtimex" RPM (an optional package in RHEL 5.x). After ntpd has been running for at least a day or two, run "adjtimex -p". It will print out the calibration values for the system clock.
The ntpd daemon adjusts the "frequency" value: ideally it would be close to 0.

If the "frequency" number is almost as big as the "tolerance" number (either negative or positive) it may be that the range of the "frequency" value is not enough to fully correct the system clock: in that case, you must manually adjust the "tick" value using the adjtimex command. The default value for "tick" is 10000; one step in the "tick" value is equal to 6553600 steps in the "frequency" value.

For example, if your current "tick" is 10000 and you see the "frequency" value is -32768000, it means ntpd was trying to slow down the system clock, but could not slow it down enough. To fix that, calculate how much you should adjust the "tick" value:

-32768000 / 6553600 = -5

So, you should change the "tick" by -5, i.e. the new value will be 9995.

adjtimex --tick 9995

Then restart ntpd and again wait and see for a couple of days. If ntpd now stays in sync and the "frequency" value is relatively small, you've found the correct value for "tick" in your system (and your system has an exceptionally fast/slow system clock).

The "tick" value is not persistent: after a reboot, the default value will again be used. You may have to write a small start-up script that runs the "adjtimex --tick " command at boot before ntpd is started.
(Debian's start-up scripts will read the correct "tick" value from /etc/default/adjtimex file if it exists and the adjtimex command is installed; I'm not sure if RedHat has something similar. I'll check at work on Monday.)

MK

[Modris Bremze]

This is not a virtual machine (VMware, Xen etc.) you are having problems with, right?

Have you "Synchronized system clock before starting the service [ntpdate ] [..] and unchecked the Use local time source in the system"? Where's the NTP server - LAN or internet? If you set the time with ntpdate, don't start the NTP service and leave the system running for a while - does the time still run faster?

[AVV]

Thanks