Centos [abrt] a Crash Has Been Detected Again

25.1. Introduction to ABRT

The Automatic Bug Reporting Tool , normally abbreviated equally ABRT , is a set of tools that is designed to help users find and report application crashes. Its primary purpose is to ease the process of reporting problems and finding solutions. In this context, the solution can be a Bugzilla ticket, a knowledge-base article, or a suggestion to update a bundle to a version containing a fix.

ABRT consists of the abrtd daemon and a number of system services and utilities for processing, analyzing, and reporting detected bug. The daemon runs silently in the background nigh of the fourth dimension and 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'south command line parameters, and other data of forensic utility.

ABRT currently supports the detection of crashes in applications written in the C, C++, Java, Python, and Ruddy programming languages, equally well as 10.Org crashes, kernel oopses, and kernel panics. Run into Section 25.four, "Detecting Software Problems" for more detailed information on the types of failures and crashes supported, and the way the various types of crashes are detected.

The identified problems can exist reported to a remote issue tracker, and the reporting tin exist configured to happen automatically whenever an issue is detected. Problem information can likewise exist stored locally or on a dedicated system and reviewed, reported, and deleted manually by the user. The reporting tools can send problem information to a Bugzilla database or the Red Hat Technical Support (RHTSupport) website. The tools tin also upload information technology using FTP or SCP, send it as an electronic mail, or write it to a file.

The ABRT component that handles existing trouble information (equally opposed to, for case, the cosmos of new trouble information) is a part of a carve up projection, libreport . The libreport library provides a generic machinery for analyzing and reporting problems, and information technology is used by applications other than ABRT equally well. Yet, ABRT and libreport operation and configuration are closely integrated. They are, therefore, discussed as one in this document.

Notation that ABRT report is generated only when core dump is generated. Core dump is generated but for some signals. For example, SIGKILL (-9) does not generate core dump, and so ABRT cannot catch this neglect. For more than information about signals and cadre dump generating, run into human 7 indicate.

25.ii. Installing ABRT and Starting its Services

In order to apply ABRT , ensure that the abrt-desktop or the abrt-cli parcel is installed on your system. The abrt-desktop packet provides a graphical user interface for ABRT , and the abrt-cli package contains a tool for using ABRT on the command line. You can likewise install both. The general workflow with both the ABRT GUI and the command line tool is procedurally similar and follows the same design.

Please note that installing the ABRT packages overwrites the /proc/sys/kernel/core_pattern file, which can comprise a template used to name core-dump files. The content of this file volition be overwritten to:

|/usr/libexec/abrt-claw-ccpp %southward %c %p %u %k %t due east

See Section 9.2.4, "Installing Packages" for general information on how to install packages using the Yum bundle manager.

25.ii.1. Installing the ABRT GUI

The ABRT graphical user interface provides an piece of cake-to-employ front end for working in a desktop environment. You tin install the required package past running the following command as the root user:

~]# yum install abrt-desktop

Upon installation, the ABRT notification applet is configured to start automatically when your graphical desktop session starts. Y'all tin verify that the ABRT applet is running past issuing the following control in a last:

~]$ ps -el | grep abrt-applet 0 S  500 2036 1824 0 lxxx  0 - 61604 poll_s ?    00:00:00 abrt-applet

If the applet is not running, you can beginning information technology manually in your current desktop session by running the abrt-applet program:

~]$              abrt-applet &              [1] 2261

25.2.2. Installing ABRT for the Command Line

The command line interface is useful on headless machines, remote systems connected over a network, or in scripts. You can install the required packet past running the following command every bit the root user:

~]# yum install abrt-cli

25.2.3. Installing Supplementary ABRT Tools

To receive email notifications about crashes detected by ABRT , you demand to have the libreport-plugin-mailx packet installed. You can install information technology by executing the following command as root:

~]# yum install libreport-plugin-mailx

Past default, it sends notifications to the root user at the local machine. The email destination can be configured in the /etc/libreport/plugins/mailx.conf file.

To have notifications displayed in your console at login time, install the abrt-panel-notification bundle besides.

