If a program developer (or package maintainer) requires some specific information which ABRT is not collecting, he can write a custom ABRT hook which collects the required data for his program (package). Such hook can be run at a different time during the problem processing depending on how "fresh" the information has to be. It can be run:

1. at the time of the crash
2. at the time when user decides to analyse the problem (usually run gdb on it)
3. at the time of reporting

All you have to do is create a .conf and place it to /etc/libreport/events.d/ from this template:

EVENT=<EVENT_TYPE> [CONDITIONS]
   <whatever command you like>

The commands will execute with the current directory set to the problem directory (e.g: /var/spool/abrt/ccpp-2012-05-17-14:55:15-31664)

If you need to collect the data at the time of the crash you need to create a hook that will be run as a post-create event.

WARNING: post-create events are run with root privileges!

EVENT=post-create component=binutils
        date > dateofcrash

• this hook will save the time to the file dateofcrash at the time when the crash is detected by ABRT
• a more realistic example: save the smart data when one of tools from udisks crashes

EVENT=post-create component=udisks
        which skdump >/dev/null 2>&1 || exit 0
        for f in /dev/[sh]d[a-z]; do
            test -e "$f" || continue
            skdump "$f"
            echo
        done >smart_data

If you want to collect the data at the time when the problem is being reported, then you need is to use a collect_ event type. Example:

EVENT=collect_syslog
        executable=`cat executable` &&
        base_executable=${executable##*/} &&
        grep -F -e "$base_executable" /var/log/messages | tail -999 >syslog

With the desktop session autoreporting enabled, ABRT automatically uploads uReport for user problems immediately upon their detection. If the uReport server (FAF) knows the reported problem, the server provides additional information about the problem and ABRT informs the user that the detected problem is known via a notification bubble. The notification bubble offers showing the problem's web page, opening the problem in the ABRT GUI or simply ignoring the problem. If the problem is unknown, ABRT shows a notification bubble and the user can either start reporting process as usual or ignore the problem.

With the autoreporting disabled, ABRT uploads an uReport for the detected problem after click on "Report" button in the notification bubble. If the detected problem is not known on the uReport server, ABRT starts reporting as usual. Otherwise, the same notification bubble as described in the 1st paragraph is displayed.

Event though ABRT notifies problems of other users, it never uploads uReports for these problems automatically. The other user's problems are always processed in the way of processing problems with the autorepoting disabled, which is described in the 2nd paragraph.

In case of unavailable network, ABRT will postpone notification of the detected problems until the network becomes available again. The list of postponed problems will be held only for a single user desktop session. The postponed problems may not be notified at all, if the network won't become available during the desktop session's lifetime.

Uploading uReports requires a writeable problem directory and in order to make the reporting more automatic and less confusing, ABRT might move the problem directory from the system dump location (usually /var/tmp/abrt/ directory) to $HOME/.cache/abrt/spool/ directory without asking the user for a permission to do so. However, ABRT moves the directories only if the user has no rights for writing to the system dump location

The Desktop Autoreporting can be enabled in various ways. The easiest way is to answer Yes in a dialogue asking for enabling automatically submitted crash reports which appears after click on "Report" button in the notification bubble. The second way is to open application:

Automatic Bug Reporting Tool

open the application menu and click on the following option:

ABRT Configuration

and turn on option:

Automatically send uReport

The last but the most inconvenient way is to manually edit file:

$HOME/.config/abrt/settings/abrt-applet.conf

and add there the following line:

AutoreportingEnabled = yes

ABRT can be configured to submit an uReport for each detected problems to the uReport server (FAF) immediately upon their detection. The server provides the following information about the submitted problem:

• URLs to existing bug reports (Bugzilla bugs)
• short description text

System Autoreporting can be enabled by issuing the following command:

abrt-auto-reporting enabled

or via Augeas:

augtool set /files/etc/abrt/abrt.conf/AutoreportingEnabled yes

or by adding the following line:

AutoreportingEnabled yes

into file:

/etc/abrt/abrt.conf

When System Autoreporting is enabled, Desktop Session Autoreporting is enabled too.

Enables shortened GUI reporting where the reporting is interrupted after AutoreportingEvent is done. It means that the reporting is done when user clicks "Report" button on the notification buble. Upon that, ABRT uploads an uReport describing handled problem, shows a notification bubble stating that the problem has been reported and finishes.

Shortened Reporting has no effect on the reporting process started from the GUI, because we wanted to allow advanced users to easily submit full bug report into Bugzilla. We believe that all users who care about detected crashes and open Automatic Bug Reporting Tool application to see them are advanced users.

To turn Shortened Reporting on open:

Automatic Bug Reporting Tool

go to the application menu and click:

ABRT Configuration

and turn on option:

Shortened Reporting

Or manually edit file:

$HOME/.config/abrt/settings/abrt-applet.conf

and add there the following line:

ShortenedReporting = yes

Default value: Yes but only if application is running in GNOME desktop

ABRT keeps the global list of sensitive words in /etc/libreport/forbidden_words.conf so in order to change this list for all users, system administrator has to edit this file. There is also per-user list in $HOME/.config/abrt/settings/forbidden_words.conf (doesn't exist by default, so user has to create it). The format of the file is one word per line. Wildcards are NOT supported.

The forbidden words are sometimes a part of other words and these are usually not deemed as sensitive information. Offering such false positive sensitive words for review by user makes the process of removing sensitive data from reports hard and the real sensitive data may be missed. Therefore, ABRT has another list of words that are never considered as sensitive information. The list contains common words consisting from the sensitive words. The global list of ignored words is kept in file:

/etc/libreport/ignored_words.conf

And the per-user list is in file:

$HOME/.config/abrt/settings/ignored_words.conf

ABRT reports problems to various destinations. Almost every reporting destination require some configuration. For instance, Bugzilla requires login and password and URL to an instance of the Bugzilla service. Some configuration details can have default values (e.g. Bugzilla's URL) but others don't have sensible defaults (e.g. login).

ABRT lets user provide configuration through text configuration files, such as /etc/libreport/events/report_Bugzilla.conf. All text configuration files consist of key/value pairs.

The event text configuration can be stored in one of these files:

• /etc/libreport/events/somename.conf - for system scope configuration
• $XDG_CACHE_HOME/abrt/events/somename.conf - for user scope configuration [XDG]

These files are the bare minimum necessary for running events on the problem directories. ABRT GUI and CLI tools will read configuration data from these files and pass it down to events they run.

However, in order to make GUI interface more user-friendly, additional information can be supplied in XML files in the same directory, such as report_Bugzilla.xml. These files can contain the following information:

• user-friendly event name and description (Bugzilla, Report to Bugzilla bug tracker).
• the list of items in problem directory which are required for event to succeed.
• default and mandatory selection of items to send or not send.
• whether GUI should prompt for data review.
• what configuration options exist, their type (string, boolean, etc), default value, prompt string, etc. This lets GUI to build the appropriate configuration dialogs.

ABRT's GUI saves configuration options in gnome-keyring or ksecrets, and passes them down to events, overriding data from text configuration files.

You can obtain a set of keys for a particular event by executing of the following command:

xmllint --xpath "/event/options/option/@name" $EVENT_XML_FILE | sed 's/name="\([^ ]*\)"/\1\n/g'

The mapping between event XML definition files and event configuration files:

By default the ABRT complains about missing configuration if any of mandatory options is not configured. Mandatory option is option not marked as 'Allow empty'. Run the following command to obtain the list of mandatory options:

xmllint --xpath "/event/options/option[allow-empty!='yes']/@name" $EVENT_XML_FILE \
        | sed 's/name="\([^ ]*\)"/\1\n/g'

Bugzilla reporter plugin accepts the -F option (default: /etc/libreport/plugins/bugzilla_format.conf), which allows user to modify the contents of the newly created bugs. Lines in this file have the following format:

# comment
%summary:: summary format
section:: element1[,element2]...
the literal text line to be added to Bugzilla comment. Can be empty.

Summary format is a line of text, where %element% is replaced by text element's content, and [[...%element%...]] block is used only if %element% exists. [[...]] blocks can nest.

Sections can be:

• %attach:: a list of elements to attach.
• text, double colon (::) and a list of comma-separated elements.

Elements can be:

• problem directory element names, which get formatted as

  <element_name>: <contents>
  

  or

  <element_name>:
  :<contents>
  :<contents>
  :<contents>
  

• problem directory element names prefixed by %bare_, which is formatted as-is, without <element_name>: and starting colons

• %oneline, %multiline, %text wildcards, which select all corresponding elements for output or attachment

• %binary wildcard, valid only for %attach section, instructs to attach binary elements

• problem directory element names prefixed by "-", which excludes given element from all wildcards

Nonexistent elements are silently ignored. If none of elements exists, the section will not be created.

Example:

%summary:: [abrt] %package%[[: %reason%]]

This bug was automatically created by ABRT.

Description of problem:: %bare_comment

Version-Release number of selected component:: %bare_package
Additional info:: \
 -analyzer,-count,-duphash,-uuid,-abrt_version,\
 -username,-hostname,\
 %oneline

Bogosection:: nonexistent_element_name

Backtrace:: %bare_backtrace

%attach:: -comment,-reason,-reported_to,-event_log,%multiline,coredump

Note that empty lines are significant. In the above example, there is no empty line between Version-Release number of selected component and Additional info sections, which will result in these two sections having no empty line between them in newly created bug's description too.

• initial bug formatting: https://github.com/abrt/libreport/blob/master/src/plugins/bugzilla_format.conf
• additional bug comments formatting: https://github.com/abrt/libreport/blob/master/src/plugins/bugzilla_formatdup.conf