auditd stop suggestion

[Steve Grubb]

On Tuesday 14 June 2005 15:34, Michael C Thompson wrote:
> what is happening with our test cases is the following:
>
> system("/etc/rc.d/init.d/auditd start");
> ...
> TEST(syscall(..))
> ...
> system("/etc/rc.d/init.d/auditd stop");
>
> Now, the outter portion of the code here (that is, before the start, and
> after the stop) should not be affecting the actions taken between start and
> stop (seems obviously correct, could be wrong). The issue we're
> experiencing is that when the stop is called, the audit.log file has no
> trace of what has transpired between the "start" & "stop" auditd calls.
> However, without putting sleeps (e.g. sleep(2); seems to be the most
> effective) before we call "../auditd stop" then the records in file which
> we are hoping to verify with are not there, unless we prolong the stop
> (i.e. with a sleep).

Right you need to add a sleep. audit records do not show up instantaneously. 
How long it takes could be subject to debate. I'd be more interested in 
figuring that out.

> As it was explained to me, the way the stop works is when auditd is told to
> "stop", the daemon dies,

Not really. It goes through a series of steps to stop processing and write the 
shutdown record. It does not just die.

> and any audit messages still in the queue are 
> "lost" in respect to the log file. 

This is true. Stopping the audit daemon is an arbitrary act. You cannot tell 
it stop after I get what I want. When you say stop...it has to stop.

> If you could confirm that, or point me 
> to a place where that's documented and I'll read it for my self, it would
> help me to understand the behaviour better.

Its in the auditd code. No docs.

> OK, good point. I remember it being mention during a meeting, but was there
> any further discussion about a "auditd stop" & "auditd shutdown" option? 

No.

> Right, the tests we are running are not a good indicator of the way
> auditd's running status will be treated in a real environment, but there
> must be some valid reasons for stopping auditd outside of a shutdown in a
> real environment, which would still have this queue issue. 

How would you know that what you want is already written to disk? If you have 
a stream of events coming in non-stop and you have to stop the audit daemon, 
you are going to have to cut off at some point. How can you pick any packet 
as the last one? They are all equally important. So, the daemon may as well 
stop at the instant its told to.

-Steve