ABRT tin find, analyze, and report various types of software failures. Past default, ABRT is installed with back up for the most mutual types of failures, such as crashes of C and C++ applications. Back up for other types of failures is provided past independent packages. For example, to install support for detecting exceptions in applications written using the Java language, run the post-obit command equally root:

~]# yum install abrt-java-connector

Run across Section 25.four, "Detecting Software Issues" for a list of languages and software projects which ABRT supports. The section also includes a list of all corresponding packages that enable the detection of the diverse types of failures.

25.2.4. Starting the ABRT Services

The abrtd daemon requires the abrt user to exist for file organization operations in the /var/spool/abrt directory. When the abrt package is installed, it automatically creates the abrt user whose UID and GID is 173, if such user does not already exist. Otherwise, the abrt user can be created manually. In that case, whatsoever UID and GID tin be chosen, considering abrtd does not require a specific UID and GID.

The abrtd daemon is configured to start at boot time. You lot tin use the following control to verify its current status:

~]$              systemctl is-active abrtd.service              agile

If systemctl returns inactive or unknown, the daemon is non running. You tin can outset it for the current session by entering the following command as root:

~]# systemctl commencement abrtd.service

Y'all can utilise the aforementioned commands to kickoff or check status of related error-detection services. For example, make certain the abrt-ccpp service is running if you desire ABRT to observe C or C++ crashes. Meet Section 25.iv, "Detecting Software Bug" for a listing of all available ABRT detection services and their respective packages.

With the exception of the abrt-vmcore and abrt-pstoreoops services, which are only started when a kernel panic or kernel oops occurs, all ABRT services are automatically enabled and started at kick time when their corresponding packages are installed. You can disable or enable whatsoever ABRT service by using the systemctl utility as described in Chapter 10, Managing Services with systemd.

25.2.five. Testing ABRT Crash Detection

To test that ABRT works properly, use the kill control to send the SEGV point to cease a process. For instance, beginning a sleep process and stop it with the kill control in the following way:

~]$              sleep 100 &              [1] 2823 ~]$              kill -s SIGSEGV 2823            

ABRT detects a crash shortly subsequently executing the kill command, and, provided a graphical session is running, the user is notified of the detected problem past the GUI notification applet. On the command line, you lot can bank check that the crash was detected by running the abrt-cli list command or by examining the crash dump created in the /var/spool/abrt/ directory. Encounter Section 25.5, "Handling Detected Problems" for more data on how to work with detected crashes.

25.3. Configuring ABRT

A trouble life cycle is driven by events in ABRT . For example:

• Event #1 — a trouble-information directory is created.
• Event #two — problem data is analyzed.
• Issue #3 — the problem is reported to Bugzilla.

Whenever a problem is detected, ABRT compares it with all existing problem information and determines whether that same problem has already been recorded. If information technology has, the existing trouble data is updated, and the most recent (indistinguishable) problem is not recorded once again. If the trouble is non recognized by ABRT , a problem-data directory is created. A trouble-information directory typically consists of files such as: analyzer, architecture, coredump, cmdline, executable, kernel, os_release, reason, fourth dimension, and uid.

Other files, such as backtrace, tin can be created during the assay of the problem, depending on which analyzer method is used and its configuration settings. Each of these files holds specific information about the organization and the problem itself. For instance, the kernel file records the version of a crashed kernel.

Later the trouble-data directory is created and problem data gathered, you tin can process the problem using either the ABRT GUI, or the abrt-cli utility for the control line. See Section 25.5, "Treatment Detected Problems" for more information about the ABRT tools provided for working with recorded issues.

25.3.1. Configuring Events

ABRT events employ plugins to carry out the actual reporting operations. Plugins are compact utilities that the events phone call to procedure the content of trouble-information directories. Using plugins, ABRT is capable of reporting problems to diverse destinations, and near every reporting destination requires some configuration. For instance, Bugzilla requires a user name, password, and a URL pointing to an instance of the Bugzilla service.

Some configuration details can have default values (such as a Bugzilla URL), only others cannot accept sensible defaults (for case, a user name). ABRT looks for these settings in configuration files, such as report_Bugzilla.conf, in the /etc/libreport/events/ or $HOME/.enshroud/abrt/events/ directories for system-wide or user-specific settings respectively. The configuration files comprise pairs of directives and values.

These files are the bare minimum necessary for running events and processing the problem-data directories. The gnome-abrt and abrt-cli tools read the configuration data from these files and laissez passer information technology to the events they run.

Additional information most events (such as their description, names, types of parameters that tin be passed to them as surround variables, and other properties) is stored in event_name .xml files in the /usr/share/libreport/events/ directory. These files are used by both gnome-abrt and abrt-cli to make the user interface more than friendly. Practise non edit these files unless you want to modify the standard installation. If you intend to do that, copy the file to exist modified to the /etc/libreport/events/ directory and modify the new file. These files can contain the following information:

• a convenient event name and description (Bugzilla, Report to Bugzilla bug tracker),
• a list of items in a problem-data directory that are required for the event to succeed,
• a default and mandatory selection of items to send or not send,
• whether the GUI should prompt for data review,
• what configuration options be, their types (string, Boolean, then on), default value, prompt cord, and so on; this lets the GUI build appropriate configuration dialogs.

For case, the report_Logger event accepts an output filename as a parameter. Using the respective event_name .xml file, the ABRT GUI determines which parameters tin be specified for a selected upshot and allows the user to set the values for these parameters. The values are saved by the ABRT GUI and reused on subsequent invocations of these events. Note that the ABRT GUI saves configuration options using the GNOME Keyring tool and by passing them to events, information technology overrides data from text configuration files.

To open the graphical Configuration window, choose → → → → from within a running instance of the gnome-abrt application. This window shows a list of events that can exist selected during the reporting process when using the GUI . When you select one of the configurable events, you can click the Configure push and modify the settings for that consequence.

Effigy 25.one. Configuring ABRT Events

All files in the /etc/libreport/ directory hierarchy are earth-readable and are meant to exist used every bit global settings. Thus, it is not advisable to store user names, passwords, or any other sensitive information in them. The per-user settings (set in the GUI awarding and readable by the owner of $HOME only) are safely stored in GNOME Keyring , or they tin can be stored in a text configuration file in $HOME/.abrt/ for use with abrt-cli.

The post-obit tabular array shows a selection of the default analyzing, collecting, and reporting events provided by the standard installation of ABRT . The table lists each event's name, identifier, configuration file from the /etc/libreport/events.d/ directory, and a cursory description. Note that while the configuration files use the event identifiers, the ABRT GUI refers to the private events using their names. Note also that non all of the events can be set up using the GUI . For data on how to ascertain a custom event, see Department 25.3.2, "Creating Custom Events".

Table 25.1. Standard ABRT Events

Name	Identifier and Configuration File	Clarification
uReport	report_uReport	Uploads a μReport to the FAF server.
Mailx	report_Mailx mailx_event.conf	Sends the trouble report via the Mailx utility to a specified email address.
Bugzilla	report_Bugzilla bugzilla_event.conf	Reports the problem to the specified installation of the Bugzilla bug tracker.
Red Hat Customer Support	report_RHTSupport rhtsupport_event.conf	Reports the problem to the Cherry Hat Technical Support system.
Analyze C or C++ Crash	analyze_CCpp ccpp_event.conf	Sends the cadre dump to a remote retrace server for analysis or performs a local analysis if the remote one fails.
Written report uploader	report_Uploader uploader_event.conf	Uploads a tarball (.tar.gz) annal with trouble data to the chosen destination using the FTP or the SCP protocol.
Clarify VM core	analyze_VMcore vmcore_event.conf	Runs the GDB (the GNU debugger) on the trouble information of a kernel oops and generates a backtrace of the kernel.
Local GNU Debugger	analyze_LocalGDB ccpp_event.conf	Runs GDB (the GNU debugger) on the problem information of an application and generates a backtrace of the plan.
Collect .xsession-errors	analyze_xsession_errors ccpp_event.conf	Saves relevant lines from the ~/.xsession-errors file to the trouble report.
Logger	report_Logger print_event.conf	Creates a problem report and saves information technology to a specified local file.
Kerneloops.org	report_Kerneloops koops_event.conf	Sends a kernel problem to the oops tracker at kerneloops.org.

25.iii.two. Creating Custom Events

Each consequence is defined by one dominion construction in a corresponding configuration file. The configuration files are typically stored in the /etc/libreport/events.d/ directory. These configuration files are loaded past the main configuration file, /etc/libreport/report_event.conf. At that place is no need to edit the default configuration files because abrt will run the scripts independent in /etc/libreport/events.d/. This file accepts shell metacharacters (for instance, *, $, ?) and interprets relative paths relatively to its location.

Each rule starts with a line with a non-space leading grapheme, and all subsequent lines starting with the space character or the tab graphic symbol are considered a function of this rule. Each rule consists of two parts, a condition part and a program part. The status part contains atmospheric condition in one of the following forms:

• VAR = VAL
• VAR != VAL
• VAL ~= REGEX

where:

• VAR is either the EVENT key word or a proper noun of a problem-data directory element (such as executable, package, hostname, and so on),
• VAL is either a name of an event or a trouble-information element, and
• REGEX is a regular expression.

The program part consists of programme names and shell-interpretable code. If all conditions in the status office are valid, the program part is run in the trounce. The following is an event example:

EVENT=post-create engagement > /tmp/dt     echo $HOSTNAME              uname -r            

This upshot would overwrite the contents of the /tmp/dt file with the current appointment and time and print the host name of the machine and its kernel version on the standard output.

Here is an example of a more complex result, which is actually 1 of the predefined events. Information technology saves relevant lines from the ~/.xsession-errors file to the problem written report of whatsoever problem for which the abrt-ccpp service has been used, provided the crashed application had any X11 libraries loaded at the time of the crash:

Result=analyze_xsession_errors analyzer=CCpp dso_list~=.                /libX11.                            test -f ~/.xsession-errors || { echo "No ~/.xsession-errors"; exit 1; }     test -r ~/.xsession-errors || { echo "Tin can't read ~/.xsession-errors"; leave 1; }     executable=cat executable              &&     base_executable=${executable##*/} &&     grep -F -e "$base_executable" ~/.xsession-errors | tail -999 >xsession_errors &&     echo "Chemical element 'xsession_errors' saved"

The set of possible events is not definitive. System administrators can add events according to their need in the /etc/libreport/events.d/ directory.

Currently, the following event names are provided with the standard ABRT and libreport installations:

mail-create

This event is run past abrtd to process newly created trouble-data directories. When the postal service-create event is run, abrtd checks whether the new problem data matches any of the already existing problem directories. If such a problem directory exists, it is updated and the new problem information is discarded. Note that if the script in whatever definition of the mail service-create issue exits with a non-naught value, abrtd will cease the procedure and will drop the trouble data.

notify, notify-dup

The notify event is run following the completion of post-create. When the event is run, the user can be sure that the problem deserves their attention. The notify-dup is similar, except information technology is used for duplicate occurrences of the same problem.

analyze_ name_suffix

where name_suffix is the replaceable office of the upshot proper noun. This outcome is used to process nerveless data. For example, the analyze_LocalGDB effect uses the GNU Debugger ( GDB ) utility to procedure the cadre dump of an application and produce a backtrace of the crash.

collect_ name_suffix

{blank}

…where name_suffix is the adjustable part of the event name. This upshot is used to collect additional information on problems.

report_ name_suffix

{blank}

…where name_suffix is the adjustable part of the event name. This consequence is used to report a problem.

25.3.three. Setting Up Automatic Reporting

ABRT can be configured to ship initial bearding reports, or μReports , of any detected issues or crashes automatically without any user interaction. When automatic reporting is turned on, the then called μReport, which is unremarkably sent at the beginning of the crash-reporting procedure, is sent immediately after a crash is detected. This prevents duplicate support cases based on identical crashes. To enable the autoreporting feature, issue the following control every bit root:

~]# abrt-auto-reporting enabled

The in a higher place command sets the AutoreportingEnabled directive in the /etc/abrt/abrt.conf configuration file to yes. This system-broad setting applies to all users of the system. Annotation that by enabling this option, automatic reporting will also be enabled in the graphical desktop surroundings. To only enable autoreporting in the ABRT GUI, switch the Automatically send uReport option to YES in the Problem Reporting Configuration window. To open this window, cull → → → → from inside a running instance of the gnome-abrt application. To launch the awarding, go to → → → → → → .

