Re: audisp-plugin.
On Tuesday, May 14, 2024 1:58:35 PM EDT nupurdeora(a)gmail.com wrote:
Another question is , Is there a metric on the number of events that
the
sample audisp-example.c can handle without queuing ?
It depends entirely on how much processing you are doing. There are syslog
and af_unix plugins that do very little processing and can keep up. But if
you do networking it can take time for the other end to ACK that it received
it.
The audit daemon also has an internal queue between the logger and the
realtime interface. This queue is shared by all plugins from the stand point
that the current event is not retired until all plugins have seen it. So, if
your plugin is slow, it affects the speed of the other plugins.
So, it is important to dequeue inbound events from stdin ASAP. If you are
slow, then it may cause auditd's internal queue to fill. When that happens, it
can't dequeue anything from the kernel and it starts backing up. Depended on
what you set for the the kernel failure action, you could panic the kernel if
it fills up.
The safest thing is to make 2 threads, one dequeing and the other processing.
This way events keep flowing and don't backup somewhere.
Also how do I control or link the start & stop of the plugin when
I do
something like "service auditd restart" ?
When you do a restart, auditd receives a SIGTERM. It in turn sends SIGTERM to
all child processes. The example plugin has a SIGTERM handler and causes the
plugin to exit. When you get SIGTERM, you should do whatever you need to do
to cleanup and exit asap. Systemd can intervene with SIGKILL if a daemon
hasn't exited within a "reasonable" time. We don't want that.
-Steve