Bug 146490 (IT#60030)
| Summary: | ntp sometimes changes the time in violation of the sanity limit | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 2.1 | Reporter: | Steve Conklin <sconklin> |
| Component: | ntp | Assignee: | Jiri Ryska <jryska> |
| Status: | CLOSED NOTABUG | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 2.1 | CC: | shillman, tao |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-03-11 17:10:28 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Given that the RHEL2.1 and RHEL3 ntp code is virtually identical, I tried to also reproduce this under RHEL 3. I did see the problem twice out of around 15 clock changes. An identical RHEL 2.1 box (both Dell rpecision 420s) with the same network path to the server (same hub) repeatably showed the problem. OK, some comments: 1. If no steptickers are found and "-x" is not in defined in /etc/sysconfig/ntpd the server is started with "-g", which allows the server to break the sanity limit once at the beginning. 2. After starting the server, it has to synchronize with the other server, so it first obeys the local clock for about 5 minutes. Without "-x" ntpd is allow to "step", which means it can make a time jump. And if the "-g" option is added (no step-tickers, no -g) by the initscript, it can once break the sanity limit! The above analysis reflects the behavior and resolves the issue. The ntpd daemon never stepped more than once without the steptickers file as expected. J |
Description of problem: When the time is changed by a large amount on the ntp server, the client sometimes changes time in violation of the sanity limit. This has been replicated on a RHEL2.1 machine in-house, but it doesn't seem to happen on all machines. I will attach ntpd debug logs that demonstrate the problem. Version-Release number of selected component (if applicable): ntp-4.1.2-1.AS21.2 How reproducible: Sometimes Steps to Reproduce: 1. Step the time on the ntp server by more than 1000 seconds 2. Observe the client 3. Actual Results: Client changes time to match server Expected Results: Client should exit with error message Jan 28 08:45:23 hostnamehere ntpd[2972]: time correction of 3595 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. Additional info: This doesn't happen on every client machine, but if it does happen, it happens consistently. The customer has deleted the step-tickers config file to prevent ntpdate from running at daemon startup, but that shouldn't affect this.