REPORT_EVENT.CONF(5)

💖 report_event.conf(5) — the LIBREPORT MANUAL page, but make it make sense 💖

okay bestie, sit down, hydrate, because this one is genuinely important and also lowkey fun. it's the manual page for report_event.conf, the config file that lives in the LIBREPORT MANUAL family. it's giving "quiet little text file that decides which programs run when something happens in a problem directory's lifetime." main character energy fr. 🎀

---

🌸 NAME 🌸

report_event.conf — configuration file for libreport.

---

✨ DESCRIPTION ✨

this configuration file specifies which programs should be run when the specified event occurs in problem directory lifetime. yes, it's a whole little scheduling diva. 💅

it consists of directives and rules.

Directives start with a reserved word. currently, there is only one directive, include.

• include FILE — this directive causes files which match FILE to be read and parsed as if they are inserted textually where this directive occurs. FILE can use shell pattern metacharacters (*,?,etc) to specify multiple files. relative paths are interpreted relative to current file. 🦋

Rule starts with a line with non-space leading character. all subsequent lines which start with space or tab form one rule. note that separating newline is retained. ngl this is the part that trips people up — indent = same rule, no indent = new rule, periodt. 💀

Rules may be commented out with #. one # is sufficient to comment out even a multi-line rule (no need to comment out every line). iconic behaviour honestly, we love a lazy-friendly format. 🙈

Rules specify which programs to run on the problem directory. each rule may have conditions to be checked before the program is run.

Conditions have form VAR=VAL or VAL~=REGEX, where VAR is either word EVENT or a name of problem directory element to be checked (for example, "executable", "package", hostname" etc).

if all conditions match, the remaining part of the rule (the "program" part) is run in the shell. all shell language constructs are valid. all stdout and stderr output is captured and passed to ABRT and possibly to ABRT's frontends and shown to the user. 🫶

if the program terminates with nonzero exit code, the event processing is considered unsuccessful and is stopped. last captured output line, if any, is considered to be the error message indicating the reason of the failure, and may be used by abrt as such.

if the program terminates successfully, next rule is read and processed. this process is repeated until the end of this file. yes, it just keeps going until the file runs out. stamina. 👑

---

🧚 Event XML configuration 🧚

these configuration files provides event meta data.

each file has XML formatting with the following DTD:

<!ELEMENT event            (name+,description+,requires-items?,exclude-items-by-default?,exclude-items-always?,exclude-binary-items?,include-items-by-default?,minimal-rating?,gui-review-elements?,options?)>
<!ELEMENT name             (#PCDATA)>
<!ATTLIST name             xml:lang CDATA #IMPLIED>
<!ELEMENT description      (#PCDATA)>
<!ATTLIST description      xml:lang CDATA #IMPLIED>
<!ELEMENT requires-items           (#PCDATA)>
<!ELEMENT exclude-items-by-default (#PCDATA)>
<!ELEMENT include-items-by-default (#PCDATA)>
<!ELEMENT exclude-items-always     (#PCDATA)>
<!ELEMENT exclude-binary-items     ("yes"|"no")>
<!ELEMENT minimal-rating           ("0"|"1"|"2"|"3"|"4")>
<!ELEMENT gui-review-elements      ("yes"|"no")>
<!ELEMENT support-restricted-access ("yes"|"no")>
<!ATTLIST support-restricted-access optionname CDATA #IMPLIED>
<!ELEMENT options          (option*,advanced-options)>
<!ELEMENT advanced-options (option)*>
<!ELEMENT option           (label+,description+,note-html+,allow-empty?,default-value?)>
<!ATTLIST option           type (text|bool|password|number|hint-html) #REQUIRED
                           name CDATA #REQUIRED>
<!ELEMENT label            (#PCDATA)>
<!ATTLIST label            xml:lang CDATA #IMPLIED>
<!ELEMENT note-html        (#PCDATA)>
<!ATTLIST note-html        xml:lang CDATA #IMPLIED>
<!ELEMENT allow-empty      ("yes"|"no")>
<!ELEMENT default-value    (#PCDATA)>
<!ELEMENT requires-details ("yes"|"no")>

and now the glossary, element by element, no skipping, i would never 😤

• name — user visible name of event
• description — user visible description
• exclude-items-by-default — comma separated names of excluded problem elements. user can include any of these elements if he wishes it.
• include-items-by-default — comma separated names of included problem elements. user can exclude any of these elements if he wishes it.
• exclude-items-always — comma separated names of included problem elements. user cannot include any of these elements.
• exclude-binary-items — if "yes" then all binary problem elements are excluded. user can include them if he wishes it.
• minimal-rating — minimal backtrace rating required for executing the event. backtrace rating is a measure of backtrace usability and understandability. with an increasing number of unresolved frames the backtrace rating gets lower values.
• gui-review-elements — if "yes", user must explicitly approve that all included problem elements can be published. if "no", the event is executed automatically. if not provided, "yes" is expected.
• support-restricted-access — if "yes", the UI tools will offer the users to enter the new report with restricted access. if "no", the UI tools will never offer the users to enter the report with restricted access. "no" is the default value. the element should have one argument named optionname which defines name of an option holding configuration of the restricted access feature. the option must of bool type.
• advanced-options — list of options which are hidden in the default view.
• label — event option label
• note-html — event option HTML formatted description
• allow-empty — determines if user can leave the option empty
• default-value — a value which is used by default
• option:name — name of exported environment variable name. libreport tools communicate through Environment Variables.
• requires-details — if "yes", the UI tools will offer the users to fill "comment", "reproducer" and "reproducible" during a reporting. if "no", only "comment" will be offered to fill.

---

🌈 EXAMPLES 🌈

look at these little guys go. copy them exactly, they're real. 🔥

EVENT=post-create analyzer=Python   abrt-action-analyze-python

EVENT=post-create
        getent passwd "`cat uid`" | cut -d: -f1 >username

---

👑 SEE ALSO 👑

• abrtd(8)

---

💜 AUTHOR 💜

manual page written by Denys Vlasenko <dvlasenk@redhat.com[1]>.

---

🎀 NOTES 🎀

1. dvlasenk@redhat.com — mailto:dvlasenk@redhat.com

---

okay that's the whole page bestie, you ate that 🫶 and just so you have the receipts: this was LIBREPORT 2.17.15, dated 09/19/2025. go forth and configure your events, you absolute icon. 💅✨🌸