On Tuesday, May 14, 2024 1:58:35 PM EDT nupurde...@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 _______________________________________________ Linux-audit mailing list -- linux-audit@lists.linux-audit.osci.io To unsubscribe send an email to linux-audit-le...@lists.linux-audit.osci.io
