This is a followup from coreos/fedora-coreos-tracker#220.

The environment is a recent Fedora CoreOS, akin to a small F31, as follows:

$ systemctl --version
systemd 243 (v243.7-1.fc31)
+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=unified

$ uname -a
Linux localhost 5.5.8-200.fc31.x86_64 #1 SMP Thu Mar 5 21:28:03 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Unexpected behaviour you saw

The scenario is:

• the OS does not have any auditd installed (nor running)
• the kernel is booted without any explicit audit= kernel argument
• both systemd-journald.service and systemd-journald-audit.socket are running without errors

In that case, audit events are correctly enabled by journald and received+logged (with proper _TRANSPORT value).
However, the same events are also duplicated to the primary system console, spamming it.
Interestingly, installing and running auditd on top of the same system and configuration, prevents this console spamming from happening.

I'm not sure whether this is a bug, and where to pinpoint it.
Looking at existing reports, I've seen https://bugzilla.redhat.com/show_bug.cgi?id=1459326 which covers auditd and some registration bug with the kernel. It seems similar, but about different codebases/designs.

Is this behavior with journald and auditing expected?
Or is this a bug in the interaction between journald and the auditing kernel subsystem?