Bug 1251177

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.

Petr,

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:

---8<---
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
544

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.
---8<---

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.

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")
   stop
}

It removes the detailed plugin suggestions from /var/log/messages but keeps the first ...setroubleshoot: SELinux is preventing... in it.

*** Bug 1252069 has been marked as a duplicate of this bug. ***

$ cat /etc/setroubleshoot/setroubleshoot.conf
...
[setroubleshootd_log]
# 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.

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.

https://rhn.redhat.com/errata/RHBA-2016-2298.html