Chapter 25. Automatic Bug Reporting Tool (ABRT)

25.1. Introduction to ABRT

The Automatic Bug Reporting Tool, commonly abbreviated as ABRT, is a set of tools that is designed to help users detect and report application crashes. Its main purpose is to ease the process of reporting issues and finding solutions. In this context, the solution can be a Bugzilla ticket, a knowledge-base article, or a suggestion to update a package to a version containing a fix.

ABRT consists of the abrtd daemon and a number of system services and utilities for processing, analyzing, and reporting detected problems. The daemon runs silently in the background most of the time and springs into action when an application crashes or a kernel oops is detected. The daemon then collects the relevant problem data, such as a core file if there is one, the crashing application’s command line parameters, and other data of forensic utility.

ABRT currently supports the detection of crashes in applications written in the C, C++, Java, Python, and Ruby programming languages, as well as X.Org crashes, kernel oopses, and kernel panics. See Section 25.4, “Detecting Software Problems” for more detailed information on the types of failures and crashes supported, and the way the various types of crashes are detected.

The identified problems can be reported to a remote issue tracker, and the reporting can be configured to happen automatically whenever an issue is detected. Problem data can also be stored locally or on a dedicated system and reviewed, reported, and deleted manually by the user. The reporting tools can send problem data to a Bugzilla database or the Red Hat Technical Support (RHTSupport) website. The tools can also upload it using FTP or SCP, send it as an email, or write it to a file.

The ABRT component that handles existing problem data (as opposed to, for example, the creation of new problem data) is a part of a separate project, libreport. The libreport library provides a generic mechanism for analyzing and reporting problems, and it is used by applications other than ABRT as well. However, ABRT and libreport operation and configuration are closely integrated. They are, therefore, discussed as one in this document.


Note that ABRT report is generated only when core dump is generated. Core dump is generated only for some signals. For example, SIGKILL (-9) does not generate core dump, so ABRT cannot catch this fail. For more information about signals and core dump generating, see man 7 signal.

25.2. Installing ABRT and Starting its Services

In order to use ABRT, ensure that the abrt-desktop or the abrt-cli package is installed on your system. The abrt-desktop package provides a graphical user interface for ABRT, and the abrt-cli package contains a tool for using ABRT on the command line. You can also install both. The general workflow with both the ABRT GUI and the command line tool is procedurally similar and follows the same pattern.


Please note that installing the ABRT packages overwrites the /proc/sys/kernel/core_pattern file, which can contain a template used to name core-dump files. The content of this file will be overwritten to:

|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e

See Section 9.2.4, “Installing Packages” for general information on how to install packages using the Yum package manager.

25.2.1. Installing the ABRT GUI

The ABRT graphical user interface provides an easy-to-use front end for working in a desktop environment. You can install the required package by running the following command as the root user:

~]# yum install abrt-desktop

Upon installation, the ABRT notification applet is configured to start automatically when your graphical desktop session starts. You can verify that the ABRT applet is running by issuing the following command in a terminal:

~]$ ps -el | grep abrt-applet
0 S  500 2036 1824 0 80  0 - 61604 poll_s ?    00:00:00 abrt-applet

If the applet is not running, you can start it manually in your current desktop session by running the abrt-applet program:

~]$ abrt-applet &
[1] 2261

25.2.2. Installing ABRT for the Command Line

The command line interface is useful on headless machines, remote systems connected over a network, or in scripts. You can install the required package by running the following command as the root user:

~]# yum install abrt-cli

25.2.3. Installing Supplementary ABRT Tools

To receive email notifications about crashes detected by ABRT, you need to have the libreport-plugin-mailx package installed. You can install it by executing the following command as root:

~]# yum install libreport-plugin-mailx

By default, it sends notifications to the root user at the local machine. The email destination can be configured in the /etc/libreport/plugins/mailx.conf file.

To have notifications displayed in your console at login time, install the abrt-console-notification package as well.

ABRT can detect, analyze, and report various types of software failures. By default, ABRT is installed with support for the most common types of failures, such as crashes of C and C++ applications. Support for other types of failures is provided by independent packages. For example, to install support for detecting exceptions in applications written using the Java language, run the following command as root:

~]# yum install abrt-java-connector

