Bug 2190166

https://access.redhat.com/solutions/5736961


Looks like 8192 is the default that would be set by auditd after the service starts - it is substantially more than the default 64 ...
We could increase by adding audit_backlog_limit=8192 on the kernel command line as well.

File: /etc/audit/rules.d/audit.rules - contains:

## Increase the buffers to survive stress events.
## Make this bigger for busy systems
-b 8192


If we don't set audit=1 some processes will not be auditable without a reboot.

Hi Vijayalakshmi,

Do you have this issue reproduced in some lab?

Can you try:
1. to remove the audit=1 on a reboot.
   Does it fix the issue with auditd.service not starting?
2. Keep audit=1 but add audit_backlog_limit=8192.
   Does it fix the issue with auditd.service not starting?


Can you grab the file: /etc/audit/auditd.conf and add the content to this BZ?
Also what is the space left on the partition where logs are written?

I wonder if we should do a SIGHUP to the auditd daemon after growvols? (AFICT we don't use a percentage, so we should not need that)

       space_left
              If  the  free space in the filesystem containing log_file drops below this value,
              the audit daemon takes the action specified by space_left_action.  If the value of
              space_left is specified as a whole number, it is interpreted as an absolute size
              in megabytes (MiB).  If the value is specified as a number between 1 and 99 followed
              by a percentage sign (e.g., 5%), the audit daemon calculates the absolute size in
              megabytes  based  on the size of the filesystem containing log_file.  (E.g., if the
              filesystem containing log_file is 2 gigabytes in size, and space_left is set to 25%,
              then the audit daemon sets space_left to approximately 500 megabytes.
              Note that this calculation is performed when the audit daemon starts, so if you resize
              the filesystem containing log_file while the audit daemon is running, you should send
              the audit daemon SIGHUP to re-read the configuration file and recalculate the correct
              percentage.

Sorry, modified the wrong field (the tabs opened in reverse order from my checklist...).  Couldn't see what I would be able to validate on it.  I presume I'm setting this correctly.

Verify error/audit messages no longer show up in dmesg.

From Undercloud, run dmesg for each compute and check output.

==========================================

(undercloud) [stack@undercloud-0 ~]$ for z in 0 1 2 3 4 5
> do
> echo "Host: compute-${z}"
> ssh tripleo-admin@compute-${z}.ctlplane "sudo dmesg | grep -E 'kauditd|overflow|Hostname'"
> done
Host: compute-0
Warning: Permanently added 'compute-0.ctlplane' (ED25519) to the list of known hosts.
Host: compute-1
Warning: Permanently added 'compute-1.ctlplane' (ED25519) to the list of known hosts.
Host: compute-2
Warning: Permanently added 'compute-2.ctlplane' (ED25519) to the list of known hosts.
Host: compute-3
Warning: Permanently added 'compute-3.ctlplane' (ED25519) to the list of known hosts.
Host: compute-4
Warning: Permanently added 'compute-4.ctlplane' (ED25519) to the list of known hosts.
Host: compute-5
Warning: Permanently added 'compute-5.ctlplane' (ED25519) to the list of known hosts.
(undercloud) [stack@undercloud-0 ~]$

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Release of components for Red Hat OpenStack Platform 17.1 (Wallaby)), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2023:4577