This alarm indicates the NTP offset of the server
currently being synced to is greater than the critical threshold.
Severity:
Critical
Instance:
May include AlarmLocation, AlarmId, AlarmState,
AlarmSeverity, and bindVarNamesValueStr
HA Score:
Normal
Auto Clear Seconds:
0 (zero)
OID:
eagleXgDsrNtpOffsetCheckFailureNotify
Alarm ID:
TKSPLATCR18
Cause:
The NTP offset of the server currently being synced to is
greater than the critical threshold.
Diagnostic Information:
Run
ntpstat command to diagnose the alarm.
Recovery:
Verify NTP settings and NTP sources can be reached.
Ensure ntpd service is running using
ps -ef | grep or
service ntpd status.
Verify the content of the /etc/ntp.conf file is
correct for the server.
Type
/usr/sbin/ntpdc -c sysinfo to check the
current state of the ntpd daemon.
Verify the ntp peer configuration; execute
ntpq -p; and analyze the output. Verify peer
data, such as tally code (first column before remote), remote, refid, stratum
(st), and jitter, are valid for server.
Execute ntpstat to determine the ntp time
synchronization status. If not synchronized or the stratum is not correct for
server, then ping the ntp peer to determine if the peer can be reached.
If ntp peer is reachable, then restart the ntpd
service.
If problem persists, then a reset of the NTP date
may resolve the issue.
Note:
Before resetting the ntp date, the applications
may need to be stopped; and subsequent to the ntp reset, the application
restarted.
To reset date:
sudo service ntpd stop
sudo ntpdate <ntp server
IP>
sudo service ntpd start
Confirm to recommended NTP topology and strategy.
No fewer than tree references are recommended.
If selecting a different number, the number
should be odd.
No intermediate reference should be a
virtualized server.
Additional recommendations and topology are
available in the NTP strategy section in the
DSR Hardware and Software Installation 1/2 customer
document.
If the problem persists, it is recommended to
contact
My Oracle Support.
