NTP time synchronization failure
Product: Agilent Connected Instrument Device (CID) for OpenLab CDS Audience: Agilent Support, IT/network administrators Support reference: Network / firewall configuration
The diagnostic procedures on this page are intended for IT administrators familiar with Linux commands. Incorrect use of the underlying tools can misconfigure the CID and render it inoperable. Proceed only if you are comfortable working in a Linux environment.
Symptom
The CID system clock has drifted from real time, breaking time-sensitive operations. This may manifest as:
- TLS certificate validation failures on HTTPS connections, even when the network path appears healthy.
- AWS API or AWS IoT requests rejected due to request-timestamp mismatch.
- CID Hub communication errors that correlate with clock drift.
- File and log timestamps on the CID drift from real time in a sustained way (not a brief skew at boot).
Root cause
The CID uses pool.ntp.org as its NTP time source and synchronizes via the chrony service. Time synchronization requires outbound UDP traffic on port 123 to be permitted by the network. Because UDP/123 is separate from TCP/443, it is frequently omitted from firewall rules that otherwise permit HTTPS.
Accurate system time is a hard dependency for several CID functions:
- TLS certificate validation. Certificates carry validity periods. A clock skewed by more than a few minutes can cause valid certificates to be rejected as expired or not-yet-valid.
- AWS request signing. AWS API and AWS IoT requests include a timestamp that must fall within a defined tolerance of actual time. Requests outside this window are rejected by AWS.
- Log correlation. Inaccurate timestamps complicate troubleshooting, event reconstruction, and incident review.
Confirm this is the right document
Run the following on the CID:
chronyc sources
| Result | Next step |
|---|---|
No source has a REACH value of 377 | This is the correct document. Continue below. |
At least one source has a REACH value of 377 | The CID Connectivity Tester considers NTP reachable. If HTTPS failures persist, see TCP port 443 blocked, TLS handshake failure, or Certificate validation errors. |
You can also arrive here from Verify CID internet connectivity if the NTP test there reported a chronyc sources REACH value below 377 for pool.ntp.org.
Affected services
If time drift accumulates, TLS handshakes, AWS IoT Core authentication, and CDS client/server communication can fail. For the complete list of internet endpoints the CID requires, see the Internet requirements section of System requirements.
Prerequisites
- Command-line access to the CID via SSH or direct console connection.
- Authorization from your IT or network security team to execute network diagnostic commands, if applicable.
Diagnostic steps
Step 1. Check NTP reachability
Run the same command used by the CID Connectivity Tester:
chronyc sources
| Result | Next step |
|---|---|
At least one source has a REACH value of 377 | The CID Connectivity Tester considers NTP reachable. No further action is required on this page. |
No source has a REACH value of 377, or the command returns an error or no usable output | Continue to Step 2. |
Step 2. Apply a pending clock correction
Check whether chronyd has a correction waiting to be applied:
chronyc tracking
If System time shows a remaining correction, wait for any active acquisition or other time-sensitive work to complete. Then apply the correction immediately:
sudo chronyc makestep
Run chronyc tracking again and record the before-and-after output for Agilent Support.
| Result | Next step |
|---|---|
| The pending correction is applied and the CID clock is correct | Run chronyc sources again. If at least one source has a REACH value of 377, no further action is required on this page. |
The CID clock remains incorrect, or no source reaches 377 | Continue to Step 3. This result alone does not identify whether the cause is DNS, UDP/123 access, or the local chrony service. |
Step 3. Verify NTP hostname resolution
Confirm the CID can resolve NTP pool hostnames. DNS failure can prevent NTP from functioning even when UDP/123 is permitted.
nslookup pool.ntp.org
If this fails, see DNS resolution failure before working further on NTP.
| Result | Next step |
|---|---|
nslookup returns an Address for pool.ntp.org | DNS is resolving. See Resolution to check UDP/123 access. |
nslookup reports server can't find or times out | DNS resolution is failing. See DNS resolution failure before working further on NTP. |
Resolution
Provide the diagnostic output from the diagnostic steps to your network security team and request the appropriate action.
| Recommended action | Applicable when |
|---|---|
Verify DNS resolution for pool.ntp.org | Step 3 showed DNS resolution failure |
Permit outbound UDP/123 to *.pool.ntp.org | DNS resolves, but no NTP source reaches 377 |
Contact Agilent Support and provide the chronyc output | DNS resolves and UDP/123 is permitted, but the NTP test still fails |
For the NTP network requirement, see the Time synchronization section of System requirements.
Related documents
Last updated: