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