Bug 182559
Summary: | auditd takes all available memory within 20 minutes of boot | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Bevis King <brwk> |
Component: | audit | Assignee: | Steve Grubb <sgrubb> |
Status: | CLOSED WORKSFORME | QA Contact: | Brian Brock <bbrock> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 5 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-05-02 12:46:55 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: |
Description
Bevis King
2006-02-23 10:53:10 UTC
Do you have any changes in /etc/auditd.conf from the default config? I just checked it with valgrind on an x86_64 machine and I don't see a memory leak. Nope, absolutely default config. Machine was installed yesterday evening from the standard CD-ROM distribution. There is definitely something amiss with YP on the box though - dbus-daemon is sitting permanently at >80% CPU usage now auditd is gone. Still investigating that.... The problem with YP appears to have been related to SELinux denying socket connects to it. Running with SELinux disabled seems much smoother. Does this bug still exist? I think it probably does - the do_ypcall issue turned out to be that NIS host lookups hang and if you have host resolution set in nsswitch.conf to "files nis dns", things go badly wrong. This has been reported seperately. The NIS bug is : 183188 So, if we exclude comments regarding yp system, does the audit daemon still consume all memory? Current release is 1.1.5. I've spent time with valgrind and cannot find any leaks. I do the audit daemon development work on an x86_64 machine and test it all the time and never see anything consuming all memory. I'm at a loss as to what it could be. OK, there are two scenarios I can think of - one is that selinux barring access to it's port was causing all requests to block and stay sitting on the queue, or it was forking over the name resolution issues and again the queue grows and thus exhausting memory. I'm not sure that there is a flaw per se except that it doesn't detect that an upstream blockage is causing it's queue to build continuously. I think I may have seen an SElinux update go through that fixed problems dbus was having with communication to auditd. Did that address this issue too? Regards, Bevis. I have used valgrind on auditd and have found no leaks. The standard SE Linux policy does not block access from the audit daemon to the kernel. The audit daemon uses select or poll to detect data being available. It re-uses the same buffer for each event to avoid memory allocation problems. If this problem exists, I need some data showing a memory leak. I'd like to fix it if its there. Otherwise, I would like to close this bug since all my testing shows no leak. Thanks... Closing this bug. If this bug recurs, please attach strace, mtrace, or valgrind data showing a leak. Thanks. |