<div dir="auto">Got it. Makes sense to me. Thanks for the explanation Steve.</div><div dir="auto"><br></div><div dir="auto">One last thing though based on the discussion we had, if the kernel is able to offload events even during bursts, wouldn’t setting q_depth =backlog_limit be enough?</div><div dir="auto"><br></div><div dir="auto">The reason being if there was an overflow on the kernel side, a different message would be printed in the logs but because it is all dispatch errors, I assume the kernel is able to handle the burst which is why the reasoning of increasing q_depth to backlog_limit.</div><div dir="auto"><br></div><div dir="auto">Thanks </div><div dir="auto">Amjad</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 8, 2021 at 4:38 PM Steve Grubb <<a href="mailto:sgrubb@redhat.com">sgrubb@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wednesday, December 8, 2021 4:54:18 PM EST Amjad Gabbar wrote:<br>
> 1. The version of auditd is 1:2.8.4-3 and the plugins are af_unix.conf and<br>
> syslog.conf for audisp. The q_depth is currently set to 80 and I think it<br>
> calls for an increase but not sure if there is a way to figure out what the<br>
> proper number would be?<br>
<br>
There is no good calculation that I can give you. It depends on the average <br>
rate of incoming events and the rate that they can be offloaded to the plugins <br>
+ some margin in case there is a burst. Looking at the 2.8.5 code, the <br>
default is 250.<br>
<br>
<a href="https://github.com/linux-audit/audit-userspace/blob/2.8_maintenance/init.d/" rel="noreferrer" target="_blank">https://github.com/linux-audit/audit-userspace/blob/2.8_maintenance/init.d/</a><br>
audispd.conf<br>
<br>
So, you should at least set it that high. Maybe a bit higher.<br>
<br>
<br>
> 2. Another thing I would like to follow up on is the difference between<br>
> q_depth and backlog_limit. My assumption was if there is any drop due to a<br>
> burst of events it would be addressed by the backlog limit. Just would like<br>
> some clarification on this and how this is an event dispatcher issue?<br>
<br>
The backlog limit is inside the kernel. This is the buffer that holds events <br>
that are waiting for the audit daemon to offload them. Once the audit daemon <br>
has them, it sends it to the dispatcher which also buffers events because not <br>
all plugins are able to receive the events as soon as they arrive at the <br>
dispatcher.<br>
<br>
So, for brief bursts, the kernel backlog will handle the load. But once they <br>
are pulled out of the kernel, the q_depth controls how much to hold waiting <br>
for plugins. If this number needs to increase much, then the plugins are <br>
having problems. The syslog plugin should be fine. I'd look more at the <br>
af_unix plugin. The client that attaches to it needs to unload events <br>
quickly. I'd investigate the af_unix client to see if it's the problem.<br>
<br>
Cheers,<br>
-Steve<br>
<br>
<br>
</blockquote></div></div>