From: Lenny Bruzenak <lenny@magitekltd.com>
To: linux-audit@redhat.com
Subject: Re: Occasional delayed output of events
Date: Tue, 19 Jan 2021 09:31:55 -0600 [thread overview]
Message-ID: <f88bcc6a-e8a8-61e3-af61-d2897df892d0@magitekltd.com> (raw)
In-Reply-To: <9a7ed1203fa7ec67000aa68281a215354c2ed5f5.camel@iinet.net.au>
[-- Attachment #1.1: Type: text/plain, Size: 1337 bytes --]
On 1/19/21 2:18 AM, Burn Alting wrote:
>> Anyway, my test setup isn't likely able to reproduce such a scenario
>> without some significant tweaks, so perhaps those of you who have seen
>> this problem (Burn, and anyone else?) could shed some light into the
>> state of the system when the ordering problem occurred.
>
> I tend to have a rigorous auditing posture (see the rules loaded in
> https://github.com/linux-audit/audit-userspace/issues/148) which is
> not normal for most. Perhaps, Paul, you have hit the nail on the head
> by stating that this 'severe delay' is not that unreasonable given my
> rules posture and we just need to 'deal with it' in user space.
> We still get the event data, I just need to adjust the user space
> tools to deal with this occurrence.
> As for what the system is doing, in my home case it's a Centos 7 VM
> running a tomcat service which only gets busy every 20 minutes and the
> other is a HPE Z800 running Centos 8 with 4-5 VM's mostly dormant. I
> can put any code in these hosts to assist in 'validating'/testing the
> delay. Advise and I will run.
Looking at the records which appear to be delayed (in OP), I see that
they are PATH (w/PROCTITLE). Just curious, is the path involved part of
a networked FS, or something like a VM shared directory?
Thx,
LCB
--
Lenny Bruzenak
MagitekLTD
[-- Attachment #1.2: Type: text/html, Size: 2213 bytes --]
[-- Attachment #2: Type: text/plain, Size: 102 bytes --]
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
next prev parent reply other threads:[~2021-01-19 15:32 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
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 [this message]
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=f88bcc6a-e8a8-61e3-af61-d2897df892d0@magitekltd.com \
--to=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