[deployment-guide] Minor changes in tagging in the ABRT chapter.
Jaromir Hradilek
jhradile at fedoraproject.org
Tue Sep 27 16:04:02 UTC 2011
commit 95542aa70f80951fd326080eff930555a2dc7770
Author: Miroslav Svoboda <msvoboda at redhat.com>
Date: Tue Sep 27 11:48:36 2011 +0200
Minor changes in tagging in the ABRT chapter.
en-US/Automatic_Bug_Reporting_Tool_ABRT.xml | 167 ++++++++++++++-------------
1 files changed, 87 insertions(+), 80 deletions(-)
---
diff --git a/en-US/Automatic_Bug_Reporting_Tool_ABRT.xml b/en-US/Automatic_Bug_Reporting_Tool_ABRT.xml
index aeccd8f..6e3bd4a 100644
--- a/en-US/Automatic_Bug_Reporting_Tool_ABRT.xml
+++ b/en-US/Automatic_Bug_Reporting_Tool_ABRT.xml
@@ -61,13 +61,13 @@
<listitem>
<para>
<systemitem
- class="service">abrt-ccpp</systemitem>, the <application>ABRT</application> service that provides the C/C++ problems analyzer
+ 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.
+ class="service">abrt-oops</systemitem> — The <application>ABRT</application> service that provides the kernel oopses analyzer.
</para>
</listitem>
</itemizedlist>
@@ -97,13 +97,12 @@ abrtd (pid 1535) is running...</screen>
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>
+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>
+ <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
@@ -265,9 +264,7 @@ kernel.panic = 0</screen>
<para>
Alternatively, you can run the <application>ABRT</application> GUI from the command line as follows:
</para>
- <screen>
-~]$ <command>abrt-gui</command> &
- </screen>
+ <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>
@@ -395,10 +392,10 @@ kernel.panic = 0</screen>
<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>
+ <command>abrt-cli</command> <optional><option>--version</option></optional> <replaceable><command></replaceable> <optional><replaceable><args></replaceable></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>…where <replaceable><args></replaceable> stands for a problem data directory and/or options modifying the commands, and <replaceable><command></replaceable> is one of the following sub-commands:
</para>
<itemizedlist>
<listitem>
@@ -424,7 +421,7 @@ kernel.panic = 0</screen>
</itemizedlist>
<para>To display help on particular <command>abrt-cli</command> command use:</para>
<synopsis>
- <command>abrt-cli <replaceable>command</replaceable>
+ <command>abrt-cli <replaceable><command></replaceable>
<option>--help</option>
</command>
</synopsis>
@@ -435,8 +432,7 @@ kernel.panic = 0</screen>
<para>
To view detected problems, enter the <command>abrt-cli list</command> command:
</para>
- <screen>
-~]# <command>abrt-cli list</command>
+ <screen>~]# <command>abrt-cli list</command>
Directory: /var/spool/abrt/ccpp-2011-09-13-10:18:14-2895
count: 2
executable: /usr/bin/gdb
@@ -472,11 +468,11 @@ uid: 500</screen>
</listitem>
<listitem>
<para>
- <computeroutput>time:</computeroutput> — Shows the date and time of the last occurrence of the problem.</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>
+ <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.
@@ -542,10 +538,12 @@ uid: 500</screen>
</table>
<para>
If you want to view information just about one particular problem, you can use the command:
+ </para>
<synopsis>
<command>abrt-cli info</command> <replaceable><DIR></replaceable>
</synopsis>
- …where <varname>DIR</varname> stands for the <emphasis
+ <para>
+ …where <replaceable><DIR></replaceable> 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
@@ -604,12 +602,14 @@ uid: 500</screen>
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
+ To report a certain problem, use the command:</para>
+ <synopsis>
+ <command>abrt-cli report <replaceable><DIR></replaceable></command>
+ </synopsis>
+ <para>...where <replaceable><DIR></replaceable> 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>
+ <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
@@ -622,14 +622,12 @@ Select analyzer: _</screen>
<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>
+ <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?
+ <screen>How would you like to report the problem?
1) Logger
2) Red Hat Customer Support
Select reporter(s): _</screen>
@@ -687,11 +685,15 @@ Select reporter(s): _</screen>
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:
+ 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:
</para>
- <screen>
-~]$ <command>abrt-cli rm</command> <filename>/var/spool/abrt/ccpp-2011-09-12-18:37:24-4413</filename>
+ <synopsis>
+ <command>abrt-cli rm <replaceable><DIR></replaceable></command>
+ </synopsis>
+ <para>
+ ...where <replaceable><DIR></replaceable> 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>
@@ -757,17 +759,17 @@ rm '/var/spool/abrt/ccpp-2011-09-12-18:37:24-4413'</screen>
<itemizedlist>
<listitem>
<para>
- Event 1 - a problem data directory is created.
+ Event 1 — a problem data directory is created.
</para>
</listitem>
<listitem>
<para>
- Event 2 - problem data is analyzed.
+ Event 2 — problem data is analyzed.
</para>
</listitem>
<listitem>
<para>
- Event 3 - a problem is reported to Bugzilla.
+ Event 3 — a problem is reported to Bugzilla.
</para>
</listitem>
</itemizedlist>
@@ -855,27 +857,26 @@ rm '/var/spool/abrt/ccpp-2011-09-12-18:37:24-4413'</screen>
</para>
<itemizedlist>
<listitem>
- <para><varname>VAR</varname> is either the <constant>EVENT</constant> key word or a name of a problem data
+ <para><replaceable>VAR</replaceable> 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
+ <replaceable>VAL</replaceable> is either a name of an event or a problem data element, and
</para>
</listitem>
<listitem>
<para>
- <varname>REGEX</varname> is a regular expression.
+ <replaceable>REGEX</replaceable> 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>
+ <programlisting language="Bash">EVENT=post-create date > /tmp/dt
+ echo $HOSTNAME `uname -r`</programlisting>
<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.
@@ -886,14 +887,13 @@ EVENT=post-create date >/tmp/dt
<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.*
+ <programlisting language="Bash">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>
+ grep -F -e "$base_executable" ~/.xsession-errors | tail -999 >xsession_errors &&
+ echo "Element 'xsession_errors' saved"</programlisting>
<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>
@@ -916,7 +916,7 @@ EVENT=analyze_xsession_errors analyzer=CCpp dso_list~=.*/libX11.*
</term>
<listitem>
<para>
- …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
+ …where <replaceable><NAME_SUFFIX></replaceable> 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>
@@ -927,7 +927,7 @@ EVENT=analyze_xsession_errors analyzer=CCpp dso_list~=.*/libX11.*
</term>
<listitem>
<para>
- …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>.
+ …where <replaceable><NAME_SUFFIX></replaceable> 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>
@@ -937,7 +937,7 @@ EVENT=analyze_xsession_errors analyzer=CCpp dso_list~=.*/libX11.*
</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>.
+ …where <replaceable><NAME_SUFFIX></replaceable> 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>
@@ -1232,8 +1232,14 @@ EVENT=analyze_xsession_errors analyzer=CCpp dso_list~=.*/libX11.*
<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.
+ 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 <application>ABRT</application> in SELinux.
+ </para>
+ <para>
+ Remember that if you enable this option when using SELinux, you need to execute the following command in order to set the appropriate boolean allowing <application>ABRT</application> to write into the public_content_rw_t domain:
</para>
+ <synopsis>
+ <command>setsebool -P abrt_anon_write 1</command>
+ </synopsis>
</warning>
</listitem>
</varlistentry>
@@ -1258,8 +1264,14 @@ EVENT=analyze_xsession_errors analyzer=CCpp dso_list~=.*/libX11.*
<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.
+ 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 <application>ABRT</application> in SELinux.
+ </para>
+ <para>
+ Remember that if you enable this option when using SELinux, you need to execute the following command in order to set the appropriate boolean allowing <application>ABRT</application> to write into the public_content_rw_t domain:
</para>
+ <synopsis>
+ <command>setsebool -P abrt_anon_write 1</command>
+ </synopsis>
</warning>
</listitem>
</varlistentry>
@@ -1342,9 +1354,9 @@ EVENT=analyze_xsession_errors analyzer=CCpp dso_list~=.*/libX11.*
<para>
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>
- <screen>EVENT=post-create analyzer=Python
- test -f component || abrt-action-save-package-data
- reporter-bugzilla -c /etc/abrt/plugins/Bugzilla.conf</screen>
+ <programlisting language="Bash">EVENT=post-create analyzer=Python
+ test -f component || abrt-action-save-package-data
+ reporter-bugzilla -c /etc/abrt/plugins/Bugzilla.conf</programlisting>
<warning>
<title><systemitem class="event">post-create</systemitem> runs with root privileges</title>
<para>
@@ -1364,10 +1376,10 @@ EVENT=analyze_xsession_errors analyzer=CCpp dso_list~=.*/libX11.*
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>
+ <programlisting language="Bash">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</programlisting>
</section>
</section>
<section
@@ -1417,11 +1429,10 @@ EVENT=analyze_xsession_errors analyzer=CCpp dso_list~=.*/libX11.*
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
+ <screen>~]$ <command>ftp</command>
+ftp> <command>open SERVERNAME</command>
+Name: <userinput>USERNAME</userinput>
+Password: <userinput>PASSWORD</userinput>
ftp> <command>cd /var/spool/abrt-upload</command>
250 Operation successful
ftp> <command>put TESTFILE</command>
@@ -1442,12 +1453,11 @@ ftp> <command>quit</command></screen>
<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>
+ <programlisting language="Bash">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</programlisting>
<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>
@@ -1483,17 +1493,15 @@ EVENT=analyze_LocalGDB analyzer=CCpp
<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>
+ <programlisting lang="Bash">EVENT=post-create
+ reporter-upload -u scp://<replaceable>user</replaceable>:<replaceable>password</replaceable>@<replaceable>server</replaceable>.<replaceable>name</replaceable>
+ <replaceable>/directory</replaceable></programlisting>
<para>
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>
- <screen>
-EVENT=report_UploadToMyServer
- reporter-upload -u scp://<replaceable>user</replaceable>:<replaceable>password</replaceable>@<replaceable>server</replaceable>.<replaceable>name</replaceable>
- <replaceable>/directory</replaceable></screen>
+ <programlisting lang="Bash">EVENT=report_UploadToMyServer
+ reporter-upload -u scp://<replaceable>user</replaceable>:<replaceable>password</replaceable>@<replaceable>server</replaceable>.<replaceable>name</replaceable>
+ <replaceable>/directory</replaceable></programlisting>
</listitem>
</orderedlist>
</section>
@@ -1518,8 +1526,8 @@ EVENT=report_UploadToMyServer
<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>
+ <programlisting lang="Bash">EVENT=post-create component=
+ abrt-action-save-package-data</programlisting>
</listitem>
<listitem>
<para>
@@ -1540,8 +1548,8 @@ EVENT=report_UploadToMyServer
<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>
+ <programlisting lang="Bash">EVENT=post-create remote!=1 component=
+ abrt-action-save-package-data</programlisting>
</para>
</listitem>
<listitem>
@@ -1568,10 +1576,9 @@ EVENT=report_UploadToMyServer
</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 &
+ <screen>~]$ <command>sleep 100 &</command>
[1] 2823
-~]$ kill -s SEGV 2823</screen>
+~]$ <command>kill -s SEGV 2823</command></screen>
<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>
More information about the docs-commits
mailing list