• /var/spool/abrt

• C/C++
• Python
• Ruby
• Java
• Kernel
• X.Org

• Make sure that following services are running:

  • abrtd
  • abrt-ccpp

  $ systemctl status abrtd && systemctl status abrt-journal-core

• If one of them is not running you can use the following command to restart both of them:

  # systemctl restart abrtd && systemctl restart abrt-journal-core

• If above doesn't help check journalctl -ex for error logs.

• By default ABRT won't handle crashes produced by 3rd party (unpackaged) software, for this to work read How to enable handling of unpackaged software.

• Edit /etc/abrt/abrt-action-save-package-data.conf and change ProcessUnpackaged = no to ProcessUnpackaged = yes

  # sed -i 's/ProcessUnpackaged = no/ProcessUnpackaged = yes/' /etc/abrt/abrt-action-save-package-data.conf

• Edit /etc/abrt/abrt-action-save-package-data.conf and change OpenGPGCheck = yes to OpenGPGCheck = no

  # sed -i 's/OpenGPGCheck = yes/OpenGPGCheck = no/' /etc/abrt/abrt-action-save-package-data.conf

• Use either GUI application: $ gnome-abrt
• or command line tool: $ abrt ls

• uReport (microreport) is a JSON object representing a problem: binary crash, kerneloops, SELinux AVC denial, etc. These reports are designed to be small and completely anonymous which allows us to use them for automated reporting.

  You can read more at https://github.com/abrt/faf/wiki/uReport

The Linux kernel maintains a taint state which indicates whether something happened to the running kernel that might caused a kernel error.

Common reasons include:

• proprietary kernel module was loaded (P flag)
• previous kernel error (kerneloops) occurred (D flag).
• previous kernel warning (GW flags).
• Both cases D flag and GW flags mean that kernel data structures may be corrupted. Therefore the current error is not necessary a real error, it could be a random consequence of the previous error.
• To get rid of the tainted kernel, you need to reboot your machine or stop loading proprietary modules.
• ABRT respects these flags and won't allow reporting if one or more are in effect because kernel developers are usually not able to fix issues when the kernel is tainted.

Complete list of taint flags:

P - Proprietary module has been loaded.
F - Module has been forcibly loaded.
S - SMP with CPUs not designed for SMP.
R - User forced a module unload.
M - System experienced a machine check exception.
B - System has hit bad_page.
U - Userspace-defined naughtiness.
D - Kernel has oopsed before
A - ACPI table overridden.
W - Taint on warning.
C - modules from drivers/staging are loaded.
I - Working around severe firmware bug.
O - Out-of-tree module has been loaded.

Source: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=kernel/panic.c

If a program developer (or package maintainer) requires some specific information which ABRT is not collecting, they 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

ABRT can create the reports with restricted access which means the access to the report is limited to a group of trusted people. Please note that the restriction differs between various bug trackers and even if you mark something as restricted it still can leak to public, so if you not sure, then don't report anything!

To create a private bugzilla ticket, you have to specify the list of groups to restrict the access to. The tricky part is that it has to be the internal id of the group from bugzilla database. To ease the pain, here is the list of the private group ids for supported bugzillas:

To enable screencasting in abrt you have to install fros package with plugin matching your desktop environment. Currently (2013-08-06) there are only 2 plugins available: fros-gnome and fros-recordmydesktop. Gnome plugin works only with G3, recordmydesktop should work with the most of other desktop environments. To install the plugin run one of the following commands (depends on your DE)

# yum install fros-gnome

# yum install fros-recordmydesktop

ABRT allows package maintainers to override default Bugzilla bug formatting for their packages by providing a component specific Bugzilla bug format template file. The file must be structured according [[these rules|https://github.com/abrt/libreport/wiki/Bugzilla-bugs-formatting]] and must be stored in

• /etc/libreport/plugins/bugzilla_format_$component.conf for initial bug formatting and
• /etc/libreport/plugins/bugzilla_formatdup_$component.conf for additional bug comments

Since the template files references ABRT problem elements, you would probably want to know which problem elements are available and what they mean. [[Check this page to get list of all problem elements with their description|http://rmarko.fedorapeople.org/abrt-python/properties.html]].

FAF collects tainted oopses because each received oops is forwarded to http://oops.kernel.org/ and kernel people want to see every oops and not only untainted ones.

Unusable backtrace is usually caused by damaged coredump, missing debug information or usage of unsupported coding technique (i.e. JavaScript in GNOME3). These cause that the generated backtrace has low information value for developers because function names are replaced with '??' string which is place holder for unavailable function name. In order to provide valuable crash reports, ABRT will not let you create a Bugzilla bug for such a backtrace.

You can use ABRT to send the unusable backtrace to maintainers via 'Email reporter', but this is on your own responsibility.

You can put a problem on the not-notified problems list by clicking 'Ignore Forever' button in the notification bubble. ABRT stores the ignored problems list in a text file stored in $XDG_CACHE_HOME/abrt/ignored_problems [XDG]. The text file consists from lines in CSV format where the first column is path to problem data directory, the second column is UUID (local identifier) and the last column is DUPHASH (global identifier).