See Section 25.4, “Detecting Software Problems” for a list of languages and software projects which ABRT supports. The section also includes a list of all corresponding packages that enable the detection of the various types of failures.

25.2.4. Starting the ABRT Services

The abrtd daemon requires the abrt user to exist for file system operations in the /var/spool/abrt directory. When the abrt package is installed, it automatically creates the abrt user whose UID and GID is 173, if such user does not already exist. Otherwise, the abrt user can be created manually. In that case, any UID and GID can be chosen, because abrtd does not require a specific UID and GID.

The abrtd daemon is configured to start at boot time. You can use the following command to verify its current status:

~]$ systemctl is-active abrtd.service

If systemctl returns inactive or unknown, the daemon is not running. You can start it for the current session by entering the following command as root:

~]# systemctl start abrtd.service

You can use the same commands to start or check status of related error-detection services. For example, make sure the abrt-ccpp service is running if you want ABRT to detect C or C++ crashes. See Section 25.4, “Detecting Software Problems” for a list of all available ABRT detection services and their respective packages.

With the exception of the abrt-vmcore and abrt-pstoreoops services, which are only started when a kernel panic or kernel oops occurs, all ABRT services are automatically enabled and started at boot time when their respective packages are installed. You can disable or enable any ABRT service by using the systemctl utility as described in Chapter 10, Managing Services with systemd.

25.2.5. Testing ABRT Crash Detection

To test that ABRT works properly, use the kill command to send the SEGV signal to terminate a process. For example, start a sleep process and terminate it with the kill command in the following way:

~]$ sleep 100 &
[1] 2823
~]$ kill -s SIGSEGV 2823

ABRT detects a crash shortly after executing the kill command, and, provided a graphical session is running, the user is notified of the detected problem by the GUI notification applet. On the command line, you can check that the crash was detected by running the abrt-cli list command or by examining the crash dump created in the /var/spool/abrt/ directory. See Section 25.5, “Handling Detected Problems” for more information on how to work with detected crashes.

25.3. 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 — the problem is reported to Bugzilla.

Whenever a problem is detected, ABRT compares it with all existing problem data and determines whether that same problem has already been recorded. If it has, the existing problem data is updated, and the most recent (duplicate) problem is not recorded again. If the problem is not recognized by ABRT, a problem-data directory is created. A problem-data directory typically consists of files such as: analyzer, architecture, coredump, cmdline, executable, kernel, os_release, reason, time, and uid.

Other files, such as backtrace, can be created during the analysis of the problem, depending on which analyzer method is used and its configuration settings. Each of these files holds specific information about the system and the problem itself. For example, the kernel file records the version of a crashed kernel.

After the problem-data directory is created and problem data gathered, you can process the problem using either the ABRT GUI, or the abrt-cli utility for the command line. See Section 25.5, “Handling Detected Problems” for more information about the ABRT tools provided for working with recorded problems.

25.3.1. Configuring Events

ABRT events use plugins to carry out the actual reporting operations. Plugins are compact utilities that the events call to process the content of problem-data directories. Using plugins, ABRT is capable of reporting problems to various destinations, and almost every reporting destination requires some configuration. For instance, Bugzilla requires a user name, password, and a URL pointing to an instance of the Bugzilla service.

Some configuration details can have default values (such as a Bugzilla URL), but others cannot have sensible defaults (for example, a user name). ABRT looks for these settings in configuration files, such as report_Bugzilla.conf, in the /etc/libreport/events/ or $HOME/.cache/abrt/events/ directories for system-wide or user-specific settings respectively. The configuration files contain pairs of directives and values.

These files are the bare minimum necessary for running events and processing the problem-data directories. The gnome-abrt and abrt-cli tools read the configuration data from these files and pass it to the events they run.

Additional information about events (such as their description, names, types of parameters that can be passed to them as environment variables, and other properties) is stored in event_name.xml files in the /usr/share/libreport/events/ directory. These files are used by both gnome-abrt and abrt-cli to make the user interface more friendly. Do not edit these files unless you want to modify the standard installation. If you intend to do that, copy the file to be modified to the /etc/libreport/events/ directory and modify the new file. These files can contain the following information:

  • a user-friendly event name and description (Bugzilla, Report to Bugzilla bug tracker),
  • a list of items in a problem-data directory that are required for the event to succeed,
  • a default and mandatory selection of items to send or not send,
  • whether the GUI should prompt for data review,
  • what configuration options exist, their types (string, Boolean, and so on), default value, prompt string, and so on; this lets the GUI build appropriate configuration dialogs.

