From: Steve Grubb <sgrubb@redhat.com>
To: Linux Audit <linux-audit@redhat.com>
Subject: Re: Occasional delayed output of events
Date: Sun, 03 Jan 2021 10:41:02 -0500 [thread overview]
Message-ID: <5426593.DvuYhMxLoT@x2> (raw)
In-Reply-To: <30c5dbc14368a1919717e2f39d2d4c29463c3108.camel@iinet.net.au>
On Friday, January 1, 2021 4:22:33 PM EST Burn Alting wrote:
> Sometimes, events recorded in /var/log/audit/audit.log appear some seconds
> past co- located events which results in auparse:au_check_events() marking
> these events complete before they are. An example of this can be seen
> below with the offending event id 44609.
>
> This has been plaguing me for a year or two and this morning was the first
> time I still had access to the raw audit.log files (I monitor a lot of
> event types and the log files roll over fairly quickly).
> The example below is from a fully patched Centos 7 but I have also seen
> this on a patched Fedora 32.
>
> Has this been seen before? Do we need to re-evaluate how auparse
> 'completes' an event (ie 2 seconds is too quick).
I have never seen this. But on the way to disk, auditd only does light
processing of the event. If the format is enriched, it looks things up on a
record by record basis. It does not collect events until they are complete -
it dumps it to disk as soon as it can tack on the extra information.
So, the question would be, does this delay happen on the way to disk? Or is
this an artifact of post processing the logs with an auparse based utility?
Can this be observed repeatedly on the same raw logs? If so, then maybe
auparse does have some issue. But if this is a post processing issue, then
the wall clock doesn't matter because this event should have collected up
together.
I'd say this merits some investigation.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
next prev parent reply other threads:[~2021-01-03 15:41 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-01 21:22 Occasional delayed output of events Burn Alting
2021-01-03 15:41 ` Steve Grubb [this message]
2021-01-04 7:55 ` Burn Alting
2021-01-04 14:46 ` Steve Grubb
2021-01-04 20:12 ` Burn Alting
2021-01-10 4:39 ` Burn Alting
2021-01-15 22:18 ` Burn Alting
2021-01-16 0:35 ` Richard Guy Briggs
2021-01-16 2:42 ` Burn Alting
2021-01-17 14:07 ` Paul Moore
2021-01-17 21:12 ` Steve Grubb
2021-01-18 13:54 ` Paul Moore
2021-01-18 14:31 ` Steve Grubb
2021-01-18 20:34 ` Burn Alting
2021-01-18 20:36 ` Paul Moore
2021-01-19 8:18 ` Burn Alting
2021-01-19 15:31 ` Lenny Bruzenak
2021-01-19 19:11 ` Paul Moore
2021-01-19 19:38 ` Burn Alting
2021-01-19 20:26 ` Paul Moore
2021-01-19 21:51 ` Steve Grubb
2021-01-20 6:38 ` Burn Alting
2021-01-20 22:50 ` Paul Moore
2021-01-23 22:55 ` Burn Alting
2021-01-25 23:53 ` Steve Grubb
2021-01-26 0:11 ` Burn Alting
2021-01-26 0:20 ` Steve Grubb
2021-01-26 0:29 ` Burn Alting
2021-01-26 11:53 ` Burn Alting
2021-01-26 20:42 ` Steve Grubb
2021-01-27 12:12 ` Burn Alting
2021-01-19 20:42 ` Richard Guy Briggs
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=5426593.DvuYhMxLoT@x2 \
--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