Hello,
On Wed, Jul 9, 2025 at 2:40 PM <nupurde...@gmail.com> wrote:
> retval= select(1, &read_mask, NULL, NULL, &tv);
> } else {
> retval= select(1, &read_mask, NULL, NULL, NULL); >>>>>>
> here it cores
> }
>
> how do we know without much logs the cause of it receiving SIGABORT ? Any
> suggestions ? the backtrace is showing EBADF
>
Auditd plugins read stdin to receive events. If it gets closed, then you
would have a bad fd.
> I see you made a recent change to handle SIGTERM
>
The recent change to SIGTERM is to prevent systemctl induced problems.
Auditd is not designed to be managed by systemctl. When you run systemctl
stop auditd, it signals the whole process group. Plugins can terminate
before auditd lets the audisp thread know it should shutdown plugins. It
then restarts the plugin. Eventually audisp realizes we are shutting down
and it starts terminating plugins. This creates a chaotic shutdown.
The intended way to shutdown auditd is with the service command. This is
because it directly interacts with auditd by sending a signal. The kernel
notices this and keeps info on who sent the signal. When auditd sees
SIGTERM, it asks the kernel who sent it? It then records this as part of
the shutdown. If you use systemctl, it uses dbus activation to start a
helper with a clean environment. It does not have the login uid associated
with it. So, we can't tell who sent the signal. This is a requirement in
many security standards. If you can't use the service command, the correct
method would be auditctl --signal term.
-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