For example, the report_Logger event accepts an output filename as a parameter. Using the respective event_name.xml file, the ABRT GUI determines which parameters can be specified for a selected event and allows the user to set the values for these parameters. The values are saved by the ABRT GUI and reused on subsequent invocations of these events. Note that the ABRT GUI saves configuration options using the GNOME Keyring tool and by passing them to events, it overrides data from text configuration files.

To open the graphical Configuration window, choose Automatic Bug Reporting ToolPreferences from within a running instance of the gnome-abrt application. This window shows a list of events that can be selected during the reporting process when using the GUI. When you select one of the configurable events, you can click the Configure button and modify the settings for that event.

Figure 25.1. Configuring ABRT Events

A screenshot of a configuration window in the ABRT GUI application.

All files in the /etc/libreport/ directory hierarchy are world-readable and are meant to be used as global settings. Thus, it is not advisable to store user names, passwords, or any other sensitive data in them. The per-user settings (set in the GUI application and readable by the owner of $HOME only) are safely stored in GNOME Keyring, or they can be stored in a text configuration file in $HOME/.abrt/ for use with abrt-cli.

The following table shows a selection of the default analyzing, collecting, and reporting events provided by the standard installation of ABRT. The table lists each event’s name, identifier, configuration file from the /etc/libreport/events.d/ directory, and a brief description. Note that while the configuration files use the event identifiers, the ABRT GUI refers to the individual events using their names. Note also that not all of the events can be set up using the GUI. For information on how to define a custom event, see Section 25.3.2, “Creating Custom Events”.

Table 25.1. Standard ABRT Events

NameIdentifier and Configuration FileDescription



Uploads a μReport to the FAF server.




Sends the problem report via the Mailx utility to a specified email address.




Reports the problem to the specified installation of the Bugzilla bug tracker.

Red Hat Customer Support



Reports the problem to the Red Hat Technical Support system.

Analyze C or C++ Crash



Sends the core dump to a remote retrace server for analysis or performs a local analysis if the remote one fails.

Report uploader



Uploads a tarball (.tar.gz) archive with problem data to the chosen destination using the FTP or the SCP protocol.

Analyze VM core



Runs the GDB (the GNU debugger) on the problem data of a kernel oops and generates a backtrace of the kernel.

Local GNU Debugger



Runs GDB (the GNU debugger) on the problem data of an application and generates a backtrace of the program.

Collect .xsession-errors



Saves relevant lines from the ~/.xsession-errors file to the problem report.




Creates a problem report and saves it to a specified local file.



Sends a kernel problem to the oops tracker at

25.3.2. Creating Custom 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 loaded by the main configuration file, /etc/libreport/report_event.conf. There is no need to edit the default configuration files because abrt will run the scripts contained in /etc/libreport/events.d/. This file accepts shell metacharacters (for example, *, $, ?) and interprets relative paths relatively to its location.

Each rule starts with a line with a non-space leading character, and 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 is either the EVENT key word or a name of a problem-data directory element (such as executable, package, hostname, and so on),
  • 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 more complex event, which is actually one of the predefined events. It saves relevant lines from the ~/.xsession-errors file to the problem report of any problem for which the abrt-ccpp service has been used, provided the crashed application had any X11 libraries loaded at the time of the 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 definitive. System administrators can add events according to their need in the /etc/libreport/events.d/ directory.

Currently, the following event names are provided with the standard ABRT and libreport installations:

This event is run by abrtd to process newly created problem-data directories. When the post-create event is run, abrtd checks whether the new problem data matches any of the already existing problem directories. If such a problem directory exists, it is updated and the new problem data is discarded. Note that if the script in any definition of the post-create event exits with a non-zero value, abrtd will terminate the process and will drop the problem data.
notify, notify-dup
The notify event is run following the completion of post-create. When the event is run, the user can be sure that the problem deserves their attention. The notify-dup is similar, except it is used for duplicate occurrences of the same problem.
where name_suffix is the replaceable part of the event name. This event is used to process collected data. For example, the analyze_LocalGDB event uses the GNU Debugger (GDB) utility to process the core dump of an application and produce a backtrace of the crash.

