Product SiteDocumentation Site

21.3. Running ABRT

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

21.3.1. Using the Graphical User Interface

The ABRT daemon sends a broadcast D-Bus message whenever a problem report is created. If the ABRT notification applet is running, it catches this message and displays an orange alarm icon in the Notification Area. You can open the ABRT GUI application using this icon. As an alternative, you can display the ABRT GUI by selecting the ApplicationSystem ToolsAutomatic Bug Reporting Tool menu item.
Running the ABRT GUI from the Applications menu.
Running the ABRT GUI from the Applications menu.
Figure 21.3. Running the ABRT GUI from the Applications menu.

Alternatively, you can run the ABRT GUI from the command line as follows:
~]$ abrt-gui &
The ABRT GUI provides an easy and intuitive way of viewing, reporting and deleting of reported problems. The ABRT 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.
An example of running ABRT GUI.
ABRT displaying its list of crashed applications
Figure 21.4. An example of running ABRT GUI.

If you double-click on a problem report line, you can access the detailed problem description and proceed with the process of determining how the problem should be analyzed, and where it should be reported.
A detailed problem data example.
Viewing detailed problem data
Figure 21.5. A detailed problem data example.

You are first asked to provide additional information about the problem which occurred. You should provide detailed information on how the problem happened and what steps should be done in order to reproduce it. In the next steps, choose how the problem will be analyzed and generate a backtrace depending on your configuration. You can skip the analysis and backtrace-generation steps but remember that developers need as much information about the problem as possible. You can always modify the backtrace and remove any sensitive information you do not want to provide before you send the problem data out.
Selecting how to analyze the problem.
Selecting how to analyze the problem.
Figure 21.6. Selecting how to analyze the problem.

ABRT analyzing the problem
ABRT analyzing the problem
Figure 21.7. ABRT analyzing the problem

Next, choose how you want to report the issue. If you are using Red Hat Enterprise Linux, Red Hat Customer Support is the preferred choice.
Selecting a problem reporter.
Selecting a problem reporter.
Figure 21.8. Selecting a problem reporter.

If you choose to report to Red Hat Customer Support, and you have not configured this event yet, you will be warned that this event is not configured properly and you will be offered an option to do so.
Warning - missing Red Hat Customer Support configuration.
Warning - missing Red Hat Customer Support configuration.
Figure 21.9. Warning - missing Red Hat Customer Support configuration.

Here, you need to provide your Red Hat login information (Refer to Section 21.4.3, “Event Configuration in ABRT GUI” for more information on how to acquire it and how to set this event.), otherwise you will fail to report the problem.
Red Hat Customer Support configuration window.
Red Hat Customer Support configuration window.
Figure 21.10. Red Hat Customer Support configuration window.

After you have chosen a reporting method and have it set up correctly, review the backtrace and confirm the data to be reported.
Reviewing the problem backtrace.
Reviewing the problem backtrace.
Figure 21.11. Reviewing the problem backtrace.

Confirming the data to report.
Confirming the data to report.
Figure 21.12. Confirming the data to report.

Finally, the problem data is sent to the chosen destination, and you can now decide whether to continue with reporting the problem using another available method or finish your work on this problem. 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 oversee the problem case using the URL that is provided to you by ABRT GUI when the problem case is created, or via emails received from Red Hat Support.
Problem is being reported to the Red Hat Customer Support database.
Problem is being reported to the Red Hat Customer Support database.
Figure 21.13. Problem is being reported to the Red Hat Customer Support database.