We are facing the following issue... Server XYZ(HPUX) time was modified manually, to be more than 1000s away from NTP server time.In this situation, when XYZ contacts NTP again, and detects such a high deviation, NTP daemon is aborted.
/var/adm/syslog/syslog.log shows Jan 17 15:04:47 XYZ xntpd[24974]: time error -6405.921590 is way too large (set clock manually)
On according to SUN documentation: "A sometimes confusing feature of NTP is that the NTP daemon on a client will abort itself if the offset between its clock and the server’s clock is too great. This behavior is triggered by an offset of greater than about 17 minutes. The rationale behind aborting the daemon over an excessive time error is that such a difference likely means that either the client is drifting at a very high rate, or the server has suddenly had its time changed using some method other than NTP."
-g Normally, ntpd exits with a message to the system log if the offset exceeds the panic threshold, which is 1000 s by default. This option allows the time to be set to any value without restriction; however, this can happen only once. If the threshold is exceeded after that, ntpd will exit with a message to the system log. This option can be used with the -q and -x options. See the tinker command for other options.
Re: ntpd abort when time deviation goes over 1000s
n order to keep ntpd running you have to tell it not to panic when it gets a very large time offset. The ntp daemon will accept an offset of up to 1000 seconds by default, but if you suspend your machine for more than that length of time the daemon will exit. In your /etc/ntp.conf file add the following lines:
tinker panic 0
The 0 says â accept any offsetâ which means that if your machine is suspended for a long time, as mine often are, when it unsuspends and gets a very large offset from the server everything will be OK.
Re: ntpd abort when time deviation goes over 1000s
Hi,
Yes what you are facing is typical NTP behaviour. If a drift of 1000 seconds is there between the server and client then, xntpd gives up and "kills" itself. That's how the protocol works. Janikks comments will be useful as well. Welcome to ITRC! Don't forget to assign appropriate points.
Regards Ismail Azad
Read, read and read... Then read again until you read "between the lines".....
