#ausearch

Saw a similar rpmdb lock bug to this: https://bugzilla.redhat.com/show_bug.cgi?id=918184 Have enabled the audit log to watch out for it in the future.

ush@gargantua ~]$ sudo dnf update [sudo] password for ush: warning: rpmdb: BDB2053 Freeing read locks for locker 0xc24: 12836/139735431249280

The auditd logging system is completely independent of syslog and derivatives http://security.blogoverflow.com/2013/01/a-brief-introduction-to-auditd/ Q: is it now more integrated with journald? PanuMatilainen suggested https://bugzilla.redhat.com/show_bug.cgi?id=918184#c1

# echo "-w /var/lib/rpm/Packages -p war -k rpmdb" >> /etc/audit/audit.rules # systemctl restart auditd.service After that, the next time that something has misbehaved and you get those "freeing read locks ...: /" messages, you can look rpmdb accessing processes by their pid with # ausearch -k rpmdb --pid To identify the troublemaker for sure, the pid of the "freeing read locks" message needs to be matched to those of audit logs. Taking the original message as an example: BDB2053 Freeing read locks for locker 0x1bf4: 4981/140246004406208 Here, the pid of the naughty process who left locks behind is 4981. So to search for the process that caused it, you need to do: # ausearch -k rpmdb --pid 4981

Instead have appended the new audit rule to /etc/audit/rules.d/audit.rules The systemctl restart of the auditd is no longer possible. Use augenrules instead. Do I really need to disable the -a never,task and what is its actual impact on performance?:

[ush@gargantua ~]$ sudo auditctl -l -a never,task [ush@gargantua ~]$ sudo augenrules --load No rules [ush@gargantua ~]$ sudo auditctl -l -a never,task -w /var/lib/rpm/Packages -p rwa -k rpmdb

This seems to be the best reference (is pointed to in the systemd unit) https://github.com/linux-audit/audit-documentation/wiki/SPEC-Writing-Good-Events https://security.stackexchange.com/questions/4629/simple-example-auditd-configuration Seems like the rules should be broken into 3 types in /etc/audit/rules.d/audit.rules (for clarity): CONTROL, FILE/DIRECTORY, SYSCALL (see man audit.rules). Syscall rules should follow the template:

-a action,list -S syscall -F field=value -k keyname

-a {always,never},{task,exit,user,exclude} -S {name or number} -S {othername or number} -F {auid,uid,euid,suid,fsuid,obj_uid,gid,egid,sgid,fsgid,obj_gid} -k $keyname-defined-by-you

Then

aureport --start this-week --key --summary