From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,MIME_HTML_MOSTLY,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A99D9C433DB for ; Fri, 15 Jan 2021 22:19:07 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B28052251E for ; Fri, 15 Jan 2021 22:19:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B28052251E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=iinet.net.au Authentication-Results: mail.kernel.org; spf=tempfail smtp.mailfrom=linux-audit-bounces@redhat.com Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-498-6lba9xJxOxKJ_LRx2XjjjQ-1; Fri, 15 Jan 2021 17:19:02 -0500 X-MC-Unique: 6lba9xJxOxKJ_LRx2XjjjQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1874F802B45; Fri, 15 Jan 2021 22:18:58 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 64F005D756; Fri, 15 Jan 2021 22:18:57 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 961F04A7C6; Fri, 15 Jan 2021 22:18:55 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 10FMIqg5005334 for ; Fri, 15 Jan 2021 17:18:53 -0500 Received: by smtp.corp.redhat.com (Postfix) id CC4502026D25; Fri, 15 Jan 2021 22:18:52 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast06.extmail.prod.ext.rdu2.redhat.com [10.11.55.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C5E552026D47 for ; Fri, 15 Jan 2021 22:18:50 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id F34D6185A794 for ; Fri, 15 Jan 2021 22:18:49 +0000 (UTC) Received: from icp-osb-irony-out8.external.iinet.net.au (icp-osb-irony-out8.external.iinet.net.au [203.59.1.225]) by relay.mimecast.com with ESMTP id us-mta-257-fgOctGT1PZWVSEZurgDc6Q-1; Fri, 15 Jan 2021 17:18:46 -0500 X-MC-Unique: fgOctGT1PZWVSEZurgDc6Q-1 X-SMTP-MATCH: 1 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2CjCABjEwJg/1enWttiHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFHgUiBfIElV2KEP4kEhjIBghYDOE2DH4psi1GBTAMNCwEBAQE?= =?us-ascii?q?BAQEBASEBCgkBAgQBAYREBAICgW4mOBMCEAEBAQUBAQEBAQYDAYZSDIVzAQE?= =?us-ascii?q?BAQIBAQEhBC8YGwsIBgIIHA4CAicwBgESG4JASwGCVQEBDx8Qrm12fzOEQAG?= =?us-ascii?q?BBhOCEQaBDYE9BoE4hnUBgkyDcjWBTT+BETaCLjU+gl0BAQIXhF6CYASBVAZ?= =?us-ascii?q?kBgEUFwRcExgJEQYCOVYBFwERDgEXb48jg1CIeopvkRMsB4J6gRcFC4ZRgTa?= =?us-ascii?q?SOSKiaIYiGI1fixqRNDkahj+BejMaH1SBQhiBD1AZDVaOcAEIAYJCilcVMDA?= =?us-ascii?q?CNQIGCgEBAwlZAQGJeyyCGgEB?= X-IPAS-Result: =?us-ascii?q?A2CjCABjEwJg/1enWttiHAEBAQEBAQcBARIBAQQEAQFHg?= =?us-ascii?q?UiBfIElV2KEP4kEhjIBghYDOE2DH4psi1GBTAMNCwEBAQEBAQEBASEBCgkBA?= =?us-ascii?q?gQBAYREBAICgW4mOBMCEAEBAQUBAQEBAQYDAYZSDIVzAQEBAQIBAQEhBC8YG?= =?us-ascii?q?wsIBgIIHA4CAicwBgESG4JASwGCVQEBDx8Qrm12fzOEQAGBBhOCEQaBDYE9B?= =?us-ascii?q?oE4hnUBgkyDcjWBTT+BETaCLjU+gl0BAQIXhF6CYASBVAZkBgEUFwRcExgJE?= =?us-ascii?q?QYCOVYBFwERDgEXb48jg1CIeopvkRMsB4J6gRcFC4ZRgTaSOSKiaIYiGI1fi?= =?us-ascii?q?xqRNDkahj+BejMaH1SBQhiBD1AZDVaOcAEIAYJCilcVMDACNQIGCgEBAwlZA?= =?us-ascii?q?QGJeyyCGgEB?= X-IronPort-AV: E=Sophos;i="5.79,350,1602518400"; d="scan'208,217";a="343701849" Received: from 219-90-167-87.ip.adam.com.au (HELO swtf.swtf.dyndns.org) ([219.90.167.87]) by icp-osb-irony-out8.iinet.net.au with ESMTP; 16 Jan 2021 06:18:36 +0800 Message-ID: Subject: Re: Occasional delayed output of events From: Burn Alting To: Steve Grubb , Linux Audit Date: Sat, 16 Jan 2021 09:18:35 +1100 In-Reply-To: References: <30c5dbc14368a1919717e2f39d2d4c29463c3108.camel@iinet.net.au> <5426593.DvuYhMxLoT@x2> <1340951117184f479e4f5dc75766fba91ed2c085.camel@iinet.net.au> <2756596.e9J7NaK4W3@x2> <8368b5c67757f2de8f664bc2eef5f5ca153a0c87.camel@iinet.net.au> Mime-Version: 1.0 X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-loop: linux-audit@redhat.com X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk Reply-To: burn@swtf.dyndns.org List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=linux-audit-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="===============7279972573250251059==" --===============7279972573250251059== Content-Type: multipart/alternative; boundary="=-PoGI7bJsnXtzgg9hwSrB" --=-PoGI7bJsnXtzgg9hwSrB Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Sun, 2021-01-10 at 15:39 +1100, Burn Alting wrote: > On Tue, 2021-01-05 at 07:12 +1100, Burn Alting wrote: > > On Mon, 2021-01-04 at 09:46 -0500, Steve Grubb wrote: > > > On Monday, January 4, 2021 2:55:25 AM EST Burn Alting wrote: > > > > On Sun, 2021-01-03 at 10:41 -0500, Steve Grubb wrote: > > > > > On Friday, January 1, 2021 4:22:33 PM EST Burn Alting wrote: > > > > > > Sometimes, events recorded in /var/log/audit/audit.log appear > > > > > > someseconds past co- located events which results > > > > > > inauparse:au_check_events() marking these events complete before > > > > > > theyare. An example of this can be seen below with the offending event > > > > > > id44609. > > > > > > This has been plaguing me for a year or two and this morning was > > > > > > thefirst time I still had access to the raw audit.log files (I monitor a > > > > > > lotof event types and the log files roll over fairly quickly).The > > > > > > example below is from a fully patched Centos 7 but I have also seenthis > > > > > > 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 > > > > > lightprocessing of the event. If the format is enriched, it looks things > > > > > upon a record by record basis. It does not collect events until they > > > > > arecomplete - it dumps it to disk as soon as it can tack on the > > > > > extrainformation. > > > > > So, the question would be, does this delay happen on the way to disk? Oris > > > > > this an artifact of post processing the logs with an auparse basedutility? > > > > > Can this be observed repeatedly on the same raw logs? If so,then maybe > > > > > auparse does have some issue. But if this is a postprocessing issue, then > > > > > the wall clock doesn't matter because this eventshould have collected up > > > > > together. > > > > > I'd say this merits some investigation. > > > > > > > > OK. I think this needs to be addressed on two fronts. There may be > > > > more.A. Within post processing ... a 2 second timeout is not sufficient. > > > > Iwould suggest we modify auparse.c:au_check_events() to i) perform theevent > > > > type checks first, then ii) increase the timeout of 2 seconds to be a > > > > larger value based onempirical tests. > > > > > > In the post processing, there are 2 use cases. The first is events that are on > > > disk. In this usage, the 2 second timeout does not come into effect because > > > the events are run through probably within nanoseconds or microseconds at the > > > worst. The only time it would come into effect is if the terminating record is > > > missing. > > > > In this first case, the 2 second timeout is on the event's time, not the > > 'processing time'. See ausearch-lol.c:check_events() and > > auparse.c:au_get_ready_event(). > > And I use the checkpointing code to avoid the incomplete event issue. > > > > In my case, I have not lost records, it's just that an event has arrived on disk > > with an event time more than 2 seconds after the previously written event. > > Basically, > > a. The event was delayed getting to auditd and we look to the kernel for a > > solution. > > b. The event arrived at a reasonable point in time at auditd and for some reason > > auditd delayed it's printing (by the way I tend to use RAW log format, not > > enriched. > > > > In either case, I believe ausearch-lol.c:check_events() and > > auparse.c:au_get_ready_event() do need to be changed as we have complete events > > written by auditd > > which these two routines fail to process properly. > > > Changing the two second timeout in ausearch-lol.c:check_events() and, one assumes > in auparse.c:au_get_ready_event() (but I have not tested the auparse code) fixes > the processing of the delayed event. > Changing the value to say 10 seconds fixes my example use case, but given the > kernel or auditd could emit an event with a larger delay, should this be a > configuration item in /etc/audit/auditd.conf? > > I have raised both a bugzilla report ( > https://bugzilla.redhat.com/show_bug.cgi?id=1914603) and Issue ( > https://github.com/linux-audit/audit-userspace/issues/148) > > How do you want me to proceed ... a simple change to 10 seconds or a more > versatile configuration item in auditd.conf? > I can perform either and issue a PR if so required. What do people think ... I would point out this currently occurs in both audit- 2.8.5-4.el7.x86_64 and audit-3.0-0.17.20191104git1c2f876.el8.x86_64 and a just compiled checkout of the audit-userspace code audit-3.0-1.fc33.x86_64. I have found examples (under audit-3.0-0.17.20191104git1c2f876.el8.x86_64) that I need a 15 second delay. I accept there may be an issue in the kernel but if it is not simple (I only see this occasionally), then we need a fix in the userspace. Since I have found varied times required, do I go down the path of a big value OR a configuration item in /etc/audit/auditd.conf? > > > > The other use case is realtime processing as an audispd plugin. In this use > > > case the wall clock could matter because records could potentially get lost > > > due to overflows or another plugin taking too long. This is the use case where > > > the wall clock matters. And again, it matters when records get lost or delayed > > > in transit. As long as everything is flowing, it should not factor into event > > > processing. > > > > B. I will build a temporary auditd daemon to perform some empirical > > > > testingto see how long events can reside within the daemon. I may need > > > > someadvice on this. I assume that the code that sets the timestamp is > > > > insrc/auditd.c:send_audit_event(). > > > > > > This is only for audit daemon's internal events. For all "real" events, it's > > > set in the kernel. > > > > If that is the case and the kernel is establishing the timestamp, then either > > the kernel has delayed the eventsarrival at the daemon or the daemon has delayed > > it's writing. > > > > If so, I will see if I can put orchestration debug code in to monitor > > > > anevent's 'time in daemon' until this point. I will then report on this. > > > > I believe given that AUDIT_PROCTITLE and AUDIT_EOE is fairly widespread,then > > > > the testing switch in A. will not be a big issue (time cost wise). Itwill > > > > also mean that if we over compensate the timeout that would causeadditional > > > > memory cost in auparse() then this is mittigated. > > > > > > I'd suggest breaking up the event completion tests so that an exact collection > > > termination reason code could be associated to the event. > > > > With respect to 'There may be more' fronts. Are there other points in > > > > the'audit ecosystem' that makes use of the '2 second timeout'. > > > > > > Ausearch/report has its own special copy of the event collection logic. It > > > should be nearly identical to what auparse does. > > > > They appear identical ... ausearch-lol.c:check_events() and > > auparse.c:au_get_ready_event(). > > > > I will start work on this, this coming weekend if the above makes sense. > > > > > > One other thought, the current shipping code is audit-3.0, doing a diff > > > between it and audit-2.8.5 for the auparse directory does show some > > > differences in event collection/grouping/next_event. A lot of the differences > > > are cosmetic to fix extra whitespace or indentation. But if you skip all that, > > > there are some real changes that probably were because of bug reports. For > > > example, > > > > I will go through these, although this occurs on my Centos 7's (audit-2.8.5- > > 4.el7.x86_64) as well as my 8's (audit-3.0-0.17.20191104git1c2f876.el8.x86_64). > > > @@ -259,15 +260,6 @@ static event_list_t *au_get_ready_event( if > > > (lowest && lowest->status == EBS_COMPLETE) { lowest->status = > > > EBS_EMPTY; au->au_ready--;- // Try to consolidate > > > the array so that we iterate- // over a smaller portion next > > > time- if (lowest == &lol->array[lol->maxi]) > > > {- au_lolnode *ptr = > > > lowest;- while (ptr->status == EBS_EMPTY && lol->maxi > > > > 0) {- lol->maxi > > > --;- ptr = &lol->array[lol > > > ->maxi];- }- } return > > > lowest->l; } > > > and > > > @@ -1536,6 +1550,13 @@ static int > > > au_auparse_next_event(auparse aup_list_create(l); > > > aup_list_set_event(l, &e); aup_list_append(l, au->cur_buf, > > > au->list_idx, au- > > > > line_number); > > > + // Eat standalone EOE - main event was already marked > > > complete+ if (l->head->type == AUDIT_EOE) > > > {+ au->cur_buf = > > > NULL;+ aup_list_clear(l);+ free(l) > > > ;+ continue;+ } if > > > (au_lol_append(au->au_lo, l) == NULL) { free((char > > > *)e.host); #ifdef LOL_EVENTS_DEBUG01 > > > I don't know if those have an effect on what you are seeing. But that is the > > > only substantial changes that I can see. > > > -Steve > > Burn > > --Linux-audit mailing listLinux-audit@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit --=-PoGI7bJsnXtzgg9hwSrB Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
On Sun, 2021-01-10 at 15:39 +1100, Burn Alting wrote:
On Tue, 2021-01-05 at 07:12 +1100, Burn Alting wro= te:
On Mon, 2021-01-04 at 09:46 -0500,= Steve Grubb wrote:
On Monday, January=
 4, 2021 2:55:25 AM EST Burn Alting wrote:
= 
On Sun, 2021-01-03 at 10:41 -0500, Steve Grubb wrote:
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 even=
ts which results in
auparse:au_check_events() marking  these even=
ts complete before they
are. An example of this can be seen below=
 with the offending event id
44609.

This has been p=
laguing 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 exa=
mple 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 secon=
ds 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 re=
cord basis. It does not collect events until they are
complete - =
it dumps it to disk as soon as it can tack on the extra
informati=
on.

So, the question would be, does this delay happen on the =
way to disk? Or
is this an artifact of post processing the logs w=
ith 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 doe=
sn't matter because this event
should have collected up together.=


I'd say this merits some investigation.
OK. I think this needs to be addressed on two fronts. There may be m=
ore.
A.  Within post processing ... a 2 second timeout is not suf=
ficient. I
would suggest we modify auparse.c:au_check_events() to=
 i) perform the
event type checks first, then
  ii) inc=