…where name_suffix is the adjustable part of the event name. This event is used to collect additional information on problems.


…where name_suffix is the adjustable part of the event name. This event is used to report a problem.

25.3.3. Setting Up Automatic Reporting

ABRT can be configured to send initial anonymous reports, or μReports, of any detected issues or crashes automatically without any user interaction. When automatic reporting is turned on, the so called μReport, which is normally sent at the beginning of the crash-reporting process, is sent immediately after a crash is detected. This prevents duplicate support cases based on identical crashes. To enable the autoreporting feature, issue the following command as root:

~]# abrt-auto-reporting enabled

The above command sets the AutoreportingEnabled directive in the /etc/abrt/abrt.conf configuration file to yes. This system-wide setting applies to all users of the system. Note that by enabling this option, automatic reporting will also be enabled in the graphical desktop environment. To only enable autoreporting in the ABRT GUI, switch the Automatically send uReport option to YES in the Problem Reporting Configuration window. To open this window, choose Automatic Bug Reporting ToolABRT Configuration from within a running instance of the gnome-abrt application. To launch the application, go to ApplicationsSundryAutomatic Bug Reporting Tool.

Figure 25.2. Configuring ABRT Problem Reporting

A screenshot of a configuration window in the ABRT GUI application.

Upon detection of a crash, by default, ABRT submits a μReport with basic information about the problem to Red Hat’s ABRT server. The server determines whether the problem is known and either provides a short description of the problem along with a URL of the reported case if known, or invites the user to report it if not known.


A μReport (microreport) is a JSON object representing a problem, such as a binary crash or a kernel oops. These reports are designed to be brief, machine readable, and completely anonymous, which is why they can be used for automated reporting. The μReports make it possible to keep track of bug occurrences, but they usually do not provide enough information for engineers to fix the bug. A full bug report is needed for a support case to be opened.

To change the default behavior of the autoreporting facility from sending a μReport, modify the value of the AutoreportingEvent directive in the /etc/abrt/abrt.conf configuration file to point to a different ABRT event. See Table 25.1, “Standard ABRT Events” for an overview of the standard events.

25.4. Detecting Software Problems

ABRT is capable of detecting, analyzing, and processing crashes in applications written in a variety of different programming languages. Many of the packages that contain the support for detecting the various types of crashes are installed automatically when either one of the main ABRT packages (abrt-desktop, abrt-cli) is installed. See Section 25.2, “Installing ABRT and Starting its Services” for instructions on how to install ABRT. See the table below for a list of the supported types of crashes and the respective packages.

Table 25.2. Supported Programming Languages and Software Projects


C or C++










Linux (kernel oops)


Linux (kernel panic)


Linux (persistent storage)


25.4.1. Detecting C and C++ Crashes

The abrt-ccpp service installs its own core-dump handler, which, when started, overrides the default value of the kernel’s core_pattern variable, so that C and C++ crashes are handled by abrtd. If you stop the abrt-ccpp service, the previously specified value of core_pattern is reinstated.

By default, the /proc/sys/kernel/core_pattern file contains the string core, which means that the kernel produces files with the core. prefix in the current directory of the crashed process. The abrt-ccpp service overwrites the core_pattern file to contain the following command:

|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e

This command instructs the kernel to pipe the core dump to the abrt-hook-ccpp program, which stores it in ABRT's dump location and notifies the abrtd daemon of the new crash. It also stores the following files from the /proc/PID/ directory (where PID is the ID of the crashed process) for debugging purposes: maps, limits, cgroup, status. See proc(5) for a description of the format and the meaning of these files.

25.4.2. Detecting Python Exceptions

The abrt-addon-python package installs a custom exception handler for Python applications. The Python interpreter then automatically imports the abrt.pth file installed in /usr/lib64/python2.7/site-packages/, which in turn imports This overrides Python’s default sys.excepthook with a custom handler, which forwards unhandled exceptions to abrtd via its Socket API.

To disable the automatic import of site-specific modules, and thus prevent the ABRT custom exception handler from being used when running a Python application, pass the -S option to the Python interpreter:

~]$ python -S

In the above command, replace with the name of the Python script you want to execute without the use of site-specific modules.

