When an application cannot get an audit event to the kernel, libaudit.conf decides what happens next: ignore it, log it, or kill the process. That is the whole job of this one file, linked in by any application that chooses to read it. Allow about ten minutes for a cautious change and verification. This guide is for the installed Ubuntu package libaudit-common 1:3.1.2-2.1build1.1.
Checkpoint: /etc/libaudit.conf is not an audit rule file and does not switch kernel auditing on or off. It holds one setting for user-space applications that choose to read it. Those applications are responsible for querying the file and obeying it, so changing it does not guarantee every program on the host will react.
Read the installed file before deciding whether it needs changing. This is an ordinary read and needs no elevated privileges:
$ dpkg-query -W -f='${Package} ${Version}\n' libaudit-common
libaudit-common 1:3.1.2-2.1build1.1
$ sed -n '1,80p' /etc/libaudit.conf
# This is the configuration file for libaudit tunables.
# It is currently only used for the failure_action tunable.
# failure_action can be: log, ignore, terminate
failure_action = ignoreThe installed file uses lower-case values; keep that spelling when editing this host. The manual describes the same three values as IGNORE, LOG and TERMINATE, but documents no additional keywords, sections, or a default you can safely assume. If the file is missing, do not invent a replacement policy until you have checked the documentation for the application and package that will actually consume it.
ignore means the application does nothing about the send failure.log means the application writes the inability to send an audit event to syslog.terminate means the application exits.ignore avoids interrupting the application, but a lost audit event becomes easy to miss. log gives an operational signal without stopping anything. terminate is the strictest choice: use it only when stopping the affected process is an acceptable response to an audit delivery failure. Do not pick it for a production service without confirming that service's recovery and availability behaviour first.
Security warning: this setting changes failure handling, not event content or audit coverage, and it is no substitute for an audit policy review. To change rules, look at audit.rules, auditctl or your distribution's audit service documentation instead.
Changing the system-wide file needs elevated privileges. Make a dated backup first:
$ sudo cp --preserve=all /etc/libaudit.conf /etc/libaudit.conf.backup-2026-09-24A silent, successful command prints nothing. Check both files before opening an editor:
$ sudo test -r /etc/libaudit.conf && sudo test -r /etc/libaudit.conf.backup-2026-09-24 && echo 'backup ready'
backup readyThat backup is a recovery copy, not a second file libaudit will read. Do not leave several ambiguous copies sitting in /etc and forget which one holds the setting you actually want.
Use an editor that writes the file with root privileges:
$ sudoedit /etc/libaudit.confKeep exactly one active assignment, using one of the three installed values. For a syslog signal, the resulting line is:
failure_action = logDo not add a new keyword, a section header or shell syntax, and keep comments separate from the assignment. Before saving, check the editor is changing /etc/libaudit.conf and not the backup. If you decide not to proceed, exit without saving and the original file stays exactly as it was.
There is no service restart command in the manpage. The setting is read by applications that choose to query the file, so whether a running process notices your change is entirely application-specific. Treat a restart as a separate operational decision, not something to do automatically because this file changed.
After saving, inspect the file as root and confirm the active assignment is exactly the one you intended:
$ sudo sed -n '1,80p' /etc/libaudit.conf
# This is the configuration file for libaudit tunables.
# It is currently only used for the failure_action tunable.
# failure_action can be: log, ignore, terminate
failure_action = log
$ sudo grep -Eq '^[[:space:]]*failure_action[[:space:]]*=[[:space:]]*(log|ignore|terminate)[[:space:]]*$' /etc/libaudit.conf && echo 'failure_action value is recognised'
failure_action value is recognisedThat check confirms the line's shape and value, nothing more. It does not prove an application has queried the file, that syslog received a message, or that termination would actually occur during a real audit-send failure; those behaviours belong to the consuming application and the conditions around its audit call.
If you picked the wrong action or the file now has an unwanted edit, restore the backup. This overwrites the current configuration, so confirm both paths before running it:
$ sudo cmp -s /etc/libaudit.conf.backup-2026-09-24 /etc/libaudit.conf || echo 'files differ; restore only if this is the intended backup'
$ sudo cp --preserve=all /etc/libaudit.conf.backup-2026-09-24 /etc/libaudit.conf
$ sudo cmp -s /etc/libaudit.conf.backup-2026-09-24 /etc/libaudit.conf && echo 'original configuration restored'
original configuration restoredThe restore only changes this configuration file. It does not undo a service restart or recover an audit event that has already been missed. If the application stopped because it read terminate, recover it through that application's normal service or process procedure, after restoring a suitable action.
libaudit-common version and read the file before changing it.ignore, log or terminate, picked for a stated operational need.failure_action assignment changed, and a dated backup exists.