rease the timeout of 2 seconds to be a larger value based on
empi=
rical tests.

In the post processing, there are 2=
 use cases. The first is events that are on 
disk. In this usage,=
 the 2 second timeout does not come into effect because 
the even=
ts are run through probably within nanoseconds or microseconds at the 
worst. The only time it would come into effect is if the terminating =
record 
is missing.

In this= first case, the 2 second timeout is on the event's time, not the 'processi= ng time'. See ausearch-lol.c:check_events() and auparse.c:au_get_ready_eve= nt().
And I use the checkpointing code to avoid the incomplete ev= ent issue.

In my case, I have not lost records, it= 's just that an event has arrived on disk with an event time more than 2 se= conds after the previously written event.
Basically,
a.= The event was delayed getting to auditd and we look to the kernel for a so= lution.
b. The event arrived at a reasonable point in time at aud= itd and for some reason auditd delayed it's printing (by the way I tend to = use RAW log format, not enriched.

In either case, = I believe ausearch-lol.c:check_events() and auparse.c:au_get_ready_event() = do need to be changed as we have complete events written by auditd
which these two routines fail to process properly.

Changing the two second timeout in ausearch-lol.c:check_eve= nts() and, one assumes in auparse.c:au_get_ready_event() (but I have not t= ested the auparse code) fixes the processing of the delayed event.
Changing the value to say 10 seconds fixes my example use case, but give= n the kernel or auditd could emit an event with a larger delay, should this= be a configuration item in /etc/audit/auditd.conf?

