It ran faster and caused application servers not to synchronize with the DB server.
Duane Fletcher helped kill the process (/usr/sbin/xntpd) and ran it again to sync the clock.
After 2 hours, the clock was again 5 minutes ahead.
In syslog, it showed the following line numerous times:
Code: Select all
Nov 12 19:57:10 laxm1311 xntpd[1835]: Unsynchronized, possible remote server failure or defective hardware clock
Eventually, HP replaced the hardware component and it was back to normal but I was checking how ntp was set up and whether it is configured as a time server because it didn't look like a time server. All application servers were syncing from laxm1311 but they didn't sync with laxm1311 and that's why the application was not in sync with database server.
From /etc/rc.log:
Code: Select all
Start time synchronization
Output from "/sbin/rc2.d/S660xntpd start":
----------------------------
12 Nov 01:01:52 ntpdate[4167]: step time server 144.15.255.25 offset -11.15630
1 sec
xntpd
Code: Select all
/sbin/rc2.d/S660xntpd stop
/sbin/rc2.d/S660xntpd start
In /sbin/rc2.d/S660xntpd, it reads /etc/rc.config.
/etc/rc.config reads config from /etc/rc.config.d/* and the key file is /etc/rc.config.d/netdaemons.
In it, there is the following section that specifies NTPD config:
Code: Select all
######################################
# xntp configuration. See xntpd(1m) #
######################################
#
# Time synchronization daemon
#
# NTPDATE_SERVER: name of trusted timeserver to synchronize with at boot
# (default is rootserver for diskess clients)
# XNTPD: Set to 1 to start xntpd (0 to not run xntpd)
# XNTPD_ARGS: command line arguments for xntpd
#
# Also, see the /etc/ntp.conf and /etc/ntp.keys file for additional
# configuration.
#
export NTPDATE_SERVER="144.15.255.25"
export XNTPD=1
export XNTPD_ARGS=