Bug 918127
| Summary: | Chronyd is flooding the audit system with time adjustment events | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Steve Grubb <sgrubb> |
| Component: | chrony | Assignee: | Miroslav Lichvar <mlichvar> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 18 | CC: | mlichvar |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | chrony-1.28-1.fc18 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-07-02 00:33:41 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Steve Grubb
2013-03-05 14:42:44 UTC
I suspect most of these are read-only adjtimex calls (modes=0) to obtain the remaining offset correction when reading the clock. Normally, the clock should be modified only about once per 1024 seconds after the synchronization has stabilized. Is it possible to extend the rule to check the modes field in the timex structure passed to the syscall? You can use ntpd from the ntp package instead of chrony, it shouldn't call adjtimex as often as chronyd does. Its not possible to do anything with the adjtimex syscall because it has one argument and its a pointer to a user space timex struct. The audit system can only check arguments passed by value rather than dereference pointers to the value. The synchronization never seems to settle. My system has been on 2 hours and I have a little over 1900 events. By default, this is too aggressive. As for ntpd, well...this package is required by revisor and anaconda. So, its pulled in and the daemon is enabled by default. This leads to flooding the audit logs. If ntpd does it, I'll open a bz on that package as well. But out of the box, this daemon is too aggressive. For example, looking at how often it does something: 10:39:12.791:1303 10:39:12.791:1304 10:39:12.911:1305 10:39:12.911:1306 10:39:12.911:1307 10:39:12.791:1302 10:40:59.077:1309 10:40:59.077:1310 10:40:59.184:1311 10:40:59.184:1312 10:40:59.184:1313 10:40:59.077:1308 10:43:25.722:1315 10:43:25.722:1316 10:43:25.811:1317 10:43:25.811:1318 10:43:25.811:1319 10:43:25.722:1314 10:47:34.406:1321 10:47:34.406:1322 10:47:34.448:1323 10:47:34.448:1324 10:47:34.448:1325 10:47:34.448:1326 10:47:34.406:1320 10:47:34.448:1327 10:47:34.448:1328 10:47:34.448:1329 10:47:34.448:1330 10:47:34.448:1331 10:47:48.475:1333 10:47:48.475:1334 10:47:48.597:1335 10:47:48.597:1336 10:47:48.597:1337 10:47:48.475:1332 This is hour:minute:second.millisecond:serial number within the millisecond. Its seems to let the system go for a couple minutes or a couple seconds, but then starts all the syscalls again. Perhaps the audit daemon could be improved to merge identical successive messages? By default there are 4 servers in chrony.conf. The initial polling interval is 64 seconds, which is gradually increased to 1024 seconds. For each server query there are 6 time stamps made (adjtimex calls). One after select() timeouts, two before the packet is send, one for select() when the packet is received, one to correct SO_TIMESTAMP and another in source selection. I think it's working as expected. From that six calls two or three could probably be eliminated/cached, but I'm not sure if that would help you. There shouldn't be any hard dependencies on chronyd in default install as it is supposed to be replaceable with ntp, it might be worth to file some bugs. The upstream code has now reduced the number of adjtimex calls approximately by half. I think this is best what can we do now. http://git.tuxfamily.org/chrony/chrony.git/?p=chrony/chrony.git;a=commitdiff;h=8aa9eb19c826f3ea4a9c2ce5e3a71b74aeeb99d0;hp=62027f1b47ada22a910d02d7eb953d2e6a45bf84 Thanks. It is a mandatory requirement on government system to audit any change to the clock because that could mess up correlation of logs should an intruder try to make it look like something happened at a different time. chrony-1.28-0.1.pre1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/chrony-1.28-0.1.pre1.fc19 Package chrony-1.28-0.1.pre1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing chrony-1.28-0.1.pre1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-11434/chrony-1.28-0.1.pre1.fc19 then log in and leave karma (feedback). chrony-1.28-0.1.pre1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. chrony-1.28-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/chrony-1.28-1.fc18 chrony-1.28-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. |