25.4.3. Detecting Ruby Exceptions

The rubygem-abrt package registers a custom handler using the at_exit feature, which is executed when a program ends. This allows for checking for possible unhandled exceptions. Every time an unhandled exception is captured, the ABRT handler prepares a bug report, which can be submitted to Red Hat Bugzilla using standard ABRT tools.

25.4.4. Detecting Java Exceptions

The ABRT Java Connector is a JVM agent that reports uncaught Java exceptions to abrtd. The agent registers several JVMTI event callbacks and has to be loaded into the JVM using the -agentlib command line parameter. Note that the processing of the registered callbacks negatively impacts the performance of the application. Use the following command to have ABRT catch exceptions from a Java class:

~]$ java -agentlib:abrt-java-connector=abrt=on $MyClass -platform.jvmtiSupported true

In the above command, replace $MyClass with the name of the Java class you want to test. By passing the abrt=on option to the connector, you ensure that the exceptions are handled by abrtd. In case you want to have the connector output the exceptions to standard output, omit this option.

25.4.5. Detecting X.Org Crashes

The abrt-xorg service collects and processes information about crashes of the X.Org server from the /var/log/Xorg.0.log file. Note that no report is generated if a blacklisted module is loaded. Instead, a not-reportable file is created in the problem-data directory with an appropriate explanation. You can find the list of offending modules in the /etc/abrt/plugins/xorg.conf file. Only proprietary graphics-driver modules are blacklisted by default.

25.4.6. Detecting Kernel Oopses and Panics

By checking the output of kernel logs, ABRT is able to catch and process the so-called kernel oopses — non-fatal deviations from the correct behavior of the Linux kernel. This functionality is provided by the abrt-oops service.

ABRT can also detect and process kernel panics — fatal, non-recoverable errors that require a reboot, using the abrt-vmcore service. The service only starts when a vmcore file (a kernel-core dump) appears in the /var/crash/ directory. When a core-dump file is found, abrt-vmcore creates a new problem-data directory in the /var/tmp/abrt/ directory and moves the core-dump file to the newly created problem-data directory. After the /var/crash/ directory is searched, the service is stopped.

For ABRT to be able to detect a kernel panic, the kdump service must be enabled on the system. The amount of memory that is reserved for the kdump kernel has to be set correctly. You can set it using the system-config-kdump graphical tool or by specifying the crashkernel parameter in the list of kernel options in the GRUB 2 menu. For details on how to enable and configure kdump, see the Red Hat Enterprise Linux 7 Kernel Crash Dump Guide. For information on making changes to the GRUB 2 menu see Chapter 26, Working with GRUB 2.

Using the abrt-pstoreoops service, ABRT is capable of collecting and processing information about kernel panics, which, on systems that support pstore, is stored in the automatically-mounted /sys/fs/pstore/ directory. The platform-dependent pstore interface (persistent storage) provides a mechanism for storing data across system reboots, thus allowing for preserving kernel panic information. The service starts automatically when kernel crash-dump files appear in the /sys/fs/pstore/ directory.

25.5. Handling Detected Problems

Problem data saved by abrtd can be viewed, reported, and deleted using either the command line tool, abrt-cli, or the graphical tool, gnome-abrt.


Note that ABRT identifies duplicate problems by comparing new problems with all locally saved problems. For a repeating crash, ABRT requires you to act upon it only once. However, if you delete the crash dump of that problem, the next time this specific problem occurs, ABRT will treat it as a new crash: ABRT will alert you about it, prompt you to fill in a description, and report it. To avoid having ABRT notifying you about a recurring problem, do not delete its problem data.

25.5.1. Using the Command Line Tool

In the command line environment, the user is notified of new crashes on login, provided they have the abrt-console-notification package installed. The console notification looks like the following:

ABRT has detected 1 problem(s). For more info run: abrt-cli list --since 1398783164

To view detected problems, enter the abrt-cli list command:

~]$ abrt-cli list
id 6734c6f1a1ed169500a7bfc8bd62aabaf039f9aa
Directory:   /var/tmp/abrt/ccpp-2014-04-21-09:47:51-3430
count:     1
executable:   /usr/bin/sleep
package:    coreutils-8.22-11.el7
time:      Mon 21 Apr 2014 09:47:51 AM EDT
uid:      1000
Run 'abrt-cli report /var/tmp/abrt/ccpp-2014-04-21-09:47:51-3430' for creating a case in Red Hat Customer Portal

