Re: AUDITD issues

[Steve Grubb <sgrubb@redhat.com>]

On Friday, March 17, 2017 1:59:46 PM EDT warron.french wrote:
> Hi everyone, I work in an environment with Internet-isolated networks.
> 
> I am having a problem that presents the following in /var/log/messages:
> *auditd[787]: *dispatch err (pipe full) event lost
> *auditd[787]: *dispatch err (pipe full) event lost
> *auditd[787]: *dispatch err (pipe full) event lost
> *auditd[787]: *dispatch err (pipe full) event lost
> *auditd[787]: *dispatch err (pipe full) event lost
> *auditd[787]: *dispatch err (pipe full) event lost
> *auditd[787]: *dispatch err (pipe full) event lost
> *auditd[787]: *dispatch err (pipe full) event lost
> *auditd[787]: *dispatch err (pipe full) event lost
> *auditd[787]: *dispatch err (pipe full) event lost
> *auditd[787]: *dispatch error reporting limit reached - ending report
> notification
> 
> While tailing the /var/log/audit/audit.log I notice a high volume of data
> pouring into the file; looked like it was tied to the same "keyed" audit
> rule, so I commented out all of the rules associated with that -k "key."
> 
> I restarted the audit daemon, and continued to monitor the
> /var/log/audit/audit.log; and the speed at which records were pouring in
> was drastically reduced; however, /var/log/messages is still reporting the
> same dispatch errors.
> 
> The rules that are pegging audit.log (and forcing it to roll over every 2
> minutes at a size of 36MB) were commented out, and /usr/sbin/ntpd (I think
> through the adjtimex syscall) is what is now the more recent culprit.
> 
> Any suggestions on how to resolve this problem?

In /etc/audisp/audispd.conf, raise the setting for q_depth. Out of the box, 
the audit system is configured for casual use and collecting selinux avcs. If 
you really are using the audit system and generating lots of events, then you 
need to tune it to survive bursts of events. I run with a value of 512 and do 
not get any overflows. YMMV.

-Steve