[deployment-guide] Included the revised version of the ABRT chapter.
Jaromir Hradilek
jhradile at fedoraproject.org
Mon Sep 26 16:21:01 UTC 2011
commit 3de73a4f115462f352e46dd814b40ff63338a7b8
Author: Jaromir Hradilek <jhradile at redhat.com>
Date: Mon Sep 26 18:18:49 2011 +0200
Included the revised version of the ABRT chapter.
en-US/Automatic_Bug_Reporting_Tool_ABRT.xml | 1890 ++++++++++++++++++-------
en-US/images/abrt-applet_setting.png | Bin 0 -> 503175 bytes
en-US/images/abrt-applet_setting2.png | Bin 0 -> 47291 bytes
en-US/images/abrt-gui_access.png | Bin 0 -> 499229 bytes
en-US/images/abrt-gui_backtrace_review.png | Bin 0 -> 174340 bytes
en-US/images/abrt-gui_event_configuration.png | Bin 0 -> 38253 bytes
en-US/images/abrt-gui_main_screen.png | Bin 0 -> 186829 bytes
en-US/images/abrt-gui_problem_analyzing.png | Bin 0 -> 67724 bytes
en-US/images/abrt-gui_problem_description.png | Bin 0 -> 134413 bytes
en-US/images/abrt-gui_report_confirmation.png | Bin 0 -> 155420 bytes
en-US/images/abrt-gui_select_analyzer.png | Bin 0 -> 77605 bytes
en-US/images/abrt-gui_select_reporter.png | Bin 0 -> 55173 bytes
12 files changed, 1343 insertions(+), 547 deletions(-)
---
diff --git a/en-US/Automatic_Bug_Reporting_Tool_ABRT.xml b/en-US/Automatic_Bug_Reporting_Tool_ABRT.xml
index 0c3abbd..aeccd8f 100644
--- a/en-US/Automatic_Bug_Reporting_Tool_ABRT.xml
+++ b/en-US/Automatic_Bug_Reporting_Tool_ABRT.xml
@@ -1,790 +1,1586 @@
-<?xml version='1.0'?>
+<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "<application>ABRT</application>-2.x.ent">
+%BOOK_ENTITIES;
]>
-<chapter id="ch-abrt">
- <title>Automatic Bug-Reporting Tool (ABRT)</title>
- <section>
+<chapter
+ id="ch-abrt">
+ <title>Automatic Bug Reporting Tool (<application>ABRT</application>)</title>
+ <section
+ id="sect-abrt-overview">
<title>Overview</title>
+ <important>
+ <title>Migration to <application>ABRT</application> version 2.0</title>
+ <para>
+ For Red Hat Enterprise Linux 6.2, the Automatic Bug Reporting Tool has been upgraded to version 2.0. The <application>ABRT</application> 2-series brings major improvements to automatic bug detection and reporting.
+ </para>
+ <para>For more information on the major differences between the <application>ABRT</application> 1-series and <application>ABRT</application> 2-series,<!--as well as easy migration instructions,--> refer to the <citetitle>Red Hat Enterprise Linux 6.2 Release Notes</citetitle>.</para>
+ <!--<para>For more information on the major differences between the <application>ABRT</application> 1-series and <application>ABRT</application> 2-series, as well as easy migration instructions, refer to <xref linkend="sect-migration_to_abrt2"/>
+ </para>-->
+ </important>
+ <para>
+ <application>ABRT</application> is the <application>Automatic Bug Reporting Tool</application>. <application>ABRT</application> consists of a daemon, <systemitem
+ class="daemon">abrtd</systemitem>, which runs silently in the background most of the time. It springs into action when an application crashes, or a kernel oops is detected. The daemon then collects the relevant problem data such as a core file if there is one, the crashing application's command line parameters, and other data of forensic utility.
+ </para>
+ <para>
+ <application>ABRT</application> currently supports detection of crashes in applications written in the C/C++ and Python languages, as well as kernel oopses.
+ </para>
+ <para>
+ <application>ABRT</application> is capable of reporting problems to a remote issue tracker. Reporting can be configured to happen automatically whenever an issue is detected, or problem data can be stored locally, reviewed, reported, and deleted manually by a user. The reporting tools can send problem data to a Bugzilla database, a Red Hat Technical Support (RHTSupport) site, upload it using <systemitem
+ class="protocol">FTP</systemitem>/<systemitem
+ class="protocol">SCP</systemitem>, email it, or write it to a file.
+ </para>
<para>
- <application>ABRT</application> is the <application>Automatic Bug-Reporting Tool</application>. <application>ABRT</application> consists of a daemon that runs silently in the background most of the time. It springs into action when an application crashes. It then collects the relevant crash data such as a core file if there is one, the crashing application's command line parameters, and other contextual puzzle pieces of forensic utility. Finally, <application>ABRT</application> is capable of reporting crash data to a relevant issue tracker, such as <!-- RHTSupport --> Red Hat Bugzilla. Reporting crash data to a relevant issue tracker can be configured to happen automatically at every detected crash, or crash dumps can be stored locally, reviewed, reported, and deleted manually by a user. <application>ABRT</application>'s various plugins analyze crash data from applications written in the C, C++ and Python language, as well as report crashes to relevant issue trackers.
+ The part of <application>ABRT</application> which handles already-existing problem data (as opposed to, for example, creation of new problem data) has been factored out into a separate project, <application>libreport</application>. The <application>libreport</application> library provides a generic mechanism for analyzing and reporting problems, and it is used by applications other than <application>ABRT</application>. However, <application>ABRT</application> and <application>libreport</application> operation and configuration is closely integrated. They are therefore discussed as one in this document.
</para>
- <para>The <application>ABRT</application> package consists of:
+ <para>
+ The <application>ABRT</application> packages provide the following crucial components, among others:
</para>
<itemizedlist>
<listitem>
<para>
- <systemitem class="daemon">abrtd</systemitem>, the system service
+ <systemitem
+ class="daemon">abrtd</systemitem> — The <application>ABRT</application> daemon which runs under root as a background service.
</para>
</listitem>
<listitem>
<para>
- <application>abrt-applet</application>, which runs in the user's Notification Area
- </para>
+ <application>abrt-applet</application> — The program that receives messages from abrtd and informs you whenever a new problem occurs.
+ </para>
</listitem>
<listitem>
<para>
- <application>abrt-gui</application>, the GUI application that shows collected crash dumps and allows you to edit, report, and delete them
- </para>
+ <application>abrt-gui</application> — The GUI application that shows collected problem data and allows you to further process it.
+ </para>
</listitem>
<listitem>
<para>
- <application>abrt-cli</application>, the command line interface with functionality similar to <application>abrt-gui</application>.
- </para>
+ <application>abrt-cli</application> — The command line interface, which provides similar functionality to the GUI.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <systemitem
+ class="service">abrt-ccpp</systemitem>, the <application>ABRT</application> service that provides the C/C++ problems analyzer
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <systemitem
+ class="service">abrt-oops</systemitem>, the <application>ABRT</application> service that provides the kernel oopses analyzer.
+ </para>
</listitem>
</itemizedlist>
- <para>You can open the <application>ABRT</application> GUI application by selecting <menuchoice><guimenu>Applications</guimenu><guisubmenu>System Tools</guisubmenu><guimenuitem>Automatic Bug Reporting Tool</guimenuitem></menuchoice> from the <guimenu>Activities</guimenu> menu.
+ </section>
+ <section
+ id="sect-abrt-installation">
+ <title>Installing <application>ABRT</application> and Starting the abrtd Service</title>
+ <para>
+ As the first step in order to use <application>ABRT</application>, you should ensure that the <package>abrt-desktop</package> package is installed on your system by running the following command as the root user:
</para>
- <figure id="fig-ABRT-Main_Window">
- <title>The Automatic Bug Reporting Tool main window</title>
+ <screen>~]# <command>yum install abrt-desktop</command></screen>
+ <para>
+ With <package>abrt-desktop</package> installed, you will be able to use <application>ABRT</application> only in its graphical interface. If you intend to use <application>ABRT</application> on the command line, install the <package>abrt-cli</package> package:
+ </para>
+ <screen>~]# <command>yum install abrt-cli</command></screen>
+ <para>
+ For more information on how to install packages with the <application>Yum</application> package manager, refer to <xref
+ linkend="sec-Installing"/>
+ </para>
+ <para>
+ Your next step should be to verify that the <systemitem
+ class="daemon">abrtd</systemitem> is running. The daemon is typically configured to start up at boot time. You can use the following command as root to verify its current status:
+ </para>
+ <screen>~]# <command>service abrtd status</command>
+abrtd (pid 1535) is running...</screen>
+ <para>
+ If the <command>service</command> command returns the <computeroutput>abrt is stopped</computeroutput> message, the daemon is not running. It can be started for the current session by entering this command:
+ </para>
+ <screen>~]# <command>service abrtd start</command>
+Starting abrt daemon: [OK]</screen>
+ <para>
+ You can run the following <command>chkconfig</command> command to ensure that the <systemitem
+ class="daemon">abrtd</systemitem> service initializes every time the system starts up:
+ </para>
+ <screen>~]# <command>chkconfig abrtd on</command>
+ </screen>
+ <para>
+ Similarly, you can follow the same steps to check and configure the <systemitem
+ class="service">abrt-ccpp</systemitem> service if you want <application>ABRT</application> to catch C/C++ crashes. To set <application>ABRT</application> to detect kernel oopses, use the same steps for the <systemitem
+ class="service">abrt-oops</systemitem> service. Note that this service cannot catch kernel oopses which cause the system to fail to become unresponsive or to reboot immediately.
+ </para>
+ <!-- mprpic: not implemented in rhel6.2 yet, planned for rhel6.3
+
+ You need to enable and configure the <systemitem
+ class="service">abrt-vmcore</systemitem> service instead of the <systemitem
+ class="service">abrt-oops</systemitem> service if your system is configured to reboot if the kernel panics. You can determine whether your system is configured to reboot in the event of a kernel panic (or "oops") by running the following command:
+ </para>
+ <screen>]$ <command>sysctl kernel.panic</command>
+kernel.panic = 0</screen>
+ <para>The value of the kernel.panic sysctl setting is the number of seconds after a kernel panic at which the kernel will reboot. A value of <constant>0</constant> indicates that the kernel will not reboot, in which case the <systemitem
+ class="daemon">abrt-oops</systemitem> service should be enabled instead of the <systemitem
+ class="daemon">abrt-vmcore</systemitem> service.</para>-->
+ <para>
+ Finally, you can verify that the <systemitem
+ class="service">ABRT notification applet</systemitem> is running:
+ </para>
+ <screen>~]$ <command>ps -el | grep abrt-applet</command>
+0 S 500 2036 1824 0 80 0 - 61604 poll_s ? 00:00:00 abrt-applet</screen>
+ <para>
+ If the <application>ABRT</application> notification applet is not running, you can start it manually in your current desktop session by running the <systemitem
+ class="service">abrt-applet</systemitem> program:
+ </para>
+ <screen>~]$ <command>abrt-applet &</command>
+[1] 2261</screen>
+ <para>
+ The applet can be configured to start automatically when your graphical desktop session starts. For example, on the GNOME desktop this can be achieved by accessing the <menuchoice><guimenu>System</guimenu>
+ <guisubmenu>Preferences</guisubmenu>
+ <guimenuitem>Startup Applications</guimenuitem>
+ </menuchoice> menu and ensuring that the <application>ABRT</application> notification applet is added to the list of programs and selected to run on at system startup.
+ </para>
+ <figure
+ id="fig-abrt-applet_setting-1">
+ <title>Setting the <application>ABRT</application> notification applet to run automatically</title>
<mediaobject>
<imageobject>
- <imagedata align="center" fileref="images/abrt.png" format="PNG" scalefit="0" />
+ <imagedata
+ fileref="images/abrt-applet_setting.png"
+ format="PNG"
+ scalefit="0" />
</imageobject>
<textobject>
- <para>The Automatic Bug Reporting Tool main window</para>
+ <para>
+ How to set <application>ABRT</application> notification applet to run automatically
+ </para>
</textobject>
</mediaobject>
</figure>
- <para>A number of additional packages can be installed to provide <application>ABRT</application> plugins and addons. To view all the available <application>ABRT</application> packages, type the following command:</para>
- <screen><command>yum list all | grep abrt</command></screen>
- </section>
- <section>
- <title>Installing and Running ABRT</title>
- <para>By default, <application>ABRT</application> should be installed on your system, the <systemitem class="daemon">abrtd</systemitem> daemon configured to run at boot time, and <application>abrt-applet</application> to run in the Notification Area of your desktop session.
- </para>
- <note>
- <title>Installing the ABRT packages</title>
- <para>In order to use <application>ABRT</application>, first ensure the <command>abrt-desktop</command> package is installed on your system by running, as <systemitem class="username">root</systemitem>:
- </para>
- <screen><command>yum install abrt-desktop</command></screen>
- <para>For more information on installing packages with Yum, refer to <xref linkend="sec-Installing"/>.</para>
- </note>
- <para>
- <application>ABRT</application> is typically configured to start up at boot time. You can check that the <systemitem class="daemon">abrtd</systemitem> daemon is running by running the following command, as <systemitem class="username">root</systemitem>:</para>
- <screen><command>systemctl is-active abrtd.service</command></screen>
- <para>If you receive <computeroutput>abrt is stopped</computeroutput>, you can start the <systemitem class="daemon">abrtd</systemitem>
- service by running, as <systemitem class="username">root</systemitem>:</para>
- <screen><command>systemctl start abrtd.service</command></screen>
- <para>You can ensure that the <systemitem class="daemon">abrtd</systemitem> service initializes at startup time by running the following command, as <systemitem class="username">root</systemitem>:</para>
- <screen><command>systemctl enable abrtd.service</command></screen>
- <para>
- <application>ABRT</application>'s applet can be started by hand by running the <command>abrt-applet</command> program as a normal user when logged into your desktop session, or by arranging for it to be started when the GUI session is initialized.</para>
- <figure id="fig-ABRT-Notification_Area_alarm_icon">
- <title>The ABRT problem report</title>
+ <figure
+ id="fig-abrt-applet_setting-2">
+ <title>Setting <application>ABRT</application> notification applet to run automatically.</title>
<mediaobject>
<imageobject>
- <imagedata fileref="images/abrt-alert.png" format="PNG" scalefit="0" />
+ <imagedata
+ fileref="images/abrt-applet_setting2.png"
+ format="PNG"
+ scalefit="0" />
</imageobject>
<textobject>
- <para>The ABRT problem report</para>
+ <para>
+ How to set the <application>ABRT</application> notification applet to run automatically.
+ </para>
</textobject>
</mediaobject>
</figure>
- <para>When a crash is detected and saved, a broadcast <systemitem>D-Bus</systemitem> message is sent about this crash. If <command>abrt-applet</command> is running, it receives this message and displays an alarm icon in the Notification Area. You can open the GUI application by clicking on this icon.</para>
- <para>Alternatively, you can open the <application>ABRT</application> GUI application by selecting <menuchoice><guimenu>Applications</guimenu><guisubmenu>System Tools</guisubmenu><guimenuitem>Automatic Bug Reporting Tool</guimenuitem></menuchoice> from the <guimenu>Activities</guimenu> menu.
+ </section>
+ <section
+ id="sect-abrt-running">
+ <title>Running <application>ABRT</application>
+ </title>
+ <para>
+ Whenever a problem is detected, <application>ABRT</application> compares it with all existing problem data and determines whether that same problem has been recorded. If it has been, the existing problem data is updated and the most recent (duplicate) problem is not recorded again. If this problem is not recognized by <application>ABRT</application>, a <emphasis
+ role="bold">problem data directory</emphasis> is created. A problem data directory typically consists of files such as:
</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <filename>analyzer</filename>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>architecture</filename>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>coredump</filename>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>cmdline</filename>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>executable</filename>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>kernel</filename>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>os_release</filename>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>reason</filename>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>time</filename>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>uid</filename>
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ Other files, such as <filename>backtrace</filename>, can be created during analysis depending on which analyzer method is used and its configuration settings. Each of these files holds specific information about the system and the problem itself. For example, the <filename>kernel</filename> file records the version of the crashed kernel.
+ </para>
+ <section
+ id="sect-abrt-gui">
+ <title>Using the Graphical User Interface</title>
+ <para>
+ The <application>ABRT</application> daemon sends a broadcast D-Bus message whenever a problem report is created. If the <application>ABRT</application> notification applet is running, it catches this message and displays an orange alarm icon in the Notification Area. You can open the <application>ABRT GUI</application> application using this icon. As an alternative, you can display the <application>ABRT</application> GUI by selecting the <menuchoice><guimenu>Application</guimenu>
+ <guisubmenu>System Tools</guisubmenu>
+ <guimenuitem>Automatic Bug Reporting Tool</guimenuitem>
+ </menuchoice> menu item.
+ </para>
+ <figure
+ id="fig-abrt-gui_access">
+ <title>Running the <application>ABRT</application> GUI from the <guimenu>Applications</guimenu> menu.</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/abrt-gui_access.png"
+ format="PNG"
+ scalefit="0" />
+ </imageobject>
+ <textobject>
+ <para>
+ Running the <application>ABRT</application> GUI from the <guimenu>Applications</guimenu> menu.
+ </para>
+ </textobject>
+ </mediaobject>
+ </figure>
+ <para>
+ Alternatively, you can run the <application>ABRT</application> GUI from the command line as follows:
+ </para>
+ <screen>
+~]$ <command>abrt-gui</command> &
+ </screen>
+ <para>
+ The <application>ABRT</application> GUI provides an easy and intuitive way of viewing, reporting and deleting of reported problems. The <application>ABRT</application> window displays a list of detected problems. Each problem entry consists of the name of the failing application, the reason why the application crashed, and the date of the last occurrence of the problem.
+ </para>
+ <figure
+ id="fig-abrt-gui_main_screen">
+ <title>An example of running <application>ABRT</application> GUI.</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/abrt-gui_main_screen.png"
+ format="PNG"
+ scalefit="0" />
+ </imageobject>
+ <textobject>
+ <para>ABRT displaying its list of crashed applications</para>
+ </textobject>
+ </mediaobject>
+ </figure>
+ <para>
+ If you double-click on a problem report line, you can access the detailed problem description and proceed with the process of determining how the problem should be analyzed, and where it should be reported.
+ </para>
+ <figure
+ id="fig-abrt-gui_problem_description">
+ <title>A detailed problem data example.</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/abrt-gui_problem_description.png"
+ format="PNG"
+ scalefit="0" />
+ </imageobject>
+ <textobject>
+ <para>Viewing detailed problem data</para>
+ </textobject>
+ </mediaobject>
+ </figure>
+ <para>
+ You are first asked to provide additional information about the problem which occurred. You should provide detailed information on how the problem happened and what steps should be done in order to reproduce it. In the next steps, choose how the problem will be analyzed and generate a backtrace depending on your configuration. You can skip the analysis and backtrace-generation steps.
+ </para>
+ <figure
+ id="fig-abrt-gui_select_analyzer">
+ <title>Selecting how to analyze the problem.</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/abrt-gui_select_analyzer.png"
+ format="PNG"
+ scalefit="0" />
+ </imageobject>
+ <textobject>
+ <para>Selecting how to analyze the problem.</para>
+ </textobject>
+ </mediaobject>
+ </figure>
+ <figure
+ id="fig-abrt-gui_problem_analyzing">
+ <title>ABRT analyzing the problem</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/abrt-gui_problem_analyzing.png"
+ format="PNG"
+ scalefit="0" />
+ </imageobject>
+ <textobject>
+ <para>ABRT analyzing the problem</para>
+ </textobject>
+ </mediaobject>
+ </figure>
+ <para>Next, choose how you want to report the issue.</para>
+ <figure
+ id="fig-abrt-gui_select_reporter">
+ <title>Selecting a problem reporter.</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/abrt-gui_select_reporter.png"
+ format="PNG"
+ scalefit="0" />
+ </imageobject>
+ <textobject>
+ <para>Selecting a problem reporter.</para>
+ </textobject>
+ </mediaobject>
+ </figure>
+ <para>Finally, review the backtrace and confirm the data to be reported.</para>
+ <figure
+ id="fig-abrt-gui_backtrace_review">
+ <title>Reviewing the problem backtrace.</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/abrt-gui_backtrace_review.png"
+ format="PNG"
+ scalefit="0" />
+ </imageobject>
+ <textobject>
+ <para>Reviewing the problem backtrace.</para>
+ </textobject>
+ </mediaobject>
+ </figure>
+ <figure
+ id="fig-abrt-gui_report_confirmation">
+ <title>Confirming the data to report.</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata
+ fileref="images/abrt-gui_report_confirmation.png"
+ format="PNG"
+ scalefit="0" />
+ </imageobject>
+ <textobject>
+ <para>Confirming the data to report.</para>
+ </textobject>
+ </mediaobject>
+ </figure>
+ </section>
+ <section
+ id="sect-abrt-cli">
+ <title>Using the Command Line Interface</title>
+ <para>
+ Problem data saved by <systemitem
+ class="daemon">abrtd</systemitem> can be viewed, reported, and deleted using the command line interface.
+ </para>
+ <para>
+ General usage of the <application>abrt-cli</application> tool can be described using the following syntax:
+ </para>
+ <synopsis>
+ abrt-cli <optional>--version</optional> <command> <optional><args></optional>
+ </synopsis>
+ <para>…where <varname>args</varname> stands for a problem data directory and/or options modifying the commands, and <varname>command</varname> is one of the following sub-commands:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <command>list</command> — lists problems and views the problem data.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <command>report</command> — analyzes and reports problems.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <command>rm</command> — removes unneeded problems.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <command>info</command> — provides information about a particular problem.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>To display help on particular <command>abrt-cli</command> command use:</para>
+ <synopsis>
+ <command>abrt-cli <replaceable>command</replaceable>
+ <option>--help</option>
+ </command>
+ </synopsis>
+ <para>The rest of the commands used with <application>abrt-cli</application> are described in the following sections.</para>
+ <section
+ id="sect-abrt-cli_viewing_problems">
+ <title>Viewing Problems</title>
+ <para>
+ To view detected problems, enter the <command>abrt-cli list</command> command:
+ </para>
+ <screen>
+~]# <command>abrt-cli list</command>
+Directory: /var/spool/abrt/ccpp-2011-09-13-10:18:14-2895
+count: 2
+executable: /usr/bin/gdb
+package: gdb-7.2-48.el6
+time: Tue 13 Sep 2011 10:18:14 AM CEST
+uid: 500
+
+Directory: /var/spool/abrt/ccpp-2011-09-21-18:18:07-2841
+count: 1
+executable: /bin/bash
+package: bash-4.1.2-8.el6
+time: Wed 21 Sep 2011 06:18:07 PM CEST
+uid: 500</screen>
+ <!--<para>Note that you can add one or more of the <option>- -full</option>, <option>- -detailed</option> or <option>- -verbose</option> flags to the <command>abrt-cli list</command> command to display more detailed data about the problem.</para>
+ <para>If you run <command>abrt-cli list</command> without any arguments, only crashes which have not yet been viewed are displayed.</para>
+ <para>Here are descriptions of various fields in the output:</para>-->
+ <itemizedlist>
+ <listitem>
+ <para>
+ <computeroutput>Directory</computeroutput> — Shows the problem data directory that contains all information about the problem.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <computeroutput>count</computeroutput> — Shows how many times this particular problem occurred.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <computeroutput>executable</computeroutput> — Indicates which binary or executable script crashed.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <computeroutput>package</computeroutput> — Shows the name of the package that contains the program that caused the problem.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <computeroutput>time:</computeroutput> — Shows the date and time of the last occurrence of the problem.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <computeroutput>uid:</computeroutput> — Shows the ID of the user which ran the program that crashed.</para>
+ </listitem>
+ </itemizedlist>
+ <para>The following table shows options available with the <command>abrt-cli list</command> command. All options are mutually inclusive so you can combine them according to your need. The command output will be the most comprehensive if you combine all options, and you will receive the least details if you use no additional options.
+ </para>
+ <table
+ id="tab-abrt-cli_list">
+ <title>The <command>abrt-cli list</command> command options</title>
+ <tgroup
+ cols="2">
+ <colspec
+ colname="command"
+ colnum="1"
+ colwidth="30*"/>
+ <colspec
+ colname="argument"
+ colnum="2"
+ colwidth="70*"/>
+ <thead>
+ <row>
+ <entry>
+ Option
+ </entry>
+ <entry>
+ Description
+ </entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>
+
+ </entry>
+ <entry>
+ With no additional option, the <command>abrt-cli list</command> command displays only basic information for problems that have not been reported yet.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <option>-d</option>, <option>--detailed</option>
+ </entry>
+ <entry>
+ Displays all stored information about problems listed, including a <filename>backtrace</filename> if it has already been generated.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <option>-f</option>, <option>--full</option>
+ </entry>
+ <entry>
+ Displays basic information for all problems including the already-reported ones.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <option>-v</option>, <option>--verbose</option>
+ </entry>
+ <entry>
+ Provides additional information on its actions.
+ </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ <para>
+ If you want to view information just about one particular problem, you can use the command:
+ <synopsis>
+ <command>abrt-cli info</command> <replaceable><DIR></replaceable>
+ </synopsis>
+ …where <varname>DIR</varname> stands for the <emphasis
+ role="bold">problem data directory</emphasis> of the problem that is being viewed. The following table shows options available with the <command>abrt-cli info</command> command. All options are mutually inclusive so you can combine them according to your need. The command output will be the most comprehensive if you combine all options, and you will receive the least details if you use no additional options.
+ </para>
+ <table
+ id="tab-abrt-cli_info">
+ <title>The <command>abrt-cli info</command> command options</title>
+ <tgroup
+ cols="2">
+ <colspec
+ colname="command"
+ colnum="1"
+ colwidth="30*"/>
+ <colspec
+ colname="argument"
+ colnum="2"
+ colwidth="70*"/>
+ <thead>
+ <row>
+ <entry>
+ Option
+ </entry>
+ <entry>
+ Description
+ </entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>
+
+ </entry>
+ <entry>
+ With no additional option, the <command>abrt-cli info</command> command displays only basic information for the problem specified by the <systemitem>problem data directory</systemitem> argument.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <option>-d</option>, <option>--detailed</option>
+ </entry>
+ <entry>
+ Displays all stored information for the problem specified by the <systemitem>problem data directory</systemitem> argument, including a <filename>backtrace</filename> if it has already been generated.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <option>-v</option>, <option>--verbose</option>
+ </entry>
+ <entry>
+ <command>abrt-cli info</command> provides additional information on its actions.
+ </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ </section>
+ <section
+ id="sect-abrt-cli_reporting_problems">
+ <title>Reporting Problems</title>
+ <para>
+ To report a certain problem, enter the <command>abrt-cli report <replaceable><DIR></replaceable>
+ </command> command where <varname>DIR</varname> stands for the <emphasis
+ role="bold">problem data directory</emphasis> of the problem that is being reported. For example:
+ </para>
+ <screen>
+~]$ <command>abrt-cli report</command> <filename>/var/spool/abrt/ccpp-2011-09-13-10:18:14-2895</filename>
+How you would like to analyze the problem?
+1) Collect .xsession-errors
+2) Local GNU Debugger
+Select analyzer: _</screen>
+ <para>
+ <application>ABRT</application> prompts you to select an analyzer event for the problem that is being reported. After selecting an event, the problem is analyzed. This can take a considerable amount of time. When the problem report is ready, <command>abrt-cli</command> opens a text editor with the content of the report. You can see what is being reported, and you can fill in instructions on how to reproduce the crash and other comments. You should also check the backtrace, because the backtrace might be sent to a public server and viewed by anyone, depending on the problem reporter event settings.
+ </para>
+ <note>
+ <title>Selecting a preferred text editor</title>
+ <para>
+ You can choose which text editor is used to check the reports. <command>abrt-cli</command> uses the editor defined in the <envar>ABRT_EDITOR</envar> environment variable. If the variable is not defined, it checks the <envar>VISUAL</envar> and <envar>EDITOR</envar> variables. If none of these variables is set, <command>vi</command> is used. You can set the preferred editor in your <filename>.bashrc</filename> configuration file. For example, if you prefer GNU Emacs, add the following line to the file:
+ </para>
+ <screen>
+export <varname>VISUAL</varname>=<userinput>emacs</userinput></screen>
+ </note>
+ <para>
+ When you are done with the report, save your changes and close the editor. You will be asked which of the configured <application>ABRT</application> reporter events you want to use to send the report.
+ </para>
+ <screen>
+How would you like to report the problem?
+1) Logger
+2) Red Hat Customer Support
+Select reporter(s): _</screen>
+ <para>
+ After selecting a reporting method, you can proceed with reviewing data to be sent with the report. The
+ following table shows options available with the <command>abrt-cli report</command> command.
+ </para>
+ <table
+ id="tab-abrt-cli_report">
+ <title>The <command>abrt-cli report</command> command options</title>
+ <tgroup
+ cols="2">
+ <colspec
+ colname="command"
+ colnum="1"
+ colwidth="30*"/>
+ <colspec
+ colname="argument"
+ colnum="2"
+ colwidth="70*"/>
+ <thead>
+ <row>
+ <entry>
+ Option
+ </entry>
+ <entry>
+ Description
+ </entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>
+
+ </entry>
+ <entry>
+ With no additional option, the <command>abrt-cli report</command> provides the usual output.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <option>-v</option>, <option>--verbose</option>
+ </entry>
+ <entry>
+ <command>abrt-cli report</command> provides additional information on its actions.
+ </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ </section>
+ <section
+ id="sect-abrt-cli_deleting_problems">
+ <title>
+ Deleting Problems
+ </title>
+ <para>
+ If you are certain that you do not want to report a particular problem, you can delete it. To delete a problem so <application>ABRT</application> does not keep information about it, use the <command>abrt-cli rm <replaceable><DIR></replaceable>
+ </command> command where <varname>DIR</varname> stands for the problem data directory of the problem being deleted. For example:
+ </para>
+ <screen>
+~]$ <command>abrt-cli rm</command> <filename>/var/spool/abrt/ccpp-2011-09-12-18:37:24-4413</filename>
+rm '/var/spool/abrt/ccpp-2011-09-12-18:37:24-4413'</screen>
+ <note>
+ <title>Deletion of a problem can lead to frequent ABRT notification</title>
+ <para>
+ Note that <application>ABRT</application> performs a detection of duplicate problems by comparing new problems with all locally saved problems. For a repeating crash, <application>ABRT</application> requires you to act upon it only once. However, if you delete the crash dump of that problem, the next time this specific problem occurs, <application>ABRT</application> will treat it as a new crash: <application>ABRT</application> will alert you about it, prompt you to fill in a description, and report it. To avoid having <application>ABRT</application> notifying you about a recurring problem, do not delete its problem data.
+ </para>
+ </note>
+ <para>
+ The following table shows options available with the <command>abrt-cli rm</command> command.
+ </para>
+ <table
+ id="tab-abrt-cli_rm">
+ <title>The <command>abrt-cli rm</command> command options</title>
+ <tgroup
+ cols="2">
+ <colspec
+ colname="command"
+ colnum="1"
+ colwidth="30*"/>
+ <colspec
+ colname="argument"
+ colnum="2"
+ colwidth="70*"/>
+ <thead>
+ <row>
+ <entry>
+ Option
+ </entry>
+ <entry>
+ Description
+ </entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>
+
+ </entry>
+ <entry>
+ With no additional option, the <command>abrt-cli rm</command> .
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <option>-v</option>, <option>--verbose</option>
+ </entry>
+ <entry>
+ <command>abrt-cli rm</command> provides additional information on its actions.
+ </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ </section>
+ </section>
</section>
- <section id="abrt-plugins">
- <title>
- ABRT Plugins</title>
+ <section
+ id="sect-abrt-configuration">
+ <title>Configuring ABRT</title>
+ <para>
+ A <emphasis>problem</emphasis> life cycle is driven by <emphasis>events</emphasis> in <application>ABRT</application>. For example:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Event 1 - a problem data directory is created.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Event 2 - problem data is analyzed.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Event 3 - a problem is reported to Bugzilla.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ When a problem is detected and its defining data is stored, the problem is processed by running events on the
+ problem's data directory. For more information on events and how to define one, refer to <xref
+ linkend="sect-abrt-configuration-events"/>. Standard <application>ABRT</application> installation currently
+ supports several default events that can be selected and used during problem reporting process. Refer to <xref
+ linkend="sect-abrt-configuration-events-default_events"/> to see the list of these events.
+ </para>
+ <para>
+ Upon installation, <application>ABRT</application> and <application>libreport</application> place their respective configuration files into the several directories on a system:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <filename>/etc/libreport/</filename> — contains the <filename>report_event.conf</filename> main configuration file. More information about this configuration file can be found in <xref
+ linkend="sect-abrt-configuration-events"/>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>/etc/libreport/events/</filename> — holds files specifying the default setting of predefined events.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>/etc/libreport/events.d/</filename> — keeps configuration files defining events.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>/etc/libreport/plugins/</filename> — contains configuration files of programs that take part in events.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>/etc/abrt/</filename> — holds <application>ABRT</application> specific configuration files used to modify the behavior of <application>ABRT</application>'s services and programs. More information about certain specific configuration files can be found in <xref
+ linkend="sect-abrt-configuration-abrt"/>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>/etc/abrt/plugins/</filename> — keeps configuration files used to override the default setting of <application>ABRT</application>'s services and programs. For more information on some specific configuration files refer to <xref
+ linkend="sect-abrt-configuration-abrt"/>.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <section
+ id="sect-abrt-configuration-events">
+ <title>ABRT Events</title>
+ <para>
+ Each event is defined by one rule structure in a respective configuration file. The configuration files are typically stored in the <filename>/etc/libreport/events.d/</filename> directory. These configuration files are used by the main configuration file, <filename>/etc/libreport/report_event.conf</filename>.
+ </para>
+ <para>
+ The <filename>/etc/libreport/report_event.conf</filename> file consists of <emphasis>include
+ directives</emphasis> and <emphasis>rules</emphasis>. Rules are typically stored in other configuration files in
+ the <filename>/etc/libreport/events.d/</filename> directory. In the standard installation, the
+ <filename>/etc/libreport/report_event.conf</filename> file contains only one include directive:
+ </para>
+ <screen><code>include events.d/*.conf</code></screen>
+ <para>
+ If you would like to modify this file, please note that it respects shell metacharacters (*,$,?, etc.) and interprets relative paths relatively to its location.
+ </para>
+ <para>
+ Each <emphasis>rule</emphasis> starts with a line with a non-space leading character, all subsequent lines starting with the <systemitem>space</systemitem> character or the <systemitem>tab</systemitem> character are considered a part of this rule. Each <emphasis>rule</emphasis> consists of two parts, a <emphasis>condition</emphasis> part and a <emphasis>program</emphasis> part. The condition part contains conditions in one of the following forms:
+ </para>
+<itemizedlist>
+ <listitem>
+ <para><replaceable>VAR</replaceable>=<replaceable>VAL</replaceable>,</para>
+ </listitem>
+ <listitem>
+ <para>
+ <replaceable>VAR</replaceable>!=<replaceable>VAL</replaceable>, or
+ </para>
+ </listitem>
+ <listitem>
<para>
- <application>ABRT</application> offers a variety of analyzer plugins and reporter plugins. These plugins are described in the following two sections. Not all of the plugins mentioned in the following sections are installed by default. To view all available plugins, run the following command:
- <screen><command>yum list all | grep abrt-plugin-*</command></screen>
+ <replaceable>VAL</replaceable>~=<replaceable>REGEX</replaceable>
</para>
- <section id="analyzer-plugins">
- <title>Analyzer Plugins</title>
+ </listitem>
+</itemizedlist>
<para>
- These plugins serve as analyzers and crash information collectors for specific types of crashes. For example, the <application>Kerneloops</application> analyzer plugin checks for crashes in the kernel only. These plugins can be enabled/disabled from loading at start-up in their corresponding configuration files placed in the <filename>/etc/abrt/plugins/</filename> directory. The following is a list of all analyzer plugins.
+ …where:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para><varname>VAR</varname> is either the <constant>EVENT</constant> key word or a name of a problem data
+ directory element (such as <filename>executable</filename>, <filename>package</filename>,
+ <filename>hostname</filename>, etc.),</para>
+ </listitem>
+ <listitem>
+ <para>
+ <varname>VAL</varname> is either a name of an event or a problem data element, and
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <varname>REGEX</varname> is a regular expression.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>The program part consists of program names and shell interpretable code. If all conditions in the condition part
+ are valid, the program part is run in the shell. The following is an <emphasis>event</emphasis> example:
+ </para>
+ <screen>
+EVENT=post-create date >/tmp/dt
+ echo $HOSTNAME `uname -r`</screen>
+ <para>
+ This event would overwrite the contents of the <filename>/tmp/dt</filename> file with the current date and time,
+ and print the hostname of the machine and its kernel version on the standard output.
+ </para>
+ <para>
+ Here is an example of a yet more complex event which is actually one of the predefined events. It saves relevant
+ lines from the <filename>~/.xsession-errors</filename> file to the problem report for any problem for which the
+ <systemitem>abrt-ccpp</systemitem> services has been used to process that problem, and the crashed application
+ has loaded any X11 libraries at the time of crash:
+ </para>
+ <screen>
+EVENT=analyze_xsession_errors analyzer=CCpp dso_list~=.*/libX11.*
+ test -f ~/.xsession-errors || { echo "No ~/.xsession-errors"; exit 1; }
+ test -r ~/.xsession-errors || { echo "Can't read ~/.xsession-errors"; exit 1; }
+ executable=`cat executable` &&
+ base_executable=${executable##*/} &&
+ grep -F -e "$base_executable" ~/.xsession-errors | tail -999 >xsession_errors &&
+ echo "Element 'xsession_errors' saved"</screen>
+ <para>
+ The set of possible events is not hard-set. System administrators can add events according to their need. Currently, the following event names are provided with standard <application>ABRT</application> and <application>libreport</application> installation:
</para>
<variablelist>
<varlistentry>
- <term>Kerneloops</term>
+ <term>
+ <systemitem class="event">post-create</systemitem>
+ </term>
<listitem>
<para>
- — Checks for crashes in the kernel and consequently collects kernel crash information. It can be enabled/disabled from loading at start-up in the <filename>/etc/abrt/plugins/Kerneloops.conf</filename> file.
+ This event is run by <systemitem
+ class="daemon">abrtd</systemitem> on newly created problem data directories. When the <systemitem class="event">post-create</systemitem> event is run, <systemitem
+ class="daemon">abrtd</systemitem> checks whether the UUID identifier of the new problem data matches the UUID of any already existing problem directories. If such a problem directory exists, the new problem data is deleted.
</para>
</listitem>
</varlistentry>
<varlistentry>
- <term>Python</term>
+ <term>
+ <systemitem class="event">analyze_<replaceable><NAME_SUFFIX></replaceable></systemitem>
+ </term>
<listitem>
<para>
- — Checks for crashes in Python programs and consequently collects the crash information. It can be enabled/disabled from loading at start-up in the <filename>/etc/abrt/plugins/Python.conf</filename> file.
+ …where <varname>NAME_SUFFIX</varname> is the adjustable part of the event name. This event is used to process collected data. For example, the <systemitem
+ class="event">analyze_LocalGDB</systemitem> runs the GNU Debugger (<application>GDB</application>) utility on a core dump of an application and produces a backtrace of a program. You can view the list of analyze events and choose from it using <application>abrt-gui</application>.
</para>
</listitem>
</varlistentry>
<varlistentry>
- <term>CCpp</term>
+ <term>
+ <systemitem class="event">collect_<replaceable><NAME_SUFFIX></replaceable></systemitem>
+ </term>
<listitem>
<para>
- — Checks for crashes in C and C++ programs and consequently collects the crash information. It can be enabled/disabled from loading at start-up in the <filename>/etc/abrt/plugins/CCpp.conf</filename> file.
+ …where <varname>NAME_SUFFIX</varname> is the adjustable part of the event name. This event is used to collect additional information on a problem. You can view the list of collect events and choose from it using <application>abrt-gui</application>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <systemitem class="event">report_<replaceable><NAME_SUFFIX></replaceable></systemitem>
+ </term>
+ <listitem>
+ <para>
+ …where <varname>NAME_SUFFIX</varname> is the adjustable part of the event name. This event is used to report a problem. You can view the list of report events and choose from it using <application>abrt-gui</application>.
</para>
</listitem>
</varlistentry>
</variablelist>
+ <para>
+ Additional information about events (such as their description, names and types of parameters which can be passed to them as environment variables, and other properties) is stored in the <filename>/etc/libreport/events/<replaceable><event_name></replaceable>.xml</filename> files. These files are used by <application>abrt-gui</application> and <application>abrt-cli</application> to make the user interface more friendly. Do not edit these files unless you want to modify the standard installation.
+ </para>
</section>
- <section id="reporter-plugins">
- <title>Reporter Plugins</title>
+ <section
+ id="sect-abrt-configuration-events-default_events">
+ <title>Standard ABRT Installation Supported Events</title>
<para>
- These plugins gather the crash data acquired by the analyzer plugins, combine the data with any user input (such as comments about the crash, reproducibility, etc.), and provide a specific output. Each of these plugins is configurable in its corresponding configuration file placed in the <filename>/etc/abrt/plugins/</filename> directory or in the <application>ABRT</application> GUI application (for more information on reporter plugin configuration in the <application>ABRT</application> GUI application, refer to <xref linkend="configuring-plugins-in-the-gui"/>).
+ Standard <application>ABRT</application> installation currently provides a number of default analyzing,
+ collecting and reporting events. Some of these events are also configurable using the
+ <application>ABRT</application> GUI application (for more information on event configuration using
+ <application>ABRT</application> GUI, refer to <xref
+ linkend="sect-abrt-configuration-event_configuration_in_gui"/>). <application>ABRT</application> GUI only shows
+ the event's unique part of the name which is more readable the user, instead of the complete event name. For
+ example, the <systemitem class="event">analyze_xsession_errors</systemitem> event is shown as
+ <systemitem>Collect .xsession-errors</systemitem> in <application>ABRT</application> GUI. The following is
+ a list of default analyzing, collecting and reporting events provided by the standard installation of
+ <application>ABRT</application>:
</para>
<variablelist>
- <!-- jhradilek: This does not seem to be relevant to Fedora.
<varlistentry>
- <term>RHTSupport</term>
+ <term>
+ analyze_LocalGDB — Local GNU Debugger
+ </term>
<listitem>
<para>
- — Reports crashes into the Red Hat Technical Support system. Intended for users of &MAJOROS;.
+ Runs <application>GDB</application> (the GNU debugger) on problem data of an application and generates a <filename>backtrace</filename> of a program. It is defined in the <filename>/etc/libreport/events.d/ccpp_event.conf</filename> configuration file.
</para>
</listitem>
</varlistentry>
- -->
<varlistentry>
- <term>MailX</term>
+ <term>
+ analyze_xsession_errors — Collect .xsession-errors
+ </term>
<listitem>
<para>
- — Sends a crash report via the <application>mailx</application> utility to a specified email address.
+ Saves relevant lines from the <filename>~/.xsession-errors</filename> file to the problem report. It is defined in the <filename>/etc/libreport/events.d/ccpp_event.conf</filename> configuration file.
</para>
</listitem>
</varlistentry>
<varlistentry>
- <term>Report Uploader</term>
+ <term>
+ report_Logger — Logger
+ </term>
<listitem>
<para>
- — Uploads a tarball with crash data into a <systemitem class="protocol">FTP</systemitem>/<systemitem class="protocol">SCP</systemitem> server
+ Creates a problem report and saves it to a specified local file. It is defined in the <filename>/etc/libreport/events.d/print_event.conf</filename> configuration file.
</para>
</listitem>
</varlistentry>
<varlistentry>
- <term>Bugzilla</term>
+ <term>
+ report_RHTSupport — Red Hat Customer Support
+ </term>
<listitem>
<para>
- — Reports crashes into Bugzilla in the form of Bugzilla database entries.
+ Reports problems to the Red Hat Technical Support system. This possibility is intended for users of Red Hat Enterprise Linux. It is defined in the <filename>/etc/libreport/events.d/rhtsupport_event.conf</filename> configuration file.
</para>
- <!-- This does not seem to be relevant to Fedora.
- <note>
- <title>Do not use the Bugzilla plugin</title>
- <para>
- The use of the Bugzilla plugin to report crashes into Bugzilla in the form of Bugzilla database entries is strongly discouraged. Please use the RHTSupport plugin to report crashes into the Red Hat Ticketing System instead.
- </para>
- </note>
- -->
</listitem>
</varlistentry>
<varlistentry>
- <term>Logger</term>
+ <term>
+ report_Mailx — Mailx
+ </term>
<listitem>
<para>
- — Creates a crash report and saves it to a specified local file.
+ Sends a problem report via the <application>Mailx</application> utility to a specified email address. It is defined in the <filename>/etc/libreport/events.d/mailx_event.conf</filename> configuration file.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ report_Kerneloops — Kerneloops.org
+ </term>
+ <listitem>
+ <para>
+ Sends a kernel problem to the oops tracker. It is defined in the <filename>/etc/libreport/events.d/koops_event.conf</filename> configuration file.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ report_Uploader — Report uploader
+ </term>
+ <listitem>
+ <para>
+ Uploads a tarball (.tar.gz) archive with problem data to the chosen destination using the <systemitem
+ class="protocol">FTP</systemitem> or the <systemitem
+ class="protocol">SCP</systemitem> protocol. It is defined in the <filename>/etc/libreport/events.d/uploader_event.conf</filename> configuration file.
</para>
</listitem>
</varlistentry>
</variablelist>
</section>
- <section id="configuring-plugins-in-the-gui">
- <title>Plugin Configuration in the GUI</title>
+ <section
+ id="sect-abrt-configuration-event_configuration_in_gui">
+ <title>Event Configuration in ABRT GUI</title>
+ <para>
+ Events can use parameters passed to them as environment variables (for example, the <systemitem class="event">report_Logger</systemitem> event accepts an output file name as a parameter). Using the respective <filename>/etc/libreport/events/<replaceable><event_name></replaceable>.xml</filename> file, <application>ABRT</application> GUI determines which parameters can be specified for a selected event and allows a user to set the values for these parameters. These values are saved by <application>ABRT</application> GUI and reused on subsequent invocations of these events.
+ </para>
<para>
- You can override the system-wide plugin configuration in the <filename>/etc/abrt/plugins/*.conf</filename> configuration files on a per-user basis. Each of the plugins specified in section <xref linkend="reporter-plugins"/> can be configured in the <application>ABRT</application> GUI application. Open the plugins window by clicking <menuchoice><guimenu>Edit</guimenu><guisubmenu>Event configuration</guisubmenu></menuchoice>. This window shows a list of all installed plugins. <!-- You can also view each of the plugins' details by selecting one and expanding <guimenu>Plugin Details</guimenu>. --> When you select one of the configurable plugins, you can click the <guibutton>Configure Event</guibutton> button and you will be able to configure your desired plugin. If you change any of the plugins' parameters, they are saved in the GNOME Keyring and will be used in the future GUI sessions.
+ Open the <guilabel>Event Configuration</guilabel> window by clicking <menuchoice><guimenu>Edit</guimenu><guisubmenu>Preferences</guisubmenu></menuchoice>. This window shows a list of all available events that can be selected during the reporting process. When you select one of the configurable events, you can click the <guibutton>Configure Event</guibutton> button and you will be able to configure settings for that event. If you change any of the events' parameters, they are saved in the <application>Gnome</application> keyring and will be used in the future GUI sessions.
</para>
<note>
<title>Do not store sensitive data in global configuration files</title>
<para>
- All of the <filename>/etc/abrt/plugins/*.conf</filename> configuration files are world readable and are meant to be used as global settings. Thus, it is not advisable to store usernames, passwords or any other sensitive data in them. The per-user settings (set in the GUI application and readable by the owner of $HOME only) are stored in the Gnome keyring or can be stored in a text file in <filename>$HOME/.abrt/*.conf</filename> for use in <command>abrt-cli</command>.
+ All files in the <filename>/etc/libreport/</filename> directory hierarchy are world readable and are meant to be used as global settings. Thus, it is not advisable to store usernames, passwords or any other sensitive data in them. The per-user settings (set in the GUI application and readable by the owner of <varname>$HOME</varname> only) are stored in the <application>Gnome</application> keyring or can be stored in a text file in <filename>$HOME/.abrt/*.conf</filename> for use in <command>abrt-cli</command>.
</para>
</note>
- <figure id="mediaobj-abrt-plugins">
- <title>ABRT plugins</title>
+ <figure
+ id="fig-abrt-gui_event_configuration">
+ <title>The Event Configuration Window.</title>
<mediaobject>
<imageobject>
- <imagedata fileref="images/abrt-event-configuration.png" format="PNG" scalefit="0" />
+ <imagedata
+ fileref="images/abrt-gui_event_configuration.png"
+ format="PNG"
+ scalefit="0" />
</imageobject>
<textobject>
- <para>ABRT plugins</para>
+ <para>
+ The Event Configuration Window.
+ </para>
</textobject>
</mediaobject>
</figure>
<para>
- The following is a list of all configuration options available for each configurable plugin in the <application>ABRT</application> GUI application.
+ The following is a list of all configuration options available for each predefined event that is configurable in the <application>ABRT</application> GUI application.
</para>
<variablelist>
- <!-- jhradilek: This does not seem to be relevant to Fedora.
<varlistentry>
- <term>RHTSupport</term>
+ <term>
+ Logger
+ </term>
<listitem>
<para>
- In the <guilabel>RHTSupport plugin configuration</guilabel>, you can configure the following parameters:
+ In the <guilabel>Logger</guilabel> event configuration window, you can configure the following parameter:
</para>
<itemizedlist>
<listitem>
<para>
- <guilabel>RHTSupport URL</guilabel> — Specifies the RHTSupport URL where crash dumps are sent (by default, set to <ulink url="https://api.access.redhat.com/rs"/>).
+ <guilabel>Log file</guilabel> — Specifies a file into which the crash reports are saved (by default, set to <filename>/var/log/abrt.log</filename>).
</para>
</listitem>
+ </itemizedlist>
+ <para>
+ When the <guilabel>Append</guilabel> option is checked, the Logger event will append new crash reports to the log file specified in the <guilabel>Logger file</guilabel> option. When unchecked, the new crash report always replaces the previous one.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Red Hat Customer Support</term>
+ <listitem>
+ <para>
+ In the <guilabel>Red Hat Customer Support</guilabel> event configuration window, you can configure the following parameters:
+ </para>
+ <itemizedlist>
<listitem>
<para>
- <guilabel>Login</guilabel> — User login which is used to log into RHTSupport and create a RHTSupport database entry for a reported crash. Use your <emphasis>Red Hat Login</emphasis> acquired by creating an account on <ulink url="http://www.redhat.com/">http://www.redhat.com/</ulink>, the Red Hat Customer Portal (<ulink url="https://access.redhat.com/home">https://access.redhat.com/home</ulink>) or the Red Hat Network (<ulink url="https://rhn.redhat.com/">https://rhn.redhat.com/</ulink>).
+ <guilabel>RH Portal URL</guilabel> — Specifies the Red Hat Customer Support URL where crash dumps are sent (by default, set to <ulink
+ url="https://api.access.redhat.com/rs"/>).
</para>
</listitem>
<listitem>
<para>
- <guilabel>Password</guilabel> — Password used to log into RHTSupport (that is, password associated with your <emphasis>Red Hat Login</emphasis>)
+ <guilabel>Username</guilabel> — User login which is used to log into Red Hat Customer Support and create a Red Hat Customer Support database entry for a reported crash. Use your <emphasis>Red Hat Login</emphasis> acquired by creating an account on <ulink
+ url="http://www.redhat.com/">http://www.redhat.com/</ulink>, the Red Hat Customer Portal (<ulink
+ url="https://access.redhat.com/home">https://access.redhat.com/home</ulink>) or the Red Hat Network (<ulink
+ url="https://rhn.redhat.com/">https://rhn.redhat.com/</ulink>).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <guilabel>Password</guilabel> — Password used to log into Red Hat Customer Support (that is, password associated with your <emphasis>Red Hat Login</emphasis>)
</para>
</listitem>
</itemizedlist>
<para>
- When the <guilabel>SSL verify</guilabel> option is checked, the <systemitem class="protocol">SSL</systemitem> protocol is used when sending the data over the network.
+ When the <guilabel>SSL verify</guilabel> option is checked, the <systemitem
+ class="protocol">SSL</systemitem> protocol is used when sending the data over the network.
</para>
</listitem>
</varlistentry>
- -->
<varlistentry>
<term>MailX</term>
<listitem>
<para>
- In the <guilabel>MailX plugin configuration</guilabel>, you can configure the following parameters:
+ In the <guilabel>MailX</guilabel> event configuration window, you can configure the following parameters:
</para>
<itemizedlist>
<listitem>
<para>
- <guilabel>Subject</guilabel> — A string that appears in the <literal>Subject</literal> field of a crash report email sent by <application>mailx</application> (by default, set to <literal>"[abrt] crash report"</literal>).
+ <guilabel>Subject</guilabel> — A string that appears in the <literal>Subject</literal> field of a problem report email sent by <application>Mailx</application> (by default, set to <literal>"[abrt] detected a crash"</literal>).
</para>
</listitem>
<listitem>
<para>
- <guilabel>Your Email</guilabel> — A string that appears in the <literal>From</literal> field of a crash report email.
+ <guilabel>Sender</guilabel> — A string that appears in the <literal>From</literal> field of a problem report email.
</para>
</listitem>
<listitem>
<para>
- <guilabel>Recipient's Email</guilabel> — Email address of the recipient of a crash report email.
+ <guilabel>Recipient</guilabel> — Email address of the recipient of a problem report email.
</para>
</listitem>
</itemizedlist>
<para>
- When the <guilabel>Send Binary Data</guilabel> option is checked, the crash report email will also contain all binary files associated with the crash in an attachment. The core dump file is also sent as an attachment.
+ When the <guilabel>Send Binary Data</guilabel> option is checked, the problem report email will also contain all binary files associated with the problem in an attachment. The core dump file is also sent as an attachment.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Kerneloops.org</term>
+ <listitem>
+ <para>
+ In the <guilabel>Kerneloops.org</guilabel> event configuration window, you can configure the following parameter:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <guilabel>Kerneloops URL</guilabel> — Specifies the URL where Kernel problems are reported to (by default, set to <ulink
+ url="http://submit.kerneloops.org/submitoops.php"/>)
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Report Uploader</term>
+ <listitem>
+ <para>
+ In the <guilabel>Report Uploader</guilabel> event configuration widow, you can configure the following parameter:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <guilabel>URL</guilabel> — Specifies the URL where a tarball containing compressed problem data is uploaded using the <systemitem
+ class="protocol">FTP</systemitem> or <systemitem
+ class="protocol">SCP</systemitem> protocol (by default, set to <literal>ftp://localhost:/tmp/upload</literal>).
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </section>
+ <section
+ id="sect-abrt-configuration-abrt">
+ <title>ABRT Specific Configuration</title>
+ <para>
+ Standard <application>ABRT</application> installation currently provides the following <application>ABRT</application> specific configuration files:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <filename>/etc/abrt/abrt.conf</filename> — allows you to modify the behavior of the <systemitem
+ class="daemon">abrtd</systemitem> service.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>/etc/abrt/abrt-action-save-package-data.conf</filename> — allows you to modify the behavior of the <application>abrt-action-save-package-data</application> program.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>/etc/abrt/plugins/CCpp.conf</filename>, — allows you to modify the behavior of <application>ABRT</application>'s core catching hook.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ The following configuration directives are supported in the <filename>/etc/abrt/abrt.conf</filename> file:
+ </para>
+ <variablelist>
+ <varlistentry>
+ <term>
+ WatchCrashdumpArchiveDir = /var/spool/abrt-upload
+ </term>
+ <listitem>
+ <para>
+ This directive is commented out by default. Enable it if you want <systemitem
+ class="daemon">abrtd</systemitem> to auto-unpack crashdump tarball archives (.tar.gz) which are located in
+ the specified directory. In the example above, it is the <filename>/var/spool/abrt-upload/</filename>
+ directory. Whichever directory you specify in this directive, you must ensure that it exists and it is
+ writable for <systemitem class="daemon">abrtd</systemitem>. The <application>ABRT</application> daemon
+ will not create it automatically.
+ </para>
+ <warning>
+ <title>Do not modify this option in SELinux</title>
+ <para>
+ If you are using SELinux, do not modify the default setting of this option unless you reflect the change in SELinux rules. Changing the location for crashdump archives without previous modification of respective rules will cause SELinux denials. See the <systemitem>abrt_selinux (8)</systemitem> manual page for more information on running ABRT in SELinux.
+ </para>
+ </warning>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ MaxCrashReportsSize = <replaceable><size_in_megabytes></replaceable>
+ </term>
+ <listitem>
+ <para>
+ This option sets the amount of storage space, in megabytes, used by <application>ABRT</application> to store all problem information from all users. The default setting is <constant>1000</constant> MB. Once the quota specified here has been met, <application>ABRT</application> will continue catching problems, and in order to make room for the new crash dumps, it will delete the oldest and largest ones.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ DumpLocation = /var/spool/abrt
+ </term>
+ <listitem>
+ <para>
+ This directive is commented out by default. It specifies the location where problem data directories are created and in which problem core dumps and all other problem data are stored. The default location is set to the <filename>/var/spool/abrt</filename> directory. Whichever directory you specify in this directive, you must ensure that it exists and it is writable for <systemitem class="daemon">abrtd</systemitem>.
+ </para>
+ <warning>
+ <title>Do not modify this option in SELinux</title>
+ <para>
+ Do not modify the default setting of this option if you are using SELinux. Changing the dump location will cause SELinux denials unless you reflect the change in respective SELinux rules first. See the <systemitem>abrt_selinux (8)</systemitem> manual page for more information on running ABRT in SELinux.
+ </para>
+ </warning>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ <para>
+ The following configuration directives are supported in the <filename>/etc/abrt/abrt-action-save-package-data.conf</filename> file:
+ </para>
+ <variablelist>
+ <varlistentry>
+ <term>
+ OpenGPGCheck = <replaceable><yes/no></replaceable>
+ </term>
+ <listitem>
+ <para>
+ Setting the <computeroutput>OpenGPGCheck</computeroutput> directive to <userinput>yes</userinput> (the default setting) tells <application>ABRT</application> to <emphasis>only</emphasis> analyze and handle crashes in applications provided by packages which are signed by the GPG keys whose locations are listed in the <filename>/etc/abrt/gpg_keys</filename> file. Setting <parameter>OpenGPGCheck</parameter> to <userinput>no</userinput> tells <application>ABRT</application> to catch crashes in all programs.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ BlackList = nspluginwrapper, valgrind, strace, <optional><replaceable><MORE_PACKAGES></replaceable>
+ </optional>
+ </term>
+ <listitem>
+ <para>
+ Crashes in packages and binaries listed after the <parameter>BlackList</parameter> directive will not be handled by <application>ABRT</application>. If you want <application>ABRT</application> to ignore other packages and binaries, list them here separated by commas.
</para>
</listitem>
</varlistentry>
<varlistentry>
- <term>ReportUploader</term>
+ <term>
+ ProcessUnpackaged = <replaceable><yes/no></replaceable>
+ </term>
<listitem>
<para>
- In the <guilabel>ReportUploader plugin configuration</guilabel>, you can configure the following parameters:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <guilabel>Customer</guilabel> — Specifies customer's identification.
- </para>
- </listitem>
- <listitem>
- <para>
- <guilabel>Ticket</guilabel> — Specifies the Ticket ID number in a specific issue tracker that collects crash reports.
- </para>
- </listitem>
- <listitem>
- <para>
- <guilabel>URL</guilabel> — Specifies the URL of the issue tracker used to collect crash reports.
- </para>
- </listitem>
- <listitem>
- <para>
- <guilabel>Retry count</guilabel> — Specifies the number of retries should an upload fail.
- </para>
- </listitem>
- <listitem>
- <para>
- <guilabel>Retry delay</guilabel> — Specifies the number or seconds between two retries.
- </para>
- </listitem>
- </itemizedlist>
- <para>
- When the <guilabel>Use encryption</guilabel> option is checked, the crash report sent to the issue tracker is encrypted.
- </para>
- <para>
- When the <guilabel>Upload</guilabel> option is checked, all crash reports are uploaded to the specified issue tracker. If the option is unchecked, all crash reports are saved locally.
+ This directive tells <application>ABRT</application> whether to process crashes in executables that do not belong to any package. The default setting is <emphasis>no</emphasis>.
</para>
</listitem>
</varlistentry>
<varlistentry>
- <term>Bugzilla</term>
+ <term>
+ BlackListedPaths = <filename>/usr/share/doc/*</filename>, <filename>*/example*</filename>
+ </term>
<listitem>
<para>
- In the <guilabel>Bugzilla plugin configuration</guilabel>, you can configure the following parameters:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <guilabel>Bugzilla URL</guilabel> — Specifies the Bugzilla URL where crash dumps are sent (by default, set to <ulink url="https://bugzilla.redhat.com"/>).
- </para>
- </listitem>
- <listitem>
- <para>
- <guilabel>Login (email)</guilabel> — User login which is used to log into Bugzilla and create a Bugzilla database entry for a reported crash.
- </para>
- </listitem>
- <listitem>
- <para>
- <guilabel>Password</guilabel> — Password used to log into Bugzilla.
- </para>
- </listitem>
- </itemizedlist>
- <para>
- When the <guilabel>SSL verify</guilabel> option is checked, the <systemitem class="protocol">SSL</systemitem> protocol is used when sending the data over the network.
+ Crashes in executables in these paths will be ignored by <application>ABRT</application>.
</para>
</listitem>
</varlistentry>
+ </variablelist>
+ <para>
+ The following configuration directives are supported in the <filename>/etc/abrt/plugins/CCpp.conf</filename> file:
+ </para>
+ <variablelist>
<varlistentry>
- <term>Logger</term>
+ <term>
+ MakeCompatCore = <replaceable><yes/no></replaceable>
+ </term>
<listitem>
<para>
- In the <guilabel>Logger plugin configuration</guilabel>, you can configure the following parameter:
+ This directive specifies whether <application>ABRT</application>'s core catching hook should create a core file, as it could be done if <application>ABRT</application> would not be installed. The core file is typically created in the current directory of the crashed program but only if the <command>ulimit -c</command> setting allows it. The directive is set to <emphasis>yes</emphasis> by default.
</para>
- <itemizedlist>
- <listitem>
- <para>
- <guilabel>Logger file</guilabel> — Specifies a file into which the crash reports are saved (by default, set to <filename>/var/log/abrt.log</filename>).
- </para>
- </listitem>
- </itemizedlist>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ SaveBinaryImage = <replaceable><yes/no></replaceable>
+ </term>
+ <listitem>
<para>
- When the <guilabel>Append new logs</guilabel> option is checked, the Logger plugin will append new crash reports to the log file specified in the <guilabel>Logger file</guilabel> option. When unchecked, the new crash report always replaces the previous one.
+ This directive specifies whether <application>ABRT</application>'s core catching hook should save a binary image to a core dump. It is useful when debugging crashes which occurred in binaries that were deleted. The default setting is <emphasis>no</emphasis>.
</para>
</listitem>
</varlistentry>
</variablelist>
</section>
- </section>
- <section id="generating-backtrace">
- <title>Generating Backtraces</title>
- <para>
- In order to analyze a reported crash, developers need as much detail about the crash as possible. A <firstterm>stack backtrace</firstterm> is an important source of information when a crash in a binary program (caught by the <command>CCpp</command> analyzer plugin) occurs.
- </para>
- <para>
- <application>ABRT</application> is configured to generate a backtrace whenever a crash is reported through the <application>ABRT</application> GUI application or the <application>ABRT</application> command line interface.
- </para>
- <para>
- <application>ABRT</application> completes the following steps to generate a backtrace:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- It examines the core dump (which consists of the recorded contents of the memory of an application at a specific time), which is saved in the crash dump directory. From this file, <application>ABRT</application> extracts the information about the crashed binary program and information about every loaded dynamic library.
- </para>
- </listitem>
- <listitem>
- <para>
- It queries <application>Yum</application> to determine which <package>debuginfo</package> packages correspond to all the files extracted from the crash dump. This is the first potentially slow operation. <application>Yum</application> may need to refresh the <parameter>filelists</parameter> of various repositories in order to find the correct package names. This process may take a few minutes.
- </para>
- </listitem>
- <listitem>
- <para>
- It downloads the needed <package>debuginfo</package> packages, and extracts and saves the <command>debuginfo</command> files. In order to speed up future backtrace generation, <command>debuginfo</command> files are cached in the <filename>/var/cache/abrt-di</filename> directory.
- </para>
- </listitem>
- <listitem>
- <para>
- It generates a backtrace using <application>GDB</application> (the GNU Debugger) and saves it into the crash dump directory.
- </para>
- </listitem>
- </itemizedlist>
- <para>
- You can change the following backtrace generation parameters in the <filename>/etc/abrt/plugins/CCpp.conf</filename> file:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <command>Backtrace = <replaceable>yes/no</replaceable></command> — Enables/Disables backtrace generation.
- </para>
- </listitem>
- <listitem>
- <para>
- <command>BacktraceRemotes = <replaceable>yes/no</replaceable></command> — For more information about this parameter, refer to <xref linkend="configuring-centralized-crash-collection"/>.
- </para>
- </listitem>
- <listitem>
- <para>
- <command>InstallDebugInfo = <replaceable>yes/no</replaceable></command> — Enables/Disables the installation of <package>debuginfo</package> packages (useful if your network is not available or it is firewalled).
- </para>
- </listitem>
- <listitem>
- <para>
- <command>ReadonlyLocalDebugInfoDirs = /path1:/path2:...</command> — Specifies the paths of local repositories (available, for example, through a network mount) that contain pre-downloaded <package>debuginfo</package> packages.
- </para>
- </listitem>
- <listitem>
- <para>
- <command>DebugInfoCacheMB = <constant>4000</constant></command> — Specifies the maximum size of the cached <package>debuginfo</package> packages in the <filename>/var/cache/abrt-di</filename> directory.
- </para>
- </listitem>
- </itemizedlist>
- <section id="troubleshooting">
- <title>Troubleshooting Backtrace Generation</title>
- <para>
- In some cases, a long delay in the <application>ABRT</application> GUI application occurs after choosing a crash and pressing the <guibutton>Report</guibutton> button. In this case, open the <guibutton>Details</guibutton> in the <guilabel>Generating backtrace</guilabel> window and examine the messages.
- </para>
- <para>
- The following is a typical output seen in the <guilabel>Generating backtrace</guilabel> window:
- </para>
- <screen>Starting the debuginfo installation
-Getting list of build IDs
-12 missing debuginfos, getting package list from cache
-12 missing debuginfos, getting package list from repositories
-Downloading 7 packages
-Download 1/7: acl-debuginfo-2.2.49-6.fc13.x86_64
-Unpacking: acl-debuginfo-2.2.49-6.fc13.x86_64.rpm
-Caching debuginfo:
-usr/lib/debug/.build-id/3d/e20df1db609bd9313b1dc440796004f95911fd.debug
-Download 2/7: firefox-debuginfo-3.6.7-1.fc13.x86_64
-Unpacking: firefox-debuginfo-3.6.7-1.fc13.x86_64.rpm
-Caching debuginfo:
-usr/lib/debug/.build-id/3d/b29c9308cb276431ce8854a2d88cf83518afc6.debug
-Caching debuginfo:
-usr/lib/debug/.build-id/a3/86884285365c8288e4e761ec034fafaa1daee1.debug
-⋮
-Download 7/7: zlib-debuginfo-1.2.3-23.fc12.x86_64
-Unpacking: zlib-debuginfo-1.2.3-23.fc12.x86_64.rpm
-Caching debuginfo:
-usr/lib/debug/.build-id/f7/933750da80f555321576e72b375caf7a3cc075.debug
-All needed debuginfos are present
-Generating backtrace</screen>
- <para>
- This process is performed by the <application>/usr/bin/abrt-debuginfo-install</application> shell script. This script uses a temporary directory (e.g. <filename>/var/run/abrt/tmp-29177-1283344373</filename>) for its operations. Normally, this directory is removed when <application>abrt-debuginfo-install</application> exits.
- </para>
+ <section
+ id="sect-abrt-configuration-automatic_reporting">
+ <title>Configuring Automatic Reporting</title>
<para>
- If the <package>debuginfo</package> installation hangs, or is unable to download anything, you may debug the problem by editing the <application>abrt-debuginfo-install</application> script. Change the following parameters:
+ ABRT can be configured to report any detected issues or crashes automatically without any user interaction. This can be achieved by specifying an analyze-and-report rule as a <emphasis>post-create</emphasis> rule. For example, you can instruct ABRT to report Python crashes to Bugzilla immediately without any user interaction by enabling the rule and replacing the <command>EVENT=report_Bugzilla</command> condition with the <command>EVENT=port-create</command> condition in the <filename>/etc/libreport/events.d/python_event.conf</filename> file:
</para>
- <programlisting>debug=false
-keep_tmp=false</programlisting>
- <para>
- at the top of the script to:
- </para>
- <programlisting>debug=true
-keep_tmp=true</programlisting>
- <para>
- The first parameter instructs <application>abrt-debuginfo-install</application> to be verbose, the second parameter instructs <application>abrt-debuginfo-install</application> to not delete the <filename>/var/run/abrt/tmp-NNN-NNN</filename> directory. You can examine the log files in this directory, they may contain useful error messages.
- </para>
- <para>
- <application>abrt-debuginfo-install</application> uses <application>yum</application> and <application>yumdownloader</application> to handle the <package>debuginfo</package> packages. In order to quickly check that your <application>yum</application> configuration does not cause any problems which prevent <application>abrt-debuginfo-install</application> from working properly, change to the <filename>/tmp</filename> directory and run the following commands, as <systemitem class="username">root</systemitem>:
- </para>
- <screen>tmp]# <command>yum --enablerepo=*debuginfo* --quiet provides /usr/bin/true</command>
-tmp]# <command>yumdownloader --enablerepo=*debuginfo* --quiet coreutils</command></screen>
+ <screen>EVENT=post-create analyzer=Python
+ test -f component || abrt-action-save-package-data
+ reporter-bugzilla -c /etc/abrt/plugins/Bugzilla.conf</screen>
+ <warning>
+ <title><systemitem class="event">post-create</systemitem> runs with root privileges</title>
<para>
- Both of these commands should complete successfully, with no error messages. The second command should download the <filename>coreutils-*.rpm</filename> file. If any error messages appear, check your <application>yum</application> configuration files in the <filename>/etc/yum.repos.d/*</filename> directory and the <filename>/etc/yum/*</filename> directory. If any of these commands hang, check that you do not have another instance of <application>yum</application> running, and that your network connection is working properly.
+ Please note that the <systemitem class="event">post-create</systemitem> event is run by <systemitem
+ class="daemon">abrtd</systemitem>, which usually runs with root privileges.
</para>
+ </warning>
</section>
- </section>
- <section>
- <title>Using the Command Line Interface</title>
- <para>Crashes detected by <application>ABRT</application> can be viewed, reported, and deleted using the command line interface.</para>
- <section>
- <title>Viewing Crashes</title>
- <para>To get a list of all crashes, simply enter <command>abrt-cli --list</command> or <command>abrt-cli -l</command>:</para>
- <screen>~]$ <command>abrt-cli --list</command>
-0.
- UID : 500
- UUID : 784b06666020e9f43718d99bf2649f19b4f251a9
- Package : bash-4.1.2-3.el6
- Executable : /bin/bash
- Crash Time : Tue 20 Jul 2010 03:22:52 PM CEST
- Crash Count: 2
-1.
- UID : 500
- UUID : 48007b98d65cca4530d99a564379e2609169239d
- Package : coreutils-8.4-9.el6
- Executable : /bin/sleep
- Crash Time : Tue 20 Jul 2010 03:22:00 PM CEST
- Crash Count: 1</screen>
- <para>This output contains basic information for every crash. The <computeroutput>UID:</computeroutput> field shows the ID of the user which ran the program that caused the crash. The <computeroutput>Package</computeroutput> field shows the name and version of the &MAJOROS; package that contains the program, and the <computeroutput>Executable</computeroutput> field shows the location of the binary or script that crashed. The <computeroutput>Crash Count</computeroutput> field indicates how many times the same crash happened.</para>
- </section>
- <section>
- <title>Reporting Crashes</title>
- <para>To report a certain crash, enter <command>abrt-cli --report <replaceable>UUID</replaceable></command> or <command>abrt-cli --r <replaceable>UUID</replaceable></command>, where <varname>UUID</varname> is a Universally Unique Identifier of a crash from the list of crashes; to view this list, execute the <command>abrt-cli --list</command> command. You do not need to remember the exact <varname>UUID</varname>; either use a mouse to copy and paste it, or enter a unique prefix and press <keycap function="enter">ENTER</keycap>.</para>
- <screen>~]$ <command>abrt-cli --report 480</command>
-<keycap function="enter"><ENTER></keycap>
->> Starting report creation...</screen>
- <para>
- <application>ABRT</application> analyzes the crash and creates a report about it. This might take a while. When the report is ready, <command>abrt-cli</command> opens a text editor with the content of the report. You can see what is being reported, and you can fill in instructions on how to reproduce the crash and other comments. You should also check the backtrace, because the backtrace might be sent to a public server and viewed by anyone, depending on the plugin settings.</para>
- <note>
- <title>Selecting a preferred text editor</title>
- <para>You can choose which text editor is used to check the reports. <command>abrt-cli</command> uses the editor defined in the <envar>ABRT_EDITOR</envar> environment variable. If the variable is not defined, it checks the <envar>VISUAL</envar> and <envar>EDITOR</envar> variables. If none of these variables is set, <command>vi</command> is used. You can set the preferred editor in your <filename>.bashrc</filename> configuration file. For example, if you prefer GNU Emacs, add the following line to the file:</para>
- <programlisting>export <varname>VISUAL</varname>=<userinput>emacs</userinput></programlisting>
- </note>
- <para>When you are done with the report, save your changes and close the editor. You will be asked which of the enabled <application>ABRT</application> plugins you want to use to send the report. Respond <keycap>Y</keycap> to send the report using your desired plugin or <keycap>N</keycap> to skip a plugin you wish not to use.</para>
- </section>
- <section>
- <title>Deleting Crashes</title>
- <para>If you know that you do not want to report a certain crash dump, you can delete it from the crash list. To delete a certain crash dump, enter the command: <command>abrt-cli --delete <replaceable>UUID</replaceable>
- </command>.
+ <section
+ id="sect-abrt-configuration-proxy_servers">
+ <title>Uploading and reporting using a proxy server</title>
+ <para>
+ The <application>reporter-bugzilla</application> and the <application>reporter-upload</application> tools respect the <envar>http_proxy</envar> and the <envar>ftp_proxy</envar> environment variables. When you use environment variables as a part of a reporting event, they inherit their values from the process which performs reporting, usually <application>abrt-gui</application> or <application>abrt-cli</application>. Therefore, you can specify <systemitem class="protocol">HTTP</systemitem> or <systemitem class="protocol">FTP</systemitem> proxy servers by using these variables in your working environment.
</para>
<para>
- Note that <application>ABRT</application> performs a detection of duplicate crashes by comparing new crashes with all locally saved crashes. For a repeating crash, <application>ABRT</application> requires you to act upon it only once. However, if you delete the crash dump of that crash, the next time this specific crash occurs, <application>ABRT</application> will treat it as a new crash: <application>ABRT</application> will alert you about it, prompt you to fill in a description, and report it. This can be redundant, therefore, deleting a crash is not advisable.
+ If you arrange these tools to be a part of the <systemitem
+ class="event">post-create</systemitem> event, they will run as children of the <systemitem
+ class="daemon">abrtd</systemitem> process. You should either adjust the environment of abrtd or modify the rules to set these variables. For example:
</para>
+ <screen>EVENT=post-create analyzer=Python
+ test -f component || abrt-action-save-package-data
+ export http_proxy=http://proxy.server:8888/
+ reporter-bugzilla -c /etc/abrt/plugins/Bugzilla.conf</screen>
</section>
</section>
- <section id="configuring">
- <title>Configuring ABRT</title>
+ <section
+ id="sect-abrt-centralized_crash_collection">
+ <title>Configuring Centralized Crash Collection</title>
<para>
- <application>ABRT</application>'s main configuration file is <filename>/etc/abrt/abrt.conf</filename>. <application>ABRT</application> plugins can be configured through their configuration files, located in the <filename>/etc/abrt/plugins/</filename> directory.</para>
- <important>
- <title>Restart the abrtd daemon to apply the changes</title>
- <para>After changing and saving the <filename>/etc/abrt/abrt.conf</filename> configuration file, you must restart the <systemitem class="daemon">abrtd</systemitem> daemon—as <systemitem class="username">root</systemitem>—for the new settings to take effect:</para>
- <screen><command>systemctl restart abrtd.service</command></screen>
- </important>
- <para>The following configuration directives are currently supported in <filename>/etc/abrt/abrt.conf</filename>.</para>
- <variablelist>
- <title>[ Common ] Section Directives</title>
- <varlistentry>
- <term>OpenGPGCheck = <replaceable>yes/no</replaceable>
- </term>
- <listitem>
- <para>Setting the <computeroutput>OpenGPGCheck</computeroutput> directive to <userinput>yes</userinput> (the default setting) tells <application>ABRT</application> to <emphasis>only</emphasis> analyze and handle crashes in applications provided by packages which are signed by the GPG keys whose locations are listed in the <filename>/etc/abrt/gpg_keys</filename> file. Setting <parameter>OpenGPGCheck</parameter> to <userinput>no</userinput> tells <application>ABRT</application> to catch crashes in all programs.</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>BlackList = nspluginwrapper, valgrind, strace, avant-window-navigator, <optional><replaceable>additional_packages</replaceable>
- </optional>
- </term>
- <listitem>
- <para>Crashes in packages and binaries listed after the <parameter>BlackList</parameter> directive will not be handled by <application>ABRT</application>. If you want <application>ABRT</application> to ignore other packages and binaries, list them here separated by commas.</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>ProcessUnpackaged = <replaceable>yes/no</replaceable>
- </term>
+ You can set up <application>ABRT</application> so that crash reports are collected from multiple systems and sent to a dedicated system for further processing. This is useful when an administrator does not want to log into hundreds of systems and manually check for crashes found by <application>ABRT</application>. In order to use this method, you need to install the <application>libreport-plugin-reportuploader</application> plug-in (<command>yum install libreport-plugin-reportuploader</command>). See the following sections on how to configure systems to use ABRT's centralized crash collection.
+ </para>
+ <section
+ id="sect-abrt-centralized_crash_collection-server">
+ <title>Configuration Steps Required on a Dedicated System</title>
+ <para>
+ Complete the following steps on a dedicated (server) system:
+ </para>
+ <orderedlist>
<listitem>
<para>
- This directive tells <application>ABRT</application> whether to process crashes in executables that do not belong to any package.
+ Create a directory to which you want the crash reports to be uploaded to. Usually, <filename>/var/spool/abrt-upload/</filename> is used (the rest of the document assumes you are using this directory). Make sure this directory is writable by the abrt user.
</para>
+ <note>
+ <title>The abrt user and group</title>
+ <para>
+ When the <package>abrt-desktop</package> package is installed, it creates a new system user and a group, both named <systemitem
+ class="username">abrt</systemitem>. This user is used by the <systemitem
+ class="daemon">abrtd</systemitem> daemon, for example, as the owner:group of <filename>/var/spool/abrt/*</filename> directories.
+ </para>
+ </note>
</listitem>
- </varlistentry>
- <varlistentry>
- <term>BlackListedPaths = <filename>/usr/share/doc/*</filename>, <filename>*/example*</filename>
- </term>
<listitem>
<para>
- Crashes in executables in these paths will be ignored by <application>ABRT</application>.
+ In the <filename>/etc/abrt/abrt.conf</filename> configuration file, set the <varname>WatchCrashdumpArchiveDir</varname> directive to the following:
</para>
+ <screen>WatchCrashdumpArchiveDir = /var/spool/abrt-upload/</screen>
</listitem>
- </varlistentry>
- <varlistentry>
- <term>Database = SQLite3</term>
- <listitem>
- <para>This directive instructs <application>ABRT</application> to store its crash data in the <application>SQLite3</application> database. Other databases are not currently supported. However, <application>ABRT</application>'s plugin architecture allows for future support for alternative databases.</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>#WatchCrashdumpArchiveDir = /var/spool/abrt-upload/</term>
<listitem>
<para>
- This directive is commented out by default. Enable (uncomment) it if you want <systemitem class="daemon">abrtd</systemitem> to auto-unpack crashdump tarballs which appear in the specified directory — in this case <filename>/var/spool/abrt-upload/</filename> — (for example, uploaded via <systemitem class="service">ftp</systemitem>, <systemitem class="service">scp</systemitem>, etc.). You must ensure that whatever directory you specify in this directive exists and is writable for <systemitem class="daemon">abrtd</systemitem>. <systemitem class="daemon">abrtd</systemitem> will not create it automatically.
+ Choose your preferred upload mechanism; for example, <systemitem
+ class="protocol">FTP</systemitem> or <systemitem
+ class="protocol">SCP</systemitem>. For more information on how to configure <systemitem
+ class="protocol">FTP</systemitem>, refer to <xref
+ linkend="s1-FTP"/>. For more information on how to configure <systemitem
+ class="protocol">SCP</systemitem>, refer to <xref
+ linkend="s2-ssh-clients-scp"/>.
+ </para>
+ <para>
+ It is advisable to check whether your upload method works. For example, if you use <systemitem
+ class="protocol">FTP</systemitem>, upload a file using an interactive <systemitem
+ class="protocol">FTP</systemitem> client:
+ </para>
+ <screen>
+~]$ <command>ftp</command>
+ftp> open SERVERNAME
+Name: USERNAME
+Password: PASSWORD
+ftp> <command>cd /var/spool/abrt-upload</command>
+250 Operation successful
+ftp> <command>put TESTFILE</command>
+ftp> <command>quit</command></screen>
+ <para>
+ Check whether <filename>TESTFILE</filename> appeared in the correct directory on the server system.
</para>
</listitem>
- </varlistentry>
- <varlistentry>
- <term>MaxCrashReportsSize = <replaceable>size_in_megabytes</replaceable>
- </term>
<listitem>
- <para>This option sets the amount of storage space, in megabytes, used by <application>ABRT</application> to store all crash information from all users. The default setting is <constant>1000</constant> MB. Once the quota specified here has been met, <application>ABRT</application> will continue catching crashes, and in order to make room for the new crash dumps, it will delete the oldest and largest ones.</para>
+ <para>
+ The <varname>MaxCrashReportsSize</varname> directive (in the <filename>/etc/abrt/abrt.conf</filename> configuration file) needs to be set to a larger value if the expected volume of crash data is larger than the default <constant>1000</constant> MB.
+ </para>
</listitem>
- </varlistentry>
- <varlistentry>
- <term>ActionsAndReporters = SOSreport, <optional><replaceable>additional_plugins</replaceable>
- </optional>
- </term>
<listitem>
- <para>This option tells <application>ABRT</application> to run the specified plugin(s) immediately after a crash is detected and saved. For example, the <userinput>SOSreport</userinput> plugin runs the <systemitem>sosreport</systemitem> tool which adds the data collected by it to the created crash dump. You can turn this behavior off by commenting out this line. For further fine-tuning, you can add <userinput>SOSreport</userinput> (or any other specified plugin) to either the <parameter>CCpp</parameter> or <parameter>Python</parameter> options to make <application>ABRT</application> run <command>sosreport</command> (or any other specified plugin) after any C and C++ or Python applications crash, respectively. For more information on various Action and Reporter plugins, refer to <xref linkend="abrt-plugins"/>
+ <para>
+ Consider whether you would like to generate a backtrace of C/C++ crashes.
+ </para>
+ <para>
+ You can disable backtrace generation on the server if you do not wish to generate backtraces at all, or if you decide to create them locally on the machine where a problem occurred. In the standard ABRT installation, a backtrace of a C/C++ crash is generated using the following rule in the <filename>/etc/libreport/events.d/ccpp_events.conf</filename> configuration file:
+ </para>
+ <screen>
+EVENT=analyze_LocalGDB analyzer=CCpp
+ abrt-action-analyze-core.py --core=coredump -o build_ids &&
+ abrt-action-install-debuginfo-to-abrt-cache --size_mb=4096 &&
+ abrt-action-generate-backtrace &&
+ abrt-action-analyze-backtrace</screen>
+ <para>
+ You can ensure that this rule is not applied for uploaded problem data by adding the <computeroutput>remote!=1</computeroutput> condition to the rule.
</para>
</listitem>
- </varlistentry>
- </variablelist>
- <variablelist>
- <title>[ AnalyzerActionsAndReporters ] Section Directives</title>
- <para>This section allows you to associate certain analyzer actions and reporter actions to run when <application>ABRT</application> catches kernel oopses or crashes in C, C++ or Python programs. The actions and reporters specified in any of the directives below will run only if you run <command>abrt-gui</command> or <command>abrt-cli</command> and report the crash that occurred. If you do not specify any actions and reporters in these directives, you will not be able to report a crash via <command>abrt-gui</command> or <command>abrt-cli</command>. The order of actions and reporters is important. Commenting out a directive, will cause <application>ABRT</application> not to catch the crashes associated with that directive. For example, commenting out the Kerneloops line will cause <application>ABRT</application> not to catch kernel oopses.</para>
- <varlistentry>
- <term>Kerneloops = <!--RHTSupport, -->Logger</term>
<listitem>
- <para>This directive specifies that, for kernel oopses, <!--both -->the <!--RHTSupport and -->Logger reporter<!--s--> will be run.</para>
+ <para>
+ Decide whether you want to collect package information (the <option>package</option> and the <option>component</option> elements) in the problem data. Refer to <xref
+ linkend="sect-abrt-centralized_crash_collection-saving_package_information"/> to find out whether you need to collect package information in your centralized crash collection configuration and how to configure it properly.
+ </para>
</listitem>
- </varlistentry>
- <varlistentry>
- <term>CCpp = <!--RHTSupport, -->Logger</term>
+ </orderedlist>
+ </section>
+ <section
+ id="sect-abrt-centralized_crash_collection-client">
+ <title>Configuration Steps Required on a Client System</title>
+ <para>
+ Complete the following steps on every client system which will use the central management method:
+ </para>
+ <orderedlist>
<listitem>
- <para>This directive specifies that, when C or C++ program crashes occur, <!--both -->the <!--RHTSupport and -->Logger reporter<!--s--> will be run.</para>
+ <para>
+ If you do not wish to generate a backtrace, or if you decided to generate it on a server system, you need to delete or comment out the corresponding rules in the <filename>/etc/libreport/events.d/ccpp_events.conf</filename> file. Refer to <xref
+ linkend="sect-abrt-centralized_crash_collection-server"/> for an example of such a example.
+ </para>
</listitem>
- </varlistentry>
- <varlistentry>
- <term>Python = <!--RHTSupport, -->Logger</term>
<listitem>
- <para>This directive specifies that, when Python program crashes occur, <!--both -->the <!--RHTSupport and -->Logger reporter<!--s--> will be run.</para>
+ <para>
+ If you decided to not collect package information on client machines, delete, comment out or modify the rule which runs abrt-action-save-package-data in the <filename>/etc/libreport/events.d/abrt_event.conf</filename> file. Refer to <xref
+ linkend="sect-abrt-centralized_crash_collection-saving_package_information"/> to find out whether you need to collect package information in your centralized crash collection configuration and how to configure it properly.
+ </para>
</listitem>
- </varlistentry>
- </variablelist>
- <para>
- Each of these destinations' details can be specified in the corresponding <filename>plugins/*.conf</filename> file. <!--For example, <filename>plugins/RHTSupport.conf</filename> specifies which RHTSupport URL to use (set to <ulink url="https://api.access.redhat.com/rs"/> by default), the user's login name, password for logging in to the RHTSupport site, etc. -->All these options can also be configured through the <command>abrt-gui</command> application (for more information on plugin configuration refer to <xref linkend="abrt-plugins"/>).
- </para>
- <variablelist>
- <title>[ Cron ] Section Directives</title>
- <varlistentry>
- <term>
- <replaceable>time</replaceable> = <replaceable>action_to_run</replaceable>
- </term>
<listitem>
- <para>The <computeroutput>[ Cron ]</computeroutput> section of <filename>abrt.conf</filename> allows you to specify the exact time, or elapsed amount of time between, when <application>ABRT</application> should run a certain action, such as scanning for kernel oopses or performing file transfers. You can list further actions to run by appending them to the end of this section.</para>
- <example id="ex-_Cron__section_of__etc_abrt_abrt.conf">
- <title>[ Cron ] section of /etc/abrt/abrt.conf</title>
- <programlisting># Which Action plugins to run repeatedly
-[ Cron ]
-# h:m - at h:m
-# s - every s seconds
-120 = KerneloopsScanner
-#02:00 = FileTransfer</programlisting>
- </example>
- <para>The format for an entry is either <userinput>time_in_seconds = <replaceable>action_to_run</replaceable>
- </userinput> or <userinput>hh:mm = action_to_run </userinput>, where <userinput>hh</userinput> (hour) is in the range <constant>00-23</constant> (all hours less than 10 should be zero-filled, i.e. preceded by a <constant>0</constant>), and <userinput>mm</userinput> (minute) is <constant>00-59</constant>, zero-filled likewise.</para>
- </listitem>
- </varlistentry>
- </variablelist>
- </section>
- <section id="configuring-centralized-crash-collection">
- <title>Configuring Centralized Crash Collection</title>
- <para>
- You can set up <application>ABRT</application> so that crash reports are collected from multiple systems and sent to a dedicated system for further processing. This is useful when an administrator does not want to log into hundreds of systems and manually check for crashes found by <application>ABRT</application>. In order to use this method, you need to install the <application>abrt-plugin-reportuploader</application> plugin (<command>yum install abrt-plugin-reportuploader</command>).
- </para>
- <para>
- The steps to configure <application>ABRT</application>'s centralized crash collection are:
- </para>
- <orderedlist>
- <listitem>
- <para>Complete the following steps on a dedicated system ("server system"):</para>
- <itemizedlist>
- <listitem>
- <para>
- Create a directory to which you want the crash reports to be uploaded to. Usually, <filename>/var/spool/abrt-upload/</filename> is used (the rest of the document assumes you are using <filename>/var/spool/abrt-upload/</filename>). Make sure this directory is writable by the <systemitem class="username">abrt</systemitem> user.
- </para>
- <note>
- <title>The abrt user and group</title>
- <para>
- When the <package>abrt-desktop</package> package is installed, it creates a new system user and a group, both named <systemitem class="username">abrt</systemitem>. This user is used by the <systemitem class="daemon">abrtd</systemitem> daemon for various things, for example, as the owner:group of <filename>/var/spool/abrt/*</filename> directories.
- </para>
- </note>
- </listitem>
- <listitem>
- <para>
- In the <filename>/etc/abrt/abrt.conf</filename> configuration file, set the <varname>WatchCrashdumpArchiveDir</varname> directive to the following:
-<programlisting>WatchCrashdumpArchiveDir = /var/spool/abrt-upload/</programlisting>
- </para>
- </listitem>
- <listitem>
- <para>
- Determine your preferred upload mechanism; for example, <systemitem class="protocol">FTP</systemitem> or <systemitem class="protocol">SCP</systemitem>. For more information on how to configure <systemitem class="protocol">FTP</systemitem>, refer to <xref linkend="s1-FTP" />. For more information on how to configure <systemitem class="protocol">SCP</systemitem>, refer to <xref linkend="s2-ssh-clients-scp"/>.
- </para>
- <para>
- For security reasons, make sure that uploads can only be performed by a specific user and with a password. The rest of the document assumes that the username used for uploads is <systemitem class="username">USERNAME</systemitem> and the password is <literal>PASSWORD</literal>. If you do not already have a suitable username which can be used to perform uploads under, you may use the <systemitem class="username">abrt</systemitem> user which already exists on every system where <application>ABRT</application> is installed.
+ <para>
+ Add a rule for uploading problem reports to the server system in the corresponding configuration file. For example, if you want to upload all problems automatically as soon as they are detected, you can use the following rule in the <filename>/etc/libreport/events.d/abrt_event.conf</filename> configuration file:
</para>
+ <screen>
+EVENT=post-create
+ reporter-upload -u scp://<replaceable>user</replaceable>:<replaceable>password</replaceable>@<replaceable>server</replaceable>.<replaceable>name</replaceable>
+ <replaceable>/directory</replaceable></screen>
<para>
- It is advisable to check whether your upload method works. For more information, refer to <xref linkend="testing-upload-method"/>.
+ Alternatively, you can use a similar rule that runs the reporter-upload program as the <systemitem class="event">report_<replaceable>SFX</replaceable></systemitem> event if you want to store problem data locally on clients and upload it later using ABRT GUI/CLI. The following is an example of such an event:
</para>
- </listitem>
+ <screen>
+EVENT=report_UploadToMyServer
+ reporter-upload -u scp://<replaceable>user</replaceable>:<replaceable>password</replaceable>@<replaceable>server</replaceable>.<replaceable>name</replaceable>
+ <replaceable>/directory</replaceable></screen>
+ </listitem>
+ </orderedlist>
+ </section>
+ <section
+ id="sect-abrt-centralized_crash_collection-saving_package_information">
+ <title>Saving Package Information</title>
+ <para>
+ In a single-machine <application>ABRT</application> installation, problems are usually reported to external bug databases such as RHTSupport or Bugzilla. Reporting to these bug databases usually requires knowledge about the component and package in which the problem occurred. The <systemitem class="event">post-create</systemitem> event runs the <application>abrt-action-save-package-data</application> tool (among other steps) in order to provide this information in the standard <application>ABRT</application> installation.
+ </para>
+ <para>
+ If you are setting up a centralized crash collection system, your requirements may be significantly different. Depending on your needs, you have two options:
+ </para>
+ <variablelist>
+ <varlistentry>
+ <term>Internal analysis of problems</term>
<listitem>
<para>
- It is advisable to check and modify the following parameters if needed:
+ After collecting problem data, you do not need to collect package information if you plan to analyze problems in-house, without reporting them to any external bug databases. You might be also interested in collecting crashes that occur in programs written by your organization. Such programs do not belong to any package in the first place. In this case take the following steps on both, <emphasis>client systems</emphasis> and a <emphasis>dedicated crash collecting system</emphasis>:
</para>
<itemizedlist>
<listitem>
<para>
- The <parameter>MaxCrashReportsSize</parameter> directive (in <filename>/etc/abrt/abrt.conf</filename>) needs to be set to a larger value if the expected volume of crash data is larger than the default <constant>1000</constant> MB.
- </para>
+ Remove the following rule from the <filename>/etc/libreport/events.d/abrt_event.conf</filename> file:
+ </para>
+ <screen>EVENT=post-create component=
+ abrt-action-save-package-data</screen>
</listitem>
<listitem>
<para>
- The <parameter>ProcessUnpackaged</parameter> directive (in <filename>/etc/abrt/abrt.conf</filename>) needs to be set to <replaceable>yes</replaceable> and the <parameter>BacktraceRemotes</parameter> (in <filename>/etc/abrt/plugins/CCpp.conf</filename>) needs to be set to <replaceable>no</replaceable> if the client system and the server system have significantly different sets of installed packages.
- </para>
+ Prevent deletion of problem data directories which do not correspond to any installed package by setting the following directive in the <filename>/etc/abrt/abrt-action-save-package-data.conf</filename> file:
+ </para>
+ <screen>ProcessUnpackaged = yes</screen>
</listitem>
</itemizedlist>
</listitem>
- </itemizedlist>
- </listitem>
- <listitem>
- <para>Complete the following steps on every client system which will use the central management method:</para>
- <itemizedlist>
- <listitem>
- <para>
- Modify the <filename>/etc/abrt/plugins/ReportUploader.conf</filename> configuration file so that the <application>ReportUploader</application> plugin knows where to copy the saved crash reports in the following way:
-<programlisting>Enabled = yes
-Upload = yes
-URL = ftp://USERNAME:PASSWORD@SERVERNAME/var/spool/abrt-upload/</programlisting>
- </para>
- </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Reporting to external bug database</term>
<listitem>
<para>
- To automatically send the crash reports to the server system immediately after the crash occurs, is detected, and saved, set the <varname>[ ActionsAndReporters ]</varname> directive in the <filename>/etc/abrt/abrt.conf</filename> configuration file to the following:
-<programlisting>ActionsAndReporters = ReportUploader</programlisting>
+ Alternatively, you may want to report crashes to RHTSupport or Bugzilla. In this case, you need to collect package information. Generally, client machines and dedicated crash collecting systems have non-identical sets of installed packages. Therefore, it may happen that problem data uploaded from a client does not correspond to any package installed on the dedicated crash collecting system. In the standard <application>ABRT</application> configuration, this will lead to deletion of problem data (ABRT will consider it to be a crash in an unpackaged executable). To prevent this from happening, it is necessary to modify <application>ABRT</application>'s configuration on the <emphasis>dedicated system</emphasis> in the following way:
</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Prevent inadvertent collection of package information for problem data uploaded from client machines, by adding the <code>remote!=1</code> condition in the <filename>/etc/libreport/events.d/abrt_event.conf</filename> file:
+ <screen>EVENT=post-create remote!=1 component=
+ abrt-action-save-package-data</screen>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Prevent deletion of problem data directories which do not correspond to any installed package by setting the following directive in <filename>/etc/abrt/abrt-action-save-package-data.conf</filename>:
+ </para>
+ <screen>ProcessUnpackaged = yes</screen>
+ </listitem>
+ </itemizedlist>
+ <note>
+ <para>
+ Note that in this case, no such modifications are necessary on client systems: they continue to collect package information, and continue to ignore crashes in unpackaged executables.
+ </para>
+ </note>
</listitem>
- <listitem>
- <para>
- Alternatively, if user interaction is required before the crash dump is sent to the server system, set the <parameter>ReportUploader</parameter> to be a reporter plugin for a specific crash type in the <literal>[ AnalyzerActionsAndReporters ]</literal> section of the <filename>/etc/abrt/abrt.conf</filename> configuration file. The user will be required to run <application>abrt-cli</application> or <application>abrt-gui</application> and instruct the <systemitem class="daemon">abrtd</systemitem> daemon to report the crash and send it to the server system. For example, if you want all crash types to use this method, edit the <literal>[ AnalyzerActionsAndReporters ]</literal> section in your <filename>/etc/abrt/abrt.conf</filename> configuration file in the following way:
- </para>
- <programlisting>Kerneloops = ReportUploader
-CCpp = ReportUploader
-Python = ReportUploader</programlisting>
- </listitem>
- </itemizedlist>
- </listitem>
- </orderedlist>
- <section>
- <title>Testing ABRT's Crash Detection</title>
- <para>
+ </varlistentry>
+ </variablelist>
+ </section>
+ <section
+ id="sect-abrt-crash_detection_test">
+ <title>Testing ABRT's Crash Detection</title>
+ <para>
After completing all the steps of the configuration process, the basic setup is finished. To test that this setup works properly use the <command>kill -s SEGV <replaceable>PID</replaceable>
- </command> command to terminate a process on a client system. For example, start a <systemitem class="process">sleep</systemitem> process and terminate it with the <command>kill</command> command in the following way:
- <screen>~]$ <command>sleep 100 &</command>
+ </command> command to terminate a process on a client system. For example, start a <systemitem
+ class="process">sleep</systemitem> process and terminate it with the <command>kill</command> command in the following way:
+ </para>
+ <screen>
+~]$ sleep 100 &
[1] 2823
-~]$ <command>kill -s SEGV 2823</command></screen>
- <application>ABRT</application> should detect a crash shortly after executing the <command>kill</command> command. Check that the crash was detected by <application>ABRT</application> on the client system (this can be checked by examining the appropriate syslog file, by running the <command>abrt-cli --list --full</command> command, or by examining the crash dump created in the <filename>/var/spool/abrt</filename> directory), copied to the server system, unpacked on the server system and can be seen and acted upon using <command>abrt-cli</command> or <command>abrt-gui</command> on the server system.
- </para></section>
- <section id="testing-upload-method">
- <title>Testing the Upload Method</title>
- <para>
- Test your upload method from a client system to ensure that it works. For example, upload a file using the interactive <systemitem class="protocol">FTP</systemitem> client:
- </para>
- <screen>~]$ <command>ftp</command>
-ftp> open SERVERNAME
-Name: USERNAME
-Password: PASSWORD
-ftp> cd /var/spool/abrt-upload
-250 Operation successful
-ftp> put TESTFILE
-ftp> quit</screen>
+~]$ kill -s SEGV 2823</screen>
<para>
- Check whether <filename>TESTFILE</filename> appeared in the correct directory on the server system.
- </para>
+ <application>ABRT</application> should detect a crash shortly after executing the <command>kill</command> command. Check that the crash was detected by <application>ABRT</application> on the client system (this can be checked by examining the appropriate syslog file, by running the <command>abrt-cli list --full</command> command, or by examining the crash dump created in the <filename>/var/spool/abrt</filename> directory), copied to the server system, unpacked on the server system and can be seen and acted upon using <command>abrt-cli</command> or <command>abrt-gui</command> on the server system.
+ </para>
</section>
</section>
- <section id="configuring-automatic-reporting">
- <title>Configuring Automatic Reporting</title>
+ <!--<section id="sect-migration_to_abrt2">
+ <title>Migrating ABRT 1.x to ABRT 2.x</title>
<para>
- <application>ABRT</application> can be configured to automatically report any detected issues or crashes. The following steps show how to enable this feature:
+ TBD
</para>
- <orderedlist>
- <listitem>
- <para>
- In your <filename>/etc/abrt/abrt.conf</filename> configuration file, for each analyzer, change the list of reporters according to your needs, for example:
- </para>
- <programlisting>[ AnalyzerActionsAndReporters ]
-Kerneloops = Logger
-CCpp = Logger
-Python = Logger</programlisting>
- </listitem>
- <listitem>
- <para>
- In the configuration files corresponding to each analyzer plugin (that is, <filename>/etc/abrt/plugins/CCpp.conf</filename>, <filename>/etc/abrt/plugins/Kerneloops.conf</filename> and <filename>/etc/abrt/plugins/Python.conf</filename>), add the following line:
- </para>
- <programlisting>AutoReportUIDs = <replaceable>USERNAME</replaceable></programlisting>
- <para>
- where <replaceable>USERNAME</replaceable> represents a user whose detected crashes and issues will be automatically reported via your specified reporters. You can specify multiple users by separating them with a comma (<literal>,</literal>).
- </para>
- </listitem>
- </orderedlist>
- </section>
-</chapter>
+ </section>-->
+</chapter>
\ No newline at end of file
diff --git a/en-US/images/abrt-applet_setting.png b/en-US/images/abrt-applet_setting.png
new file mode 100644
index 0000000..73bb39d
Binary files /dev/null and b/en-US/images/abrt-applet_setting.png differ
diff --git a/en-US/images/abrt-applet_setting2.png b/en-US/images/abrt-applet_setting2.png
new file mode 100644
index 0000000..83043ba
Binary files /dev/null and b/en-US/images/abrt-applet_setting2.png differ
diff --git a/en-US/images/abrt-gui_access.png b/en-US/images/abrt-gui_access.png
new file mode 100644
index 0000000..09f55ee
Binary files /dev/null and b/en-US/images/abrt-gui_access.png differ
diff --git a/en-US/images/abrt-gui_backtrace_review.png b/en-US/images/abrt-gui_backtrace_review.png
new file mode 100644
index 0000000..94105a8
Binary files /dev/null and b/en-US/images/abrt-gui_backtrace_review.png differ
diff --git a/en-US/images/abrt-gui_event_configuration.png b/en-US/images/abrt-gui_event_configuration.png
new file mode 100644
index 0000000..e71dac6
Binary files /dev/null and b/en-US/images/abrt-gui_event_configuration.png differ
diff --git a/en-US/images/abrt-gui_main_screen.png b/en-US/images/abrt-gui_main_screen.png
new file mode 100644
index 0000000..82048cb
Binary files /dev/null and b/en-US/images/abrt-gui_main_screen.png differ
diff --git a/en-US/images/abrt-gui_problem_analyzing.png b/en-US/images/abrt-gui_problem_analyzing.png
new file mode 100644
index 0000000..95f50c3
Binary files /dev/null and b/en-US/images/abrt-gui_problem_analyzing.png differ
diff --git a/en-US/images/abrt-gui_problem_description.png b/en-US/images/abrt-gui_problem_description.png
new file mode 100644
index 0000000..d5c441b
Binary files /dev/null and b/en-US/images/abrt-gui_problem_description.png differ
diff --git a/en-US/images/abrt-gui_report_confirmation.png b/en-US/images/abrt-gui_report_confirmation.png
new file mode 100644
index 0000000..5852e8f
Binary files /dev/null and b/en-US/images/abrt-gui_report_confirmation.png differ
diff --git a/en-US/images/abrt-gui_select_analyzer.png b/en-US/images/abrt-gui_select_analyzer.png
new file mode 100644
index 0000000..b62a477
Binary files /dev/null and b/en-US/images/abrt-gui_select_analyzer.png differ
diff --git a/en-US/images/abrt-gui_select_reporter.png b/en-US/images/abrt-gui_select_reporter.png
new file mode 100644
index 0000000..598ace2
Binary files /dev/null and b/en-US/images/abrt-gui_select_reporter.png differ
More information about the docs-commits
mailing list