I have raised both a bugzilla report (https://bugzilla.redhat.com/show_bug.cgi?id= =3D1914603) and Issue (https://github.com/linux-audit/audit-userspace/issues= /148)

How do you want me to proceed ... a simp= le change to 10 seconds or a more versatile configuration item in auditd.co= nf?
I can perform either and issue a PR if so required.

What do people think ... I would point out thi= s currently occurs in both audit-2.8.5-4.el7.x86_64 and audit-3.0-0.17.2019= 1104git1c2f876.el8.x86_64 and a just compiled checkout of the audit-userspa= ce code audit-3.0-1.fc33.x86_64.

I have found exam= ples (under audit-3.0-0.17.20191104git1c2f876.el8.x86_64) that I need a 15 = second delay.

I accept there may be an issue in th= e kernel but if it is not simple (I only see this occasionally), then we ne= ed a fix in the userspace. Since I have found varied times required, do I g= o down the path of a big value OR a configuration item in /etc/audit/auditd= .conf?


The other use case is=
 realtime processing as an audispd plugin. In this use 
case the =
wall clock could matter because records could potentially get lost
due to overflows or another plugin taking too long. This is the use case= where 
the wall clock matters. And again, it matters when record=
s get lost or 
delayed in transit. As long as everything is flowi=
ng, it should not factor 
into event processing.

B. I will build a temporary auditd daemon to perfo=
rm some empirical testing
to see how long events can reside withi=
n the daemon. I may need some
advice on this. I assume that the c=
ode that sets the timestamp is in
src/auditd.c:send_audit_event()=
.

This is only for audit daemon's internal event=
s. For all "real" events, it's 
set in the kernel.

If that is the case and the kernel is establishing = the timestamp, then either the kernel has delayed the events
arri= val at the daemon or the daemon has delayed it's writing.


If so, I =
will see if I can put orchestration debug code in to monitor an
e=
vent's 'time in daemon' until this point. I will then report on this.
= 
I believe given that AUDIT_PROCTITLE and AUDIT_EOE is fairly wides=
pread,
then the testing switch in A. will not be a big issue (tim=
e cost wise). It
will also mean that if we over compensate the ti=
meout that would cause
additional memory cost in auparse() then t=
his is mittigated.

I'd suggest breaking up the e=
vent completion tests so that an exact 
collection termination re=
ason code could be associated to the event.

With respect to 'There may be more' fronts. Are there other point=
s in the
'audit ecosystem' that makes use of the '2 second timeou=
t'.

Ausearch/report has its own special copy of =
the event collection logic. It 
should be nearly identical to wha=
t auparse does.

They appear identical= ... ausearch-lol.c:check_events() and auparse.c:au_get_ready_event().

I will sta=
rt work on this, this coming weekend if the above makes sense.

One other thought, the current shipping code is audit-3.0, d=
oing a diff 
between it and audit-2.8.5 for the auparse directory=
 does show some 
differences in event collection/grouping/next_ev=
ent. A lot of the differences 
are cosmetic to fix extra whitespa=
ce or indentation. But if you skip all that, 
there are some real=
 changes that probably were because of bug reports. For 
example,=


I will go through these, although this occurs o=
n my Centos 7's (audit-2.8.5-4.el7.x86_64) as well as my 8's (audit-3.0-0.1=
7.20191104git1c2f876.el8.x86_64).


= 
@@ -259,15 +260,6 @@ static event_list_t *au_get_ready_event(
if (lowest && lowest->status =3D=3D EBS_COMPLETE) {
                lowest->status =3D EBS_EMPTY;
        =
        au->au_ready--;
-               // Try to consolidate =
the array so that we iterate
-               // over a smaller po=
rtion next time
-               if (lowest =3D=3D &lol->ar=
ray[lol->maxi]) {
-                       au_lolnode *ptr =3D =
lowest;
-                       while (ptr->status =3D=3D EBS_=
EMPTY && lol->maxi > 0) {
-                        =
       lol->maxi--;
-                               ptr =3D &a=
mp;lol->array[lol->maxi];
-                       }
- }
                return lowest->l;
}
and

@@ -1536,6 +1550,13 @@ static =
int au_auparse_next_event(auparse
                aup_list_create=
(l);
                aup_list_set_event(l, &e);
   =
             aup_list_append(l, au->cur_buf, au->list_idx, au-
<= blockquote type=3D"cite" style=3D"margin:0 0 0 .8ex; border-left:2px #729fc= f solid;padding-left:1ex">
line_number);
+      =
         // Eat standalone EOE - main event was already marked 
c=
omplete
+               if (l->head->type =3D=3D AUDIT_EOE)=
 {
+                       au->cur_buf =3D NULL;
+  =
                     aup_list_clear(l);
+                       f=
ree(l);
+                       continue;
+            =
   }
                if (au_lol_append(au->au_lo, l) =3D=3D NU=
LL) {
                        free((char *)e.host);
 #i=
fdef LOL_EVENTS_DEBUG01

I don't know if those have an effect =
on what you are seeing. But that is the 
only substantial changes=
 that I can see.

-Steve
<= br>
Burn
--
Linux-audit mailing list
Linux-audit@redhat.com

https://www.r=
edhat.com/mailman/listinfo/linux-audit
 --=-PoGI7bJsnXtzgg9hwSrB-- --===============7279972573250251059== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit --===============7279972573250251059==--