Chapter 28. Automatic Bug Reporting Tool (ABRT)
The Automatic Bug Reporting Tool, commonly abbreviated as ABRT, consists of the
abrtd daemon and a number of system services and utilities to process, analyze, and report 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. For a brief overview of the most important ABRT components, see Table 28.1, “Basic ABRT components”.
Important
For Red Hat Enterprise Linux 6.2, the Automatic Bug Reporting Tool has been upgraded to version 2.0. The ABRT 2-series brings major improvements to automatic bug detection and reporting.
| Component | Package | Description |
|---|---|---|
abrtd | abrt | The ABRT daemon which runs under the root user as a background service. |
abrt-applet | abrt-gui | The program that receives messages from abrtd and informs you whenever a new problem occurs. |
abrt-gui | abrt-gui | The GUI application that shows collected problem data and allows you to further process it. |
abrt-cli | abrt-cli | The command-line interface that provides similar functionality to the GUI. |
abrt-ccpp | abrt-addon-ccpp | The ABRT service that provides the C/C++ problems analyzer. |
abrt-oops | abrt-addon-kerneloops | The ABRT service that provides the kernel oopses analyzer. |
abrt-vmcore | abrt-addon-vmcore[a] | The ABRT service that provides the kernel panic analyzer and reporter. |
[a]
The abrt-addon-vmcore package is provided by the Optional subscription channel. See Section 8.4.8, “Adding the Optional and Supplementary Repositories” for more information on Red Hat additional channels.
| ||
ABRT currently supports detection of crashes in applications written in the C/C++ and Python languages, as well as kernel oopses. With Red Hat Enterprise Linux 6.3, ABRT can also detect kernel panics if the additional abrt-addon-vmcore package is installed and the
kdump crash dumping mechanism is enabled and configured on the system accordingly.
ABRT is capable of reporting problems to a remote issue tracker. Reporting can be configured to happen automatically whenever an issue is detected, or problem data can be stored locally, reviewed, reported, and deleted manually by a user. The reporting tools can send problem data to a Bugzilla database, a Red Hat Technical Support (RHTSupport) site, upload it using
FTP/SCP, email it, or write it to a file.
The part of ABRT which handles already-existing problem data (as opposed to, for example, creation of new problem data) has been factored out into 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. However, ABRT and libreport operation and configuration is closely integrated. They are therefore discussed as one in this document.
Whenever a problem is detected, ABRT compares it with all existing problem data and determines whether that same problem has been recorded. If it has been, the existing problem data is updated and the most recent (duplicate) problem is not recorded again. If this 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 analysis 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 the crashed kernel.
After the problem directory is created and problem data gathered, you can further process, analyze and report the problem using either the ABRT GUI, or the abrt-cli utility for the command line. For more information about these tools, see Section 28.2, “Using the Graphical User Interface” and Section 28.3, “Using the Command-Line Interface” respectively.
Note
If you do not use ABRT to further analyze and report the detected problems but instead you report problems using a legacy problem reporting tool, report, note that you can no longer file new bugs. The report utility can now only be used to attach new content to the already existing bugs in the RHTSupport or Bugzilla database. Use the following command to do so:
report [-v] --target target --ticket ID file
…where target is either strata for reporting to RHTSupport or bugzilla for reporting to Bugzilla. ID stands for number identifying an existing problem case in the respective database, and file is a file containing information to be added to the problem case.
If you want to report new problems and you do not want to use abrt-cli, you can now use the report-cli utility instead of report. Issue the following command to let report-cli to guide you through the problem reporting process:
report-cli -r dump_directory
…where dump_directory is a problem data directory created by ABRT or some other application using
libreport. For more information on report-cli, see man report-cli.
28.1. Installing ABRT and Starting its Services
As a prerequisite for its use, 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.
As the first step in order to use ABRT, you should ensure that the abrt-desktop package is installed on your system by running the following command as the root user:
~]# yum install abrt-desktop
With abrt-desktop installed, you will be able to use ABRT only in its graphical interface. If you intend to use ABRT on the command line, install the abrt-cli package:
~]# yum install abrt-cli
See Section 8.2.4, “Installing Packages” for more information on how to install packages with the Yum package manager.
Your next step should be to verify that
abrtd is running. The daemon is typically configured to start up at boot time. You can use the following command as root to verify its current status:
~]# service abrtd status
abrtd (pid 1535) is running...
If the
service command returns the abrt is stopped message, the daemon is not running. It can be started for the current session by entering this command:
~]# service abrtd start
Starting abrt daemon: [ OK ]
Similarly, you can follow the same steps to check and start up the
abrt-ccpp service if you want ABRT to catch C/C++ crashes. To set ABRT to detect kernel oopses, use the same steps for the abrt-oops service. Note that this service cannot catch kernel oopses which cause the system to fail, to become unresponsive or to reboot immediately. To be able to detect such kernel oopses with ABRT, you need to install the abrt-vmcore service. If you require this functionality, see Section 28.4.5, “Configuring ABRT to Detect a Kernel Panic” for more information.
When installing ABRT packages, all respective ABRT services are automatically enabled for
runlevels 3 and 5. You can disable or enable any ABRT service for the desired runlevels using the chkconfig utility. See Section 12.2.3, “Using the chkconfig Utility” for more information.
Warning
Please note that installing 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
Finally, if you run ABRT in a graphical desktop environment, you can verify that the
ABRT notification applet is running:
~]$ ps -el | grep abrt-applet
0 S 500 2036 1824 0 80 0 - 61604 poll_s ? 00:00:00 abrt-applet
If the ABRT notification applet is not running, you can start it manually in your current desktop session by running the
abrt-applet program:
~]$ abrt-applet &
[1] 2261
The applet can be configured to start automatically when your graphical desktop session starts. You can ensure that the ABRT notification applet is added to the list of programs and selected to run at system startup by selecting the
Figure 28.1. Setting ABRT notification applet to run automatically.
