On Wednesday 07 January 2009 06:11:37 pm Linda Knippers wrote:
The first makes more sense to me. If an auditd is happily running,
starting a second one is an error.
Yes, but how can you detect that on an async protocol? The kernel would have
to look and verify the original pid is alive, then look to see if there is a
matching netlink socket for that pid.
At some point in the past, the kernel only knew that an auditd was dead on
attempting to use the socket. I don't know if its still the same way, but if
it were, then you don't really know if the audit daemon is alive so you may
as well trust the second one under the assumption that its a restarted daemon
to replace the crashed one the kernel didn't know about yet.
Disconnecting a running auditd seems problematic. What happens to
audit
messages in flight?
It just won't get anything and will error out next time it tries to read
events.
Is there a race where both auditds will be writing to
the log?
Yes, that is why the first needs to go away.
-Steve