[deployment-guide/comm-rel: 353/727] changed the order of sections
Jaromir Hradilek
jhradile at fedoraproject.org
Tue Oct 19 12:54:21 UTC 2010
commit 0da58cee9fea113bde689850dccf149767dae60a
Author: Martin Prpic <mprpic at redhat.com>
Date: Thu Aug 12 15:58:20 2010 +0200
changed the order of sections
en-US/ABRT.xml | 352 ++++++++++++++++++++++++++++----------------------------
1 files changed, 176 insertions(+), 176 deletions(-)
---
diff --git a/en-US/ABRT.xml b/en-US/ABRT.xml
index 6b8c8d8..ce008e4 100644
--- a/en-US/ABRT.xml
+++ b/en-US/ABRT.xml
@@ -130,127 +130,6 @@ Starting abrt daemon: [ OK ]</screen>
<para>Alternatively, you can open the <application>ABRT</application> GUI application by clicking <menuchoice><guimenu>Applications</guimenu> <guisubmenu>System Tools</guisubmenu><guimenuitem>Automatic Bug Reporting Tool</guimenuitem></menuchoice>.
</para>
</section>
- <section id="configuring">
- <title>Configuring ABRT</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 config files, located in the <filename>/etc/abrt/plugins/</filename> directory.</para>
- <para>After changing and saving the <filename>abrt.conf</filename> configuration file, you must restart the <systemitem class="daemon">abrtd</systemitem> daemon—as root—for the new settings to take effect:</para>
- <screen>~]# <command>service abrtd restart</command>
- </screen>
- <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 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, list them here separated by commas.</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>ProcessUnpackaged = <replaceable><yes/no></replaceable>
- </term>
- <listitem>
- <para>
- This directive tells <application>ABRT</application> whether to process crashes in executables that do not belong to any package.
- </para>
- </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>.
- </para>
- </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.
- </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>
- </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="plugins-and-sending-crash-reports"/></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 = TicketUploader, Bugzilla</term>
- <listitem>
- <para>This directive specifies that, for kernel oopses, the TicketUploader and Bugzilla reporters will be run.</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>CCpp = TicketUploader, Bugzilla</term>
- <listitem>
- <para>This directive specifies that, when C or C++ program crashes occur, both the TicketUploader and Bugzilla reporters will be run.</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>Python = TicketUploader, Bugzilla</term>
- <listitem>
- <para>This directive specifies that, when Python program crashes occur, both the TicketUploader and Bugzilla reporters will be run.</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/Bugzilla.conf</filename> specifies which Bugzilla URL to use (set to <ulink url="https://bugzilla.redhat.com/"/> by default), the user's login name, password for logging in to the Bugzilla 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="plugins-and-sending-crash-reports"/>).
- </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>
- <screen># Which Action plugins to run repeatedly
-[ Cron ]
-# h:m - at h:m
-# s - every s seconds
-120 = KerneloopsScanner
-#02:00 = FileTransfer</screen>
- </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="plugins-and-sending-crash-reports">
<title>Plugins and Sending Crash Reports</title>
<para>
@@ -476,7 +355,7 @@ Starting abrt daemon: [ OK ]</screen>
</listitem>
</itemizedlist>
<para>
- When the <guilabel>No SSL verify</guilabel> option is checked, the <systemitem class="protocol">SSL</systemitem> protocol is not used when sending data over the network.
+ When the <guilabel>No SSL verify</guilabel> option is checked, the <systemitem class="protocol">SSL</systemitem> protocol is not used when sending the data over the network.
</para>
</listitem>
</varlistentry>
@@ -501,6 +380,181 @@ Starting abrt daemon: [ OK ]</screen>
</variablelist>
</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. It is useful when <command>abrt-cli</command> is executed with superuser privileges and it lists crashes from all users. 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 certain crash, you enter <command>abrt-cli <replaceable>--report/-r</replaceable> <UUID></command>, where <varname>UUID</varname> is a field from <command>abrt-cli <replaceable>--list/-l</replaceable>
+ </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="tab"><ENTER></keycap>.</para>
+ <screen>
+~]# <command>abrt-cli --report 480</command>
+ <keycap function="tab"><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>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 if you want to send the report. Respond <keycap>Y</keycap> to send the report or <keycap>N</keycap> to cancel it.</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>.
+ </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.
+ </para>
+ </section>
+ </section>
+ <section id="configuring">
+ <title>Configuring ABRT</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 config files, located in the <filename>/etc/abrt/plugins/</filename> directory.</para>
+ <para>After changing and saving the <filename>abrt.conf</filename> configuration file, you must restart the <systemitem class="daemon">abrtd</systemitem> daemon—as root—for the new settings to take effect:</para>
+ <screen>~]# <command>service abrtd restart</command>
+ </screen>
+ <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 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, list them here separated by commas.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>ProcessUnpackaged = <replaceable><yes/no></replaceable>
+ </term>
+ <listitem>
+ <para>
+ This directive tells <application>ABRT</application> whether to process crashes in executables that do not belong to any package.
+ </para>
+ </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>.
+ </para>
+ </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.
+ </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>
+ </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="plugins-and-sending-crash-reports"/></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 = TicketUploader, Bugzilla</term>
+ <listitem>
+ <para>This directive specifies that, for kernel oopses, the TicketUploader and Bugzilla reporters will be run.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>CCpp = TicketUploader, Bugzilla</term>
+ <listitem>
+ <para>This directive specifies that, when C or C++ program crashes occur, both the TicketUploader and Bugzilla reporters will be run.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Python = TicketUploader, Bugzilla</term>
+ <listitem>
+ <para>This directive specifies that, when Python program crashes occur, both the TicketUploader and Bugzilla reporters will be run.</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/Bugzilla.conf</filename> specifies which Bugzilla URL to use (set to <ulink url="https://bugzilla.redhat.com/"/> by default), the user's login name, password for logging in to the Bugzilla 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="plugins-and-sending-crash-reports"/>).
+ </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>
+ <screen># Which Action plugins to run repeatedly
+[ Cron ]
+# h:m - at h:m
+# s - every s seconds
+120 = KerneloopsScanner
+#02:00 = FileTransfer</screen>
+ </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>
@@ -617,58 +671,4 @@ Python = ReportUploader
<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>
- <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. It is useful when <command>abrt-cli</command> is executed with superuser privileges and it lists crashes from all users. 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 certain crash, you enter <command>abrt-cli <replaceable>--report/-r</replaceable> <UUID></command>, where <varname>UUID</varname> is a field from <command>abrt-cli <replaceable>--list/-l</replaceable>
- </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="tab"><ENTER></keycap>.</para>
- <screen>
-~]# <command>abrt-cli --report 480</command>
- <keycap function="tab"><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>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 if you want to send the report. Respond <keycap>Y</keycap> to send the report or <keycap>N</keycap> to cancel it.</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>.
- </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.
- </para>
- </section>
- </section>
</chapter>
More information about the docs-commits
mailing list