From: Steve Grubb <sgrubb@redhat.com>
To: LC Bruzenak <lenny@magitekltd.com>
Cc: linux-audit@redhat.com
Subject: Re: buffer space
Date: Tue, 18 Aug 2009 11:53:43 -0400 [thread overview]
Message-ID: <200908181153.51387.sgrubb@redhat.com> (raw)
In-Reply-To: <1250608198.3048.787.camel@homeserver>
On Tuesday 18 August 2009 11:09:58 am LC Bruzenak wrote:
> On Tue, 2009-08-18 at 09:02 -0400, David Flatley wrote:
> > When I do "service auditd rotate" I am getting in
> > the /var/log/messages the following:
> >
> > Error receiving audit netlink packet (No buffer space available)
> > Error sending signal_info request (No buffer space available)
> >
> > At the same time I am running a regression test that is generating 20
> > meg audit logs every six to eight minutes.
> >
> > Is this a concern?
It sounds like you have a system that is auditing a lot of data. Since you are
doing regression testing, I would not be too concerned. But in general, you
can increase the priority boost for auditd and see if it gets more time slots
to drain the queue, make the log files larger, but fewer of them so rotate is
faster, increase the backlog buffer some more, or adjust what you are auditing.
> What I believe is happening is that you are generating an abnormal
> amount of audit data in your regression test. That's OK, but I think
> when you do the rotate the auditd suspends disk writes while it waits
> for the rotate to complete.
>
> IIRC, the rotate starts with the highest number log, rolls it to the
> next higher number. Then it decrements the counter and repeats. So
> log.13->log.14, then log.12->log.13, etc., and eventually moves
> audit.log to audit.log.1. Then a new audit.log is created and the flow
> resumes.
>
> While this happens, you are stacking up events from the kernel and
> eventually run out of space. On some machines where the log files are in
> the hundreds (I had around 300) I have seen the rotate take an
> appreciable amount of time.
This is true.
But having looked at the audit requirements and the given/suggested rules,
they are badly in need of correction. I would say those audit rules is the
root cause of the problem.
-Steve
next prev parent reply other threads:[~2009-08-18 15:53 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-13 14:56 buffer space David Flatley
2009-08-13 15:29 ` Matthew Booth
2009-08-13 18:28 ` Steve Grubb
2009-08-17 14:49 ` David Flatley
2009-08-17 15:07 ` Steve Grubb
2009-08-17 15:36 ` Norman Mark St. Laurent
2009-08-17 16:38 ` David Flatley
2009-08-17 16:52 ` LC Bruzenak
2009-08-17 17:06 ` David Flatley
2009-08-17 17:15 ` LC Bruzenak
2009-08-17 17:24 ` LC Bruzenak
2009-08-17 21:18 ` David Flatley
2009-08-17 17:32 ` David Flatley
2009-08-17 17:46 ` LC Bruzenak
2009-08-17 18:01 ` Steve Grubb
2009-08-17 18:13 ` Norman Mark St. Laurent
2009-08-17 18:14 ` LC Bruzenak
2009-08-17 18:46 ` Norman Mark St. Laurent
2009-08-17 19:37 ` Steve Grubb
2009-08-17 19:46 ` Norman Mark St. Laurent
2009-08-18 13:02 ` David Flatley
2009-08-18 15:09 ` LC Bruzenak
2009-08-18 15:53 ` Steve Grubb [this message]
2009-08-27 17:21 ` David Flatley
2009-08-27 17:32 ` Steve Grubb
2009-08-27 17:45 ` David Flatley
2009-08-27 18:45 ` Steve Grubb
2009-08-27 17:33 ` LC Bruzenak
2009-08-23 4:12 ` D.A. Muran-de Assereto
2009-08-17 15:34 ` Norman Mark St. Laurent
2009-08-17 16:58 ` Mike Nixon
2009-08-23 4:32 ` David Muran-de Assereto
2009-08-23 16:12 ` Mike Nixon
2009-08-23 20:24 ` David Muran-de Assereto
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=200908181153.51387.sgrubb@redhat.com \
--to=sgrubb@redhat.com \
--cc=lenny@magitekltd.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