Each crash listed in the output of the abrt-cli list command has a unique identifier and a directory that can be used for further manipulation using abrt-cli.

To view information about just one particular problem, use the abrt-cli info command:

    abrt-cli info -d directory_or_id

To increase the amount of information displayed when using both the list and info sub-commands, pass them the -d (--detailed) option, which shows all stored information about the problems listed, including respective backtrace files if they have already been generated.

To analyze and report a certain problem, use the abrt-cli report command:

    abrt-cli report directory_or_id

Upon invocation of the above command, you will be asked to provide your credentials for opening a support case with Red Hat Customer Support. Next, abrt-cli opens a text editor with the content of the report. You can see what is being reported, and you can fill in instructions on how to reproduce the crash and other comments. You should also check the backtrace because the backtrace might be sent to a public server and viewed by anyone, depending on the problem-reporter event settings.


You can choose which text editor is used to check the reports. abrt-cli uses the editor defined in the ABRT_EDITOR environment variable. If the variable is not defined, it checks the VISUAL and EDITOR variables. If none of these variables is set, the vi editor is used. You can set the preferred editor in your .bashrc configuration file. For example, if you prefer GNU Emacs, add the following line to the file:

export VISUAL=emacs

When you are done with the report, save your changes and close the editor. If you have reported your problem to the Red Hat Customer Support database, a problem case is filed in the database. From now on, you will be informed about the problem-resolution progress via email you provided during the process of reporting. You can also monitor the problem case using the URL that is provided to you when the problem case is created or via emails received from Red Hat Support.

If you are certain that you do not want to report a particular problem, you can delete it. To delete a problem, so that ABRT does not keep information about it, use the command:

    abrt-cli rm directory_or_id

To display help about a particular abrt-cli command, use the --help option:

    abrt-cli command --help

25.5.2. Using the GUI

The ABRT daemon broadcasts a D-Bus message whenever a problem report is created. If the ABRT applet is running in a graphical desktop environment, it catches this message and displays a notification dialog on the desktop. You can open the ABRT GUI using this dialog by clicking on the Report button. You can also open the ABRT GUI by selecting the ApplicationsSundryAutomatic Bug Reporting Tool menu item.

Alternatively, you can run the ABRT GUI from the command line as follows:

~]$ gnome-abrt &

The ABRT GUI window displays a list of detected problems. Each problem entry consists of the name of the failing application, the reason why the application crashed, and the date of the last occurrence of the problem.

Figure 25.3. ABRT GUI

A screenshot of the ABRT GUI application.

To access a detailed problem description, double-click on a problem-report line or click on the Report button while the respective problem line is selected. You can then follow the instructions to proceed with the process of describing the problem, determining how it should be analyzed, and where it should be reported. To discard a problem, click on the Delete button.

25.6. Additional Resources

For more information about ABRT and related topics, see the resources listed below.

Installed Documentation

  • abrtd(8) — The manual page for the abrtd daemon provides information about options that can be used with the daemon.
  • abrt_event.conf(5) — The manual page for the abrt_event.conf configuration file describes the format of its directives and rules and provides reference information about event meta-data configuration in XML files.

Online Documentation

  • Red Hat Enterprise Linux 7 Networking Guide — The Networking Guide for Red Hat Enterprise Linux 7 documents relevant information regarding the configuration and administration of network interfaces and network services on this system.
  • Red Hat Enterprise Linux 7 Kernel Crash Dump Guide — The Kernel Crash Dump Guide for Red Hat Enterprise Linux 7 documents how to configure, test, and use the kdump crash recovery service and provides a brief overview of how to analyze the resulting core dump using the crash debugging utility.

See Also

  • Chapter 23, Viewing and Managing Log Files describes the configuration of the rsyslog daemon and the systemd journal and explains how to locate, view, and monitor system logs.
  • Chapter 9, Yum describes how to use the Yum package manager to search, install, update, and uninstall packages on the command line.
  • Chapter 10, Managing Services with systemd provides an introduction to systemd and documents how to use the systemctl command to manage system services, configure systemd targets, and execute power management commands.