Description of problem: Shortly after booting a Sun w2100z dual processor opteron workstation with Fedora Core 5 test 3, the system became unusable due to system load. Looking with top this was attributable to auditd having reached 18.9G of virtual address space, 1.8G resident set size and a shared of 438M. There were a large number of yp_docall: clnt_call: RPC timed out errors being reported on the system despite all usual YP tools working normally: ypwhich, ypcat, etc. I'm still investigating that. Even so, auditd shouldn't have exhausted all system resources. Version-Release number of selected component (if applicable): audit-1.1.4-5.1 How reproducible: Unknown. Steps to Reproduce: 1. Boot system, log in, start working 2. System load becomes high, auditd seems to be culprit 3. Actual results: System becomes very slow (load average > 20) until auditd process is killed. Expected results: System running normally. Additional info: Killing auditd seemed to resolve the problem and the machine returned to normal operation.
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.