public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com, Amjad Gabbar <amjadgabbar11@gmail.com>
Subject: Re: Maximum Value for q_depth
Date: Wed, 08 Dec 2021 17:44:16 -0500	[thread overview]
Message-ID: <21289484.EfDdHjke4D@x2> (raw)
In-Reply-To: <CAJcJf=R=AYf-9_ipM0qUVD65DnkD-ifVmm4JgmjVXZbASTqt7w@mail.gmail.com>

Hello,

On Wednesday, December 8, 2021 4:54:52 PM EST Amjad Gabbar wrote:
> 1. The version of auditd is 1:2.8.4-3 and the plugins are af_unix.conf and
> syslog.conf for audisp. The q_depth is currently set to 80 and I think it
> calls for an increase but not sure if there is a way to figure out what the
> proper number would be?

There is no good calculation that I can give you. It depends on the average 
rate of incoming events and the rate that they can be offloaded to the plugins 
+ some margin in case there is a burst. Looking at the 2.8.5 code, the 
default is 250.

https://github.com/linux-audit/audit-userspace/blob/2.8_maintenance/init.d/
audispd.conf

So, you should at least set it that high. Maybe a bit higher.


> 2. Another thing I would like to follow up on is the difference between
> q_depth and backlog_limit. My assumption was if there is any drop due to a
> burst of events it would be addressed by the backlog limit. Just would like
> some clarification on this and how this is an event dispatcher issue?

The backlog limit is inside the kernel. This is the buffer that holds events 
that are waiting for the audit daemon to offload them. Once the audit daemon 
has them, it sends it to the dispatcher which also buffers events because not 
all plugins are able to receive the events as soon as they arrive at the 
dispatcher.

So, for brief bursts, the kernel backlog will handle the load. But once they 
are pulled out of the kernel, the q_depth controls how much to hold waiting 
for plugins. If this number needs to increase much, then the plugins are 
having problems. The syslog plugin should be fine. I'd look more at the 
af_unix plugin. The client that attaches to it needs to unload events 
quickly. I'd investigate the af_unix client to see if it's the problem.

Cheers,
-Steve
 

> On Wed, Dec 1, 2021 at 10:00 AM Steve Grubb <sgrubb@redhat.com> wrote:
> > Hello,
> > 
> > On Tuesday, November 30, 2021 6:04:28 PM EST Amjad Gabbar wrote:
> > > I am currently seeing a lot of auditd dispatch error issues.
> > 
> > What version of auditd and what plugins do you have?
> > 
> > > It is related to a particular keyed rule that from the looks of it is
> > > generating close to a million events /day. I have seen previous answers
> > > where it was advised to increase the q_depth value to a suitable
> > > number.
> > > 
> > > Based on this, I would like to confirm what is the maximum advisable
> > 
> > value
> > 
> > > q_depth can have/take?
> > 
> > Depends on what you are willing to set it to. You can easily go to 64k,
> > but
> > you really ought to look at the plugins to see why they can't keep up.
> > And
> > of
> > course, are the rules really designed right and you need the million
> > events/
> > day?
> > 
> > -Steve




--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit


  reply	other threads:[~2021-12-08 22:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-30 23:04 Maximum Value for q_depth Amjad Gabbar
2021-12-01 16:00 ` Steve Grubb
     [not found]   ` <CAJcJf=RM3r1GcgeCof3Xna7Hz94C1Wg9_9YLQTfXd3ozun8CmA@mail.gmail.com>
2021-12-08 21:54     ` Fwd: " Amjad Gabbar
2021-12-08 22:44       ` Steve Grubb [this message]
     [not found]     ` <2165998.iZASKD2KPV@x2>
2021-12-09  4:00       ` Amjad Gabbar
2021-12-09 14:18         ` Steve Grubb
2021-12-21  5:55           ` Amjad Gabbar
2021-12-21 20:39             ` Steve Grubb
2022-01-18  6:36               ` Amjad Gabbar
2022-01-25 20:30                 ` Steve Grubb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=21289484.EfDdHjke4D@x2 \
    --to=sgrubb@redhat.com \
    --cc=amjadgabbar11@gmail.com \
    --cc=linux-audit@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox