Audisp is flooding /var/log/messages and trying to fix it
I'm upgrading from syslog to rsyslog in order to clean up logging. I've noticed that Audispd was flooding /var/log/messages with the following:
2015-12-23T08:33:46.370297-06:00 ameda4aisrx0238 audisp-remote: queue is full - dropping event
Under /etc/audisp/audispd.conf, I've changed the overflow_action from SYSLOG to SUSPEND, since I don't see a STIG pertaining to it:
q_depth = 2048
overflow_action = SUSPEND
priority_boost = 8
max_restarts = 10
name_format = HOSTNAME
#name = mydomain
That seemed to fix it for about 1 minute and then it was back to what it was.
I've read that q_depth could be increased to handle this since the logging can't keep up. The man page doesn't have a recommendation for a size or a best practice, so I'm wondering what would be a good number to set it to or see what others have done to fix this.
thanks
I'm wondering what
Responses
We have faced the same issue. I have increased q_depth to 32768 and it still cannot cope.
Since you have switched to rsyslog, why not do your remote logging via rsyslog? It is far more robust than audisp. There is a quick HOWTO on the syslog wiki: http://wiki.rsyslog.com/index.php/Centralizing_the_audit_log
Note: If you use SELinux, you will need to allow syslog to access /var/log/audit.log
See this Red Hat solution https://access.redhat.com/solutions/499323
Also, see this RH discussion ID https://access.redhat.com/discussions/650853 (particularly Jason Greene's response, and those that follow)
And... also see this RH discussion ID https://access.redhat.com/discussions/1311544
Perhaps I should not have commented on this thread as my main concern was not audit messages in /var/log/messages (which could be easily ignored or directed to a separate log file using other directives in rsyslog.conf) but the apparent lack of robustness when using audisp to send audit records to a remote logging server. I never found a q_depth that stopped audisp from dropping audit records and am not convinced that the queue file is ever properly drained. (Once full, audisp never seemed to be able catch up.) In other words my main concern was dropped audit records which the rsyslog solution addressed.
We too are subject to meeting STIG requirements. In most cases rsyslog handled the volume of generated audit records just fine. There have been a few instances where we have had to back off slightly from the strict STIG requirements due to excessive system overhead but this is probably off topic for this thread ...