From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Subject: Re: buffer space
Date: Thu, 13 Aug 2009 14:28:43 -0400 [thread overview]
Message-ID: <200908131428.52924.sgrubb@redhat.com> (raw)
In-Reply-To: <OF353CD1BD.0E9A8BA7-ON85257611.004F634D-85257611.00521D7B@us.ibm.com>
On Thursday 13 August 2009 10:56:50 am David Flatley wrote:
> Red Hat 5.3 running audit 1.7.7-6
> Rotating logs at 20 megs and allowing 8 logs
> Rules have watches and syscalls from the SECSCAN recommendations, and have
> added some of Steve Grubb's recommendations.
I would be curious what the SECSCAN recommendations are. Never heard of it...
> When we extract and archive the audit logs we get "Error receiving audit
> netlink packet (No buffer space available) an "error sending signal info
> request"
> Our extract is: stop auditd then create a file and run ausearch -i > file
> then run an aureport -i > file then once that is done we delete all the
> logs and restart auditd.
I think this is your problem. If you have audit rules loaded and stop auditd,
then audit events are going to pile up in the queue waiting for auditd to
download them. At some point the kernel will decide auditd doesn't exist and
will dump all events to syslog. This probably is not what you want either.
I would recommend calling "service auditd rotate" and then grab logs
audit.log.1 -> audit.logs.7 and move them away to another directory for post
processing the contents.
You may also want to check you backlog size settings too.
> If I run this manually it works fine but if I have it running it in a cron
> we get Kernel panics, lockups and log data loss plus the buffer messages.
Shouldn't really make a difference.
-Steve
next prev parent reply other threads:[~2009-08-13 18:28 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 [this message]
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
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=200908131428.52924.sgrubb@redhat.com \
--to=sgrubb@redhat.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