Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
28.4. Configuring ABRT
A problem life cycle is driven by events in ABRT. For example:
- Event 1 — a problem data directory is created.
- Event 2 — problem data is analyzed.
- Event 3 — a problem is reported to Bugzilla.
When a problem is detected and its defining data is stored, the problem is processed by running events on the problem's data directory. For more information on events and how to define one, see Section 28.4.1, “ABRT Events”. Standard ABRT installation currently supports several default events that can be selected and used during problem reporting process. See Section 28.4.2, “Standard ABRT Installation Supported Events” to see the list of these events.
Upon installation, ABRT and libreport place their respective configuration files into the several directories on a system:
/etc/libreport/— contains thereport_event.confmain configuration file. More information about this configuration file can be found in Section 28.4.1, “ABRT Events”./etc/libreport/events/— holds files specifying the default setting of predefined events./etc/libreport/events.d/— keeps configuration files defining events./etc/libreport/plugins/— contains configuration files of programs that take part in events./etc/abrt/— holds ABRT specific configuration files used to modify the behavior of ABRT's services and programs. More information about certain specific configuration files can be found in Section 28.4.4, “ABRT Specific Configuration”./etc/abrt/plugins/— keeps configuration files used to override the default setting of ABRT's services and programs. For more information on some specific configuration files see Section 28.4.4, “ABRT Specific Configuration”.
28.4.1. ABRT Events
Each event is defined by one rule structure in a respective configuration file. The configuration files are typically stored in the
/etc/libreport/events.d/ directory. These configuration files are used by the main configuration file, /etc/libreport/report_event.conf.
The
/etc/libreport/report_event.conf file consists of include directives and rules. Rules are typically stored in other configuration files in the /etc/libreport/events.d/ directory. In the standard installation, the /etc/libreport/report_event.conf file contains only one include directive:
include events.d/*.conf
If you would like to modify this file, please note that it respects shell metacharacters (*,$,?, etc.) and interprets relative paths relatively to its location.
Each rule starts with a line with a non-space leading character, all subsequent lines starting with the
space character or the tab character are considered a part of this rule. Each rule consists of two parts, a condition part and a program part. The condition part contains conditions in one of the following forms:
- VAR=VAL,
- VAR!=VAL, or
- VAL~=REGEX
…where:
- VAR is either the
EVENTkey word or a name of a problem data directory element (such asexecutable,package,hostname, etc.), - VAL is either a name of an event or a problem data element, and
- REGEX is a regular expression.
The program part consists of program names and shell interpretable code. If all conditions in the condition part are valid, the program part is run in the shell. The following is an event example:
EVENT=post-create date > /tmp/dt
echo $HOSTNAME `uname -r`
This event would overwrite the contents of the
/tmp/dt file with the current date and time, and print the host name of the machine and its kernel version on the standard output.
Here is an example of a yet more complex event which is actually one of the predefined events. It saves relevant lines from the
~/.xsession-errors file to the problem report for any problem for which the abrt-ccpp services has been used to process that problem, and the crashed application has loaded any X11 libraries at the time of crash:
EVENT=analyze_xsession_errors analyzer=CCpp dso_list~=.*/libX11.*
test -f ~/.xsession-errors || { echo "No ~/.xsession-errors"; exit 1; }
test -r ~/.xsession-errors || { echo "Can't read ~/.xsession-errors"; exit 1; }
executable=`cat executable` &&
base_executable=${executable##*/} &&
grep -F -e "$base_executable" ~/.xsession-errors | tail -999 >xsession_errors &&
echo "Element 'xsession_errors' saved"
The set of possible events is not hard-set. System administrators can add events according to their need. Currently, the following event names are provided with standard ABRT and libreport installation:
-
post-create - This event is run by
abrtdon newly created problem data directories. When thepost-createevent is run,abrtdchecks whether the UUID identifier of the new problem data matches the UUID of any already existing problem directories. If such a problem directory exists, the new problem data is deleted. -
analyze_name_suffix - …where name_suffix is the adjustable part of the event name. This event is used to process collected data. For example, the
analyze_LocalGDBruns the GNU Debugger (GDB) utility on a core dump of an application and produces a backtrace of a program. You can view the list of analyze events and choose from it using abrt-gui. -
collect_name_suffix - …where name_suffix is the adjustable part of the event name. This event is used to collect additional information on a problem. You can view the list of collect events and choose from it using abrt-gui.
-
report_name_suffix - …where name_suffix is the adjustable part of the event name. This event is used to report a problem. You can view the list of report events and choose from it using abrt-gui.
Additional information about events (such as their description, names and types of parameters which can be passed to them as environment variables, and other properties) is stored in the
/etc/libreport/events/event_name.xml files. These files are used by abrt-gui and abrt-cli to make the user interface more friendly. Do not edit these files unless you want to modify the standard installation.
