Sales Guy at EnterpriseDB,
open sourcerer

Shut up, auditd!

Audit logging

(Happy 2021, may it be better than 2020!)

On my tiny, Raspberry Pi based Fedora systems, I have a lot of audit messages in my journal. And I mean a lot, I mean like over 50,000 over the course of 9 days. That’s over 5,500 per day. Or, to put it plainly: too many.1

Jan 02 12:20:31 system.domain.lan audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=someunit comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? te [...]
Jan 02 12:20:51 system.domain.lan audit[471147]: CRYPTO_KEY_USER pid=471147 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=SHA256:77:39:df:9f:00:00:00:0 [...] 
Jan 02 12:20:51 system.domain.lan audit[471147]: USER_LOGIN pid=471147 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="(unknown)" exe="/usr/sbin/sshd" hostname=? ad [...]

These logs take up space and consume resources that are scarse on a Raspberry Pi. Therefore, I set off to disable them.


The first thing I tried is setting Audit=no in /etc/systemd/journald.conf, but that didn’t work. As man 5 journald.conf says:

Note that this option does not control whether systemd-journald collects generated audit
records, it just controls whether it tells the kernel to generate them. This means if
another tool turns on auditing even if systemd-journald left it off, it will still
collect the generated messages.

The audit socket

The audit messages originate from the Linux kernel audit framework. In order to quiet them down, you can pass audit=0 to the kernel at boot time. This prevents the kernel from logging and the systemd-journald-audit.socket unit from starting up. That means no more audit log messages in my journal.

Configuring grub

Just open /etc/default/grub and append audit=0 to the line that starts with GRUB_CMDLINE_LINUX. Regenerate your grub.cfg with the following command:

WARNING: You really need to verify whether (a) your grub.cfg is in the same location as mine2, and (b) whether this command doesn’t do anything funky on your system. A broken grub.cfg will render your system unbootable!! Make sure you at least have a backup of the original grub.cfg.

sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

Now reboot your system. That should do it.

  1. I do understand there is a purpose to these messages, and that not everyone should disable them. I also understand that I might have been artificially increasing the number of log messages by using monit to check on running services. 

  2. It should be if you are on a UEFI system, but check anyway.