Figure 25.ii. Configuring ABRT Problem Reporting

Upon detection of a crash, by default, ABRT submits a μReport with bones information virtually the problem to Cherry Hat's ABRT server. The server determines whether the problem is known and either provides a brusque description of the problem along with a URL of the reported example if known, or invites the user to report information technology if not known.

A μReport (microreport) is a JSON object representing a problem, such equally a binary crash or a kernel oops. These reports are designed to be cursory, car readable, and completely bearding, which is why they can be used for automatic reporting. The μReports brand it possible to proceed rail of problems occurrences, but they usually do not provide enough information for engineers to fix the bug. A full bug report is needed for a support case to be opened.

To change the default behavior of the autoreporting facility from sending a μReport, alter the value of the AutoreportingEvent directive in the /etc/abrt/abrt.conf configuration file to point to a different ABRT upshot. See Tabular array 25.1, "Standard ABRT Events" for an overview of the standard events.

25.4. Detecting Software Problems

ABRT is capable of detecting, analyzing, and processing crashes in applications written in a variety of different programming languages. Many of the packages that contain the support for detecting the various types of crashes are installed automatically when either one of the main ABRT packages ( abrt-desktop , abrt-cli ) is installed. Encounter Section 25.2, "Installing ABRT and Starting its Services" for instructions on how to install ABRT . Come across the table below for a listing of the supported types of crashes and the respective packages.

Table 25.2. Supported Programming Languages and Software Projects

Langauge/Project	Package
C or C++	abrt-addon-ccpp
Python	abrt-addon-python
Ruby	rubygem-abrt
Java	abrt-java-connector
X.Org	abrt-addon-xorg
Linux (kernel oops)	abrt-addon-kerneloops
Linux (kernel panic)	abrt-addon-vmcore
Linux (persistent storage)	abrt-addon-pstoreoops

25.4.1. Detecting C and C++ Crashes

The abrt-ccpp service installs its own core-dump handler, which, when started, overrides the default value of the kernel's core_pattern variable, and then that C and C++ crashes are handled past abrtd. If yous stop the abrt-ccpp service, the previously specified value of core_pattern is reinstated.

By default, the /proc/sys/kernel/core_pattern file contains the string core, which means that the kernel produces files with the cadre. prefix in the electric current directory of the crashed process. The abrt-ccpp service overwrites the core_pattern file to contain the following command:

|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e

This command instructs the kernel to pipage the core dump to the abrt-hook-ccpp programme, which stores it in ABRT 'south dump location and notifies the abrtd daemon of the new crash. Information technology also stores the following files from the /proc/ PID / directory (where PID is the ID of the crashed procedure) for debugging purposes: maps, limits, cgroup, status. See proc (5) for a description of the format and the significant of these files.

25.4.2. Detecting Python Exceptions

The abrt-addon-python parcel installs a custom exception handler for Python applications. The Python interpreter then automatically imports the abrt.pth file installed in /usr/lib64/python2.7/site-packages/, which in plow imports abrt_exception_handler.py. This overrides Python'southward default sys.excepthook with a custom handler, which forwards unhandled exceptions to abrtd via its Socket API.

To disable the automatic import of site-specific modules, and thus prevent the ABRT custom exception handler from existence used when running a Python application, laissez passer the -Southward pick to the Python interpreter:

~]$              python -Due south                                  file.py                                          

In the in a higher place command, supercede file.py with the name of the Python script you want to execute without the employ of site-specific modules.

25.4.3. Detecting Carmine Exceptions

The rubygem-abrt packet registers a custom handler using the at_exit feature, which is executed when a plan ends. This allows for checking for possible unhandled exceptions. Every fourth dimension an unhandled exception is captured, the ABRT handler prepares a bug report, which can be submitted to Blood-red Hat Bugzilla using standard ABRT tools.

25.4.4. Detecting Java Exceptions

The ABRT Coffee Connector is a JVM agent that reports uncaught Java exceptions to abrtd. The agent registers several JVMTI result callbacks and has to be loaded into the JVM using the -agentlib control line parameter. Note that the processing of the registered callbacks negatively impacts the performance of the application. Use the following command to take ABRT catch exceptions from a Coffee class:

