Bug 1906065
Summary: | 'audisp-remote' process consumes 100% of one CPU, if remote location is not available | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Rainer Beyel <rbeyel> |
Component: | audit | Assignee: | Sergio Correia <scorreia> |
Status: | CLOSED ERRATA | QA Contact: | Martin Zelený <mzeleny> |
Severity: | medium | Docs Contact: | Khushbu Borole <kborole> |
Priority: | medium | ||
Version: | 8.3 | CC: | dapospis, lvrabec, m.strelow, mzeleny, rmetrich |
Target Milestone: | rc | Keywords: | AutoVerified, Triaged |
Target Release: | 8.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | audit-3.0.5-1.el8 | Doc Type: | Bug Fix |
Doc Text: |
.`audisp-remote` now correctly detects the availability of the remote locations
Previously, the `audisp-remote` plugin did not detect that remote services became unavailable. As a consequence, the `audisp-remote` process would enter a state with high CPU usage. With this update, `audisp-remote` can properly detect remote services becoming unavailable. As a result, the process no longer enters a high-CPU-usage state.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2022-05-10 15:30:12 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1939406 | ||
Bug Blocks: |
Description
Rainer Beyel
2020-12-09 15:52:29 UTC
This is also a severe issue in virtual Environments. On hosts with many VMs sending their audit messages to the same destination, this saturates CPU on the virhost, when destination becomes unavailable. Although it doesn't seem to be documented, it looks like audisp-remote in "format=ascii" mode is nothing more then a program that relays stdin to a remote tcp port. On a test system I was able to use a socat wrapper as a custom audisp plugin and it looks like it's a perfect drop-in relacement (without the bug and the added feature that we could even use TLS as transport encryption). Could you please confirm that my findings are correct as I think this could be a feasible solution for us. We already evaluated other solutions like shipping the contents of /var/log/audit/audit.log. As we need a quick and lightweight solution (because of regulatory reasons) using the auditd multiplexer was (besides this bug) the perfect way. In the long run we are planing to switch to auditbeat anyway. Upstream commit 3e45aa9 should fix this. 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 (audit bug fix and enhancement update), 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/RHBA-2022:2096 |