Bug 1251177 - RFC: Reduce verbosity in /var/log/messages (or journalctl)
RFC: Reduce verbosity in /var/log/messages (or journalctl)
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: setroubleshoot (Show other bugs)
All Linux
low Severity low
: rc
: ---
Assigned To: Petr Lautrbach
Milos Malik
: 1252069 (view as bug list)
Depends On:
Blocks: 1203710 1295396 1296594 1313485
  Show dependency treegraph
Reported: 2015-08-06 11:53 EDT by Paulo Andrade
Modified: 2016-11-03 22:56 EDT (History)
8 users (show)

See Also:
Fixed In Version: setroubleshoot-3.2.26-1.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-11-03 22:56:55 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Paulo Andrade 2015-08-06 11:53:12 EDT
Is there some way to reduce verbosity in setroubleshoot
log messages?

  User wants to only see:

$DATE $HOST setroubleshoot: SELinux is preventing $SOMETHING. For complete SELinux messages. run sealert -l $HASH

and then run the suggested command manually, without
clobbering the logs with too many, too long, and repeated
Comment 2 Petr Lautrbach 2015-08-07 09:12:28 EDT
I'm afraid that it is not possible directly in setroubleshootd now.

There's an ongoing update for rhel-7.2 which removes debug messages from logs  unless loglevel is set to DEBUG.

However, it won't remove a plugin output from logs. Please file a RFE bug for rhel-7.3 with this feature and we'll try to provide a way how to disable logging of plugins output or make it at least simple filterable if it's feasible.
Comment 3 Paulo Andrade 2015-08-07 10:04:32 EDT

In case you missed it, there is a collaboration note, from
ssekidde at redhat.com, in the Customer Portal, that better
describe the user problem:

Looking at /var/log/messages

Jul 29 17:35:03 HOSTNAME audispd: queue is full - dropping event

$ grep "audispd: queue is full - dropping event" SOSREPORT/var/log/messages | wc -l

Basically these messages appear when audispd is trying to send current events to all the plugins but the plugins aren't working fast enough. 

And which plugins are these? 

ll /etc/audisp/plugins.d/
total 12
-rw-r-----. 1 root root 358 Jan 14  2015 af_unix.conf
-rw-r--r--. 1 root root 170 Mar 23 04:56 sedispatch.conf <-------
-rw-r-----. 1 root root 453 Jan 14  2015 syslog.conf

The SELinux notification workflow assuming auditd, rsyslog and sedispatch are running is

 auditd --> audispd --> sedispatch --> [dbus message] --> setroubleshootd --> [dbus signal] --> (seapplet) --> sealert

Why is it happening? 

This is an overflow condition as the warning message is from audispd

From /etc/audisp/audispd.conf 

      6 q_depth = 150
      7 overflow_action = SYSLOG <------
      8 priority_boost = 4

The fix is to increase the queue and priority above. More so the priority, but the bigger problem is getting the SELinux problems fixed.
Comment 4 Petr Lautrbach 2015-08-07 10:22:00 EDT
I've read it but I might not understand it right or there are two problems.

My understanding is that the customer wants suppress output from plugin analysis like:

    *****  Plugin %s (%.4s confidence) suggests 

while he wants to have messages suggesting use sealert:

    For complete SELinux messages. run sealert -l %s

The plugin analysis is sent using:

    systemd.journal.send(siginfo.format_text(), OBJECT_PID=pid)

therefore it can't be dropped or filtered right now as there's no FACILITY, PRIORITY or a config option for that.
Comment 7 Steve B 2015-08-10 12:15:42 EDT
I have the same problem (and the same request), but I have a workaround for the mean time until a proper fix is done.

I added a rsyslog filter in a file in the folder /etc/rsyslog.d/ with

if $programname == 'python' and $msg startswith 'SELinux is preventing' then {
   action(type="omfile" file="/var/log/selinux-python-output.log")

It removes the detailed plugin suggestions from /var/log/messages but keeps the first ...setroubleshoot: SELinux is preventing... in it.
Comment 9 Petr Lautrbach 2016-05-31 06:48:33 EDT
*** Bug 1252069 has been marked as a duplicate of this bug. ***
Comment 11 Petr Lautrbach 2016-06-02 10:44:47 EDT
$ cat /etc/setroubleshoot/setroubleshoot.conf
# log_full_report: True|False, log full report analysis to journal
log_full_report = True

log_full_report = True => the behavior doesn't change and a whole report analysis is logged to journal.

log_full_report = False => only 'sealert -l ...' is logged and it's up to a user to run sealert herself.
Comment 15 errata-xmlrpc 2016-11-03 22:56:55 EDT
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, and where to find the updated
files, follow the link below.

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


Note You need to log in before you can comment on or make changes to this bug.