Description of problem: By default, systemd logs audit info to the journal, see systemd-journald-audit.socket(8) Now, when I install audit, it enables auditd.service by default. This runs auditd, which is configured by default in /etc/audit/auditd.conf to log audit info to /var/log/audit/audit.log. Thus, effectively, audit info is logged twice. auditd is required for audispd which is required for setroubleshoot to work Version-Release number of selected component (if applicable): audit-2.7.6-1.fc25.i686 How reproducible: always Steps to Reproduce: 1. install auditd Actual results: audit info logged to journal as well as /var/log/audit/audit.log Expected results: only one location logged to.
There is some discussion at bug 1227379, though it complains about /var/log messages, not journal vs. audit.log
So, what is the problem? Auditd is designed to collect and handle audit information and journald has no business doing that. If the author of journald decided on behalf of everyone that they want to waste your disk space, isn't that where the bug belongs?
I'm just seeing that it is logged twice after audit is installed. Whether it should be only audit or only journald that is logging I cannot say. Feel free to assign the bug to systemd if you think that this will solve the problem.
Hello. One thing that you can do to fix it on your machine is to edit /etc/audit/auditd.conf. Set write_logs = no. Then restart auditd using the service command. This will make the events available to setroubleshoot and without writing anything to disk.
poettering says on https://github.com/systemd/systemd/issues/959 "Audit can be potentially useful, and we should centralize it by default in the journal" So should perhaps write_logs = no be the default? Another option would be to execute systemctl mask --now systemd-journald-audit.socket; systemctl restart systemd-journald.service in postinstall and systemctl unmask systemd-journald-audit.socket; systemctl restart systemd-journald.service in preuninstall.
Unless there is a good reason to keep this open, I will close it as not a bug. None of the audit tools work against the journal, so Lennart's suggestion is a non-starter.
Thanks for reporting this issue. I don't think there is anything I can do here. Audit tooling does not work against the journal.