Last modified 3 months ago Last modified on 02/06/14 16:14:06

Custom hooks

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 <somedescriptivename>.conf and place it to /etc/libreport/events.d/ from this template:

   <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: This runs 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"
        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_<something> event type. Example:

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


Desktop Session Autoreporting

If the desktop session autoreporting feature is enabled abrt-applet automatically sends an ureport with user's problem immediately after its detection. The ureport is send through execution of report_uReport event. Each event run requires a writable dump directory and in order to make reporting more automatic, abrt-applet steals problem's directory without asking the user. If the uReport server (ABRT server, FAF server, Problem Tracker) knows the problem, abrt-applet lets user to ignore the problem, open the problem in the GUI or show problem's web page. If the problem is unknown, abrt-applet notifies the user and the user can either start reporting process as usual or ignore the problem.

When report_uReport fails and Network Manager's state is not one of the connected states (NM_STATE_CONNECTED_LOCAL, NM_STATE_CONNECTED_SITE, NM_STATE_CONNECTED_GLOBAL), abrt-applet pushes the problem to a deferred queue. Once the Network Manager announces that its state was changed to one of the connected states, the deferred queue will be processed. The deferred queue is destroyed when abrt-applet exits.

If the feature is not enabled abrt-applet sends an ureport on user's requests. The user can request the reporting from a notification shown by abrt-applet. There are two more possible request on the notification. User can either ignore the problem or start the automatic reporting. As was described above, the event run requires a writable dump directory therefore abrt-applet steals problem's directory. The start automatic reporting request enables the autoreporting and processes the problem in the way of automatic reporting.

In this configuration, if a problem is unknown or report_uReport event fails regardless on Network Manager's state, abrt-applet starts reporting as usual.

The foreign problems are never reported automatically even if the autoreporting is enabled. The foreign problems are always processed in the way of processing problems with the autorepoting disabled which is described few paragraphs above. There is small difference in notifications, users can't start the automatic reporting from a foreign problem notification.

Automatic sensitive data filtering

ABRT keeps the global list of 'sensitive words' in /etc/libreport/forbidden_words.conf so in order to change this list for all user admin has to edit this file. There is also per-user list in $HOME/.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

Adjusting plugin configuration

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 to provide configuration through text configuration files, such as /etc/libreport/events/report_Bugzilla.conf. All text configuration files consist from key/value pairs.

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

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:

Event name Definition file Configuration file
Bugzilla report_Bugzilla.xml report_Bugzilla.conf
Logger report_Logger.xml report_Logger.conf
Analyze C/C++ Crash analyze_CCpp.xml analyze_CCpp.conf
Local GNU Debugger analyze_LocalGDB.xml analyze_LocalGDB.conf
Retrace Server analyze_RetraceServer.xml analyze_RetraceServer.conf
Analyze VM core analyze_VMcore.xml analyze_VMcore.conf
Collect GConf configuration collect_GConf.xml collect_GConf.conf
Collect Smolt profile collect_Smolt.xml collect_Smolt.conf
Collect system-wide vim configuration files collect_vimrc_system.xml collect_vimrc_system.conf
Collect yours vim configuration files collect_vimrc_user.xml collect_vimrc_user.conf
Collect .xsession-errors collect_xsession_errors.xml collect_xsession_errors.conf
Post report post_report.xml post_report.conf report_Kerneloops.xml report_Kerneloops.conf
Mailx report_Mailx.xml report_Mailx.conf
Red Hat Customer Support report_RHTSupport.xml report_RHTSupport.conf
Report uploader report_Uploader.xml report_Uploader.conf
uReport report_uReport.xml report_uReport.conf

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 plugin output configuration

Bugzilla reporter plugin accepts the -F <format_file> 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 the list of comma-separated elements.

Elements can be:

  • problem directory element names, which get formatted as
    <element_name>: <contents>
  • problem directory element names prefixed by "%bare_", which is formatted as-is, without "<element_name>:" and 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.


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

This bug was automatically created by ABRT.

Description of problem:: %bare_comment

Version-Release number of selected component:: %bare_package
Additional info:: \

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.