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:

• a bugzilla ticket
• knowledge base article
• updated package

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, a GUI that presents a list of crashes and available actions or abrt-cli, command line interface with similar functionality.

For reporting, the user can select various reporting locations. Settings are available either in gnome-abrt under Preferences menu or in the /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, it continues either by creating a microreport [1] and sending that microreport to an abrt server [2] 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. The user is then presented with a link to the report based on the reporting mechanism e.g: kb article or bugzilla ticket url.

[1]	uReport specs

[2]	https://retrace.fedoraproject.org/faf/summary/ (Fedora)

ABRT detects various kinds of problems. It watches various sources 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:

• C/C++ crashes
  • generates backtrace automatically (installs debuginfo pkgs if necessary)
  • identifies the crashing function
• unhandled Python exceptions
• kernel oopses (non critical)
• kernel crashes (critical, system crashes)
• XORG crashes (xorg doesn't crash like other C/C++ programs)
• Java exceptions (using JVMTI, still proof of concept, might have performance impact)

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.

[3]	RHEL6 + F17 /var/spool/abrt F18+ /var/tmp/abrt

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:

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:

ABRT also provides a GUI application which allows users to browse detected problems. The GUI shows to users additional information about a problem such date of detection, number of occurrences, version, URL to a report and short solution text if available.

This figure shows a not reported kernel oops problem detect in system logs.

This figure shows a reported binary crash (C/C++) problem.

This figure shows a crash of VLC which is not reportable to Red Hat Bugzilla.

This figure shows a not reported kernel oops problem obtained from VMCore.

This figure shows an uncaught Java exception problem detected by JVM.

This figure shows an uncaught Python exception problem detected by Python uncaught exception handler.

This figure shows an uncaught Ruby exception problem detected by Ruby uncaught exception handler.

This figure shows a Xorg Server problem detect in Xorg logs.

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 shortcut 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

libreport is a library with the goal 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. */
problem_data_add_basics(pd);

report_problem_in_memory(pd, LIBREPORT_NOWAIT | LIBREPORT_GETPID);