ABRT is a set of tools to help users detect and report problems. It's main purpose is to ease the process of reporting an issue and finding a solution.
The solution in this context means: ABRT consists of a daemon that monitors logs, system crashes and triggers events based on the type of crash. Also provides desktop notification that popup at the time of a crash. The user can work with gnome-abrt, GUI that presents a list of crashes and available actions or abrt-cli, command line interface with similar functionality.

For reporting user can select various reporting locations. Settings are available either in gnome-abrt under Preferences menu or in /etc/libreport/... configuration files.

Reporting an issue consists of gathering system information about a crash, package versions, snapshot of /proc and processing that report. The collected data depends on the type of the problem and can be customized per package/executable/library/version/etc. Based on the configuration tool continues either by creating a microreport1 and sending that microreport to an abrt server2 (in Fedora and internal RHEL testing only) that collects anonymous statistics about crash count, top issues for packages and release or by sending a full report to either a customer portal, local or remote storage or bugzilla. User is then presented with a link to the report based on the reporting mechanism e.g: kb article or bugzilla ticket url

Features Overview

ABRT detects various kinds of problems. It watches various sources4 of potential problems. For many problems it also provides a post-processing to analyze the problem even further and to help find possible cause and fix for the problem. In the current version (2.1.2) it detects: For all these types of crashes, ABRT daemon automatically collects a crash specific information based on the configuration in /etc/libreport/events.d/ creates a report placed in /var/tmp/abrt 3 and finds existing duplicates or reports this report is then processed either by GUI or CLI tool




ABRT is in the default installation, so if the system is not installed using custom ks file
it should be running and watching for problems in the background.
When ABRT detects a problem it informs the user via the notification bubble:
G3 with the ABRT notification

After clicking the "Report" button the the reporting wizard is started. Which will ask for an user description of what happened

Then, if it's the first time, it will ask for credentials to the RH support portal:


When crash is detected on a headless server abrtd sends an email to root@localhost
To list all crashes on a machine run:

$ abrt-cli list

Which should result in a similar output:
Every problem has an ID which is actually a path to the saved problem data. It also has a shotcut in form @ID, so reporting a problem from cmdline is done like this:

$ abrt-cli report /var/tmp/abrt/something

or using the shortcut:

$ abrt-cli report @0


It's a library which goal is to provide an unified API for reporting problem to the various bug trackers. It's purpose is to hide the differences
between various bug tracking APIs and provide an abstraction so it's easy to use and the app developer doesn't have to implement support for various
bug trackers separately. It also enables sharing the configuration between different applications, so user only have to set the credentials once.
It's extensible via plugins and in the current version it supports reporting to: RH portal, bugzilla, email, ftp, scp, local log file.

problem_data_t *pd = problem_data_new();
problem_data_add_text_noteditable(pd, FILENAME_COMMENT, description);
problem_data_add_text_noteditable(pd, FILENAME_REASON, summary);
problem_data_add_text_noteditable(pd, FILENAME_COMPONENT, "abrt");
char *version = xasprintf("abrt-%s", VERSION);
problem_data_add_text_noteditable(pd, FILENAME_PACKAGE, version);

/* Must be here because it computes FILENAME_DUPHASH from the content. */

report_problem_in_memory(pd, LIBREPORT_NOWAIT | LIBREPORT_GETPID);