Troubleshooting Time Synchronization Issues Notes
NTP on Linux
Linux and Unix platforms have native NTP clients and daemons specific to each platform. Typically, this is ntpd (NTP version 4) or xntpd (NTP version 3).
To check if the package is already installed, you can use the RedHat RPM utility. At the console prompt, enter the following:
rpm –q xntp
To check if the xntp daemon is running, enter the following at a console prompt (ps=report process status; -e=select all processes; f=full listing):
ps –ef|grep xntp
NTP on Netware
TIMESYNC 5.24 or later can communicate with NTP time servers (including public NTP sources on the Internet) as well as function as an NTP time server.
NTP has a feature to prevent time adjustments from time sources that begin sending the incorrect time. If an NTP client determines that an NTP time server it is configured to get time from is more than 1000 seconds (or about 17 minutes) off from the local machine’s time, then it labels the time source as insane and ignores the NTP time adjustment.
How Time Stamps Are Created
There are 3 parts to an eDirectory time stamp; the UTC, the replica number and the event ID.
- Universal Time Coordinated (UTC) is a time system that calculates Greenwich Mean Time (GMT) for the local time zone of the server. When time is synchronized, UTC guarantees that all servers are at the same time no matter what time zone they physically reside in.eDirectory stores UTC in 4 bytes using the following format: yyy/mmm/dd hh:mm:ss
- The formula for calculating UTC is as follows:Local time + or – time zone offset (+ daylight saving time offset) = UTC
- The Replica number is a 2-byte field that records the replica where the eDirectory event took place.
- The Event ID is a 2-byte field that holds the order in which eDirectory time stamps occurring in the same second were issued. Because the smallest unit of measurement for UTC is a second, eDirectory must be able to accurately record the order of multiple events within the same second. The event ID field increments each time a new eDirectory even occurs with the same second. It increments until a new second has advanced or 65,535 events have been issued for the same second. After the maximum number of events has occurred, the system advances to the next second. After the second has advanced, the event counter returns to the value of 1.
How Synthetic Time Issues Occur
Synthetic time is a condition where the time provided by the local operating system is older than the time stamps already recorded in eDirectory. If the local server time is older than the minimum possible time stamp value held by the Next Time Stamp field of the partition record on that server, eDirectory will show that the server is issuing synthetic time. Synthetic time is issued until the local server time catches up with the synthetic time.
How to Resolve Synthetic Time Issues
You can use the following methods to resolve synthetic time:
- Wait for eDirectory to Repair itself
- Manually Re-create Offending Objects
- Declare a New Epoch
Declaring a New Epoch
The following describes what happens when you declare a new epoch:
- A new epoch is declared on the master replica, possibly affecting all objects in all replicas of the partition.
- All time stamps are examined and repaired as required.
- Updates are not accepted from replicas with post-dated time stamps (epochs) until the replicas are synchronized.
- A replica receives a copy of all objects in a master replica or any other replica that has received a new epoch.
- The replica becomes the same epoch as the master replica.
- Any modifications from a previous epoch are lost.
- The master replica does not need to reside on the current server, but you must have the Supervisor right to the server holding the master replica to perform the repair operation.
- The other replicas are put in a new state.
Declaring a new epoch can be a potentially destructive operation. Existing replicas are deleted and replaced with a copy of the master replica. If the master replica is in good shape, this doesn’t present a problem. However if the master replica is corrupt, declaring a new epoch will replace potentially good replicas with a copy of the corrupt master replica. Consider all other options before resorting to declaring a new epoch.
To declare a new epoch run DSREPAIR –A and select Advanced Options Menu/Replica and Partition Operations, select the replica where the offending object reside, select Repair Time Stamps and Declare a New Epoch.