~]$              coffee -agentlib:abrt-java-connector=abrt=on                                  $MyClass                                -platform.jvmtiSupported true            

In the to a higher place control, replace $MyClass with the name of the Java class yous want to test. By passing the abrt=on choice to the connector, y'all ensure that the exceptions are handled past abrtd. In example you want to have the connector output the exceptions to standard output, omit this pick.

25.iv.5. Detecting X.Org Crashes

The abrt-xorg service collects and processes information virtually crashes of the X.Org server from the /var/log/Xorg.0.log file. Notation that no report is generated if a blacklisted Ten.org module is loaded. Instead, a not-reportable file is created in the problem-information directory with an advisable caption. Yous can notice the listing of offending modules in the /etc/abrt/plugins/xorg.conf file. Only proprietary graphics-driver modules are blacklisted past default.

25.4.6. Detecting Kernel Oopses and Panics

Past checking the output of kernel logs, ABRT is able to catch and process the so-called kernel oopses — non-fatal deviations from the correct behavior of the Linux kernel. This functionality is provided by the abrt-oops service.

ABRT can likewise detect and process kernel panics — fatal, non-recoverable errors that require a reboot, using the abrt-vmcore service. The service only starts when a vmcore file (a kernel-core dump) appears in the /var/crash/ directory. When a cadre-dump file is constitute, abrt-vmcore creates a new problem-information directory in the /var/spool/abrt/ directory and copies the core-dump file to the newly created problem-data directory. Later the /var/crash/ directory is searched, the service is stopped.

For ABRT to be able to detect a kernel panic, the kdump service must exist enabled on the system. The amount of retention that is reserved for the kdump kernel has to be prepare correctly. You can set information technology using the arrangement-config-kdump graphical tool or by specifying the crashkernel parameter in the list of kernel options in the GRUB 2 menu. For details on how to enable and configure kdump, run into the Crimson Hat Enterprise Linux 7 Kernel Crash Dump Guide. For information on making changes to the GRUB 2 menu meet Chapter 26, Working with Grub two.

Using the abrt-pstoreoops service, ABRT is capable of collecting and processing information about kernel panics, which, on systems that back up pstore , is stored in the automatically-mounted /sys/fs/pstore/ directory. The platform-dependent pstore interface (persistent storage) provides a machinery for storing data across organisation reboots, thus allowing for preserving kernel panic data. The service starts automatically when kernel crash-dump files appear in the /sys/fs/pstore/ directory.

25.5. Treatment Detected Problems

Problem data saved past abrtd can be viewed, reported, and deleted using either the command line tool, abrt-cli, or the graphical tool, gnome-abrt.

Note that ABRT identifies duplicate problems by comparing new problems with all locally saved problems. For a repeating crash, ABRT requires you lot to human activity upon information technology only once. However, if you delete the crash dump of that problem, the next time this specific problem occurs, ABRT will care for information technology as a new crash: ABRT will alert you about it, prompt you to fill in a description, and written report it. To avoid having ABRT notifying y'all about a recurring problem, practice not delete its trouble data.

25.5.1. Using the Command Line Tool

In the command line environment, the user is notified of new crashes on login, provided they have the abrt-console-notification package installed. The console notification looks similar the post-obit:

ABRT has detected 1 trouble(southward). For more than info run: abrt-cli list --since 1398783164

To view detected problems, enter the abrt-cli listing command:

~]$              abrt-cli list              id 6734c6f1a1ed169500a7bfc8bd62aabaf039f9aa Directory:   /var/tmp/abrt/ccpp-2014-04-21-09:47:51-3430 count:     i executable:   /usr/bin/slumber package:    coreutils-8.22-11.el7 time:      Monday 21 Apr 2014 09:47:51 AM EDT uid:      chiliad Run 'abrt-cli report /var/tmp/abrt/ccpp-2014-04-21-09:47:51-3430' for creating a case in Red Chapeau Customer Portal

Each crash listed in the output of the abrt-cli listing command has a unique identifier and a directory that can be used for further manipulation using abrt-cli.

To view information most just one particular trouble, use the abrt-cli info control:

              abrt-cli info -d directory_or_id

To increase the amount of information displayed when using both the list and info sub-commands, laissez passer them the -d (--detailed) option, which shows all stored information near the problems listed, including corresponding backtrace files if they have already been generated.

To analyze and report a sure problem, use the abrt-cli written report command:

              abrt-cli report directory_or_id

Upon invocation of the above command, yous will exist asked to provide your credentials for opening a support case with Scarlet Hat Customer Support. Next, abrt-cli opens a text editor with the content of the report. You can run across what is beingness reported, and y'all can fill in instructions on how to reproduce the crash and other comments. You should also cheque the backtrace because the backtrace might be sent to a public server and viewed past anyone, depending on the problem-reporter event settings.

You tin cull which text editor is used to check the reports. abrt-cli uses the editor divers in the ABRT_EDITOR environment variable. If the variable is not defined, information technology checks the VISUAL and EDITOR variables. If none of these variables is set, the vi editor is used. You tin can set up the preferred editor in your .bashrc configuration file. For example, if y'all prefer GNU Emacs , add the post-obit line to the file:

export                VISUAL=emacs              

When you are done with the report, save your changes and shut the editor. If y'all have reported your problem to the Reddish Hat Customer Support database, a problem case is filed in the database. From at present on, yous volition exist informed about the problem-resolution progress via email you provided during the procedure of reporting. You can also monitor the problem case using the URL that is provided to you when the problem instance is created or via emails received from Scarlet Lid Support.

If you are certain that you do not want to study a item problem, yous can delete it. To delete a problem, and so that ABRT does not keep information about it, use the command:

              abrt-cli rm directory_or_id

To display help near a particular abrt-cli command, use the --assist pick:

              abrt-cli                                  command                                --help            

25.5.ii. Using the GUI

The ABRT daemon broadcasts a D-Coach message whenever a problem report is created. If the ABRT applet is running in a graphical desktop environment, it catches this message and displays a notification dialog on the desktop. You lot tin open the ABRT GUI using this dialog by clicking on the Report button. You can also open up the ABRT GUI by selecting the → → → → → → menu item.

Alternatively, you can run the ABRT GUI from the command line as follows:

~]$              gnome-abrt &            

The ABRT GUI window displays a list of detected issues. Each problem entry consists of the proper name of the failing awarding, the reason why the application crashed, and the date of the concluding occurrence of the problem.

Figure 25.3. ABRT GUI

To access a detailed problem description, double-click on a problem-report line or click on the Written report button while the respective problem line is selected. Yous tin then follow the instructions to proceed with the process of describing the trouble, determining how it should be analyzed, and where it should exist reported. To discard a problem, click on the Delete button.

25.vi. Additional Resources

For more information about ABRT and related topics, come across the resources listed beneath.

Installed Documentation

• abrtd (8) — The manual page for the abrtd daemon provides information nearly options that tin exist used with the daemon.
• abrt_event.conf (5) — The manual page for the abrt_event.conf configuration file describes the format of its directives and rules and provides reference information nearly upshot meta-information configuration in XML files.

Online Documentation

• Red Hat Enterprise Linux 7 Networking Guide — The Networking Guide for Ruddy Hat Enterprise Linux vii documents relevant information regarding the configuration and administration of network interfaces and network services on this organisation.
• Red Chapeau Enterprise Linux 7 Kernel Crash Dump Guide — The Kernel Crash Dump Guide for Ruby Lid Enterprise Linux vii documents how to configure, exam, and use the kdump crash recovery service and provides a cursory overview of how to analyze the resulting core dump using the crash debugging utility.

See Also

• Chapter 23, Viewing and Managing Log Files describes the configuration of the rsyslog daemon and the systemd periodical and explains how to locate, view, and monitor system logs.
• Chapter 9, Yum describes how to utilize the Yum package manager to search, install, update, and uninstall packages on the command line.
• Chapter 10, Managing Services with systemd provides an introduction to systemd and documents how to employ the systemctl command to manage system services, configure systemd targets, and execute power management commands.

wadeclavory.blogspot.com

Source: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/ch-abrt

Share this post