Что такое abrt и процесс abrt-action-generate-core-backtrace?
Это распространено в большом количестве команд Unix.
Первоначальное расследование
Я проверил для наблюдения, какого RPMs это приложение было частью.
Описание того пакета следующие:
Этот пакет содержит рычаг для разрушенных программ C/C++ и C/C++ abrt
Об/мин также упоминает этот URL: https://fedorahosted.org/abrt/. Тот URL берет Вас к странице, которая утверждает, что это является устаревшим, направляя Вас теперь к странице GitHub: https://github.com/abrt/abrt/wiki/ABRT-Project.
Это продолжает также описывать это следующим образом:
ABRT состоит из демона, который контролирует журналы, системные катастрофические отказы и инициировал события на основе типа катастрофического отказа. Также предоставляет настольное уведомление, которые раскрываются во время катастрофического отказа. Пользователь может работать с гномом-abrt, GUI, который представляет список катастрофических отказов и доступных действий или abrt-cli, интерфейса командной строки со схожей функциональностью.
Страница обзора перечисляет следующие функции демона ABRT, что она автоматически обнаружит проблемы для и автоматически сообщит, входит к «где-нибудь».
Таким образом, что это делало?
Файл на сегодняшний день, last-ccpp был бы вероятный кандидат на какой abrt. составил. Тот файл не был большим количеством справки.
Страница обзора затем показала снимок экрана, что я действительно распознавал. Таким образом, я думаю, уничтожая abrt. процесс не является большой частью риска вообще.
Итак, вы успешно установили дистрибутив Linux Mint, Ubuntu или Fedora Workstation, провели его оптимизацию, но он все равно медленно загружается. Конечно же, можно просто смириться с этим, ведь время загрузки системы не является определяющим фактором при работе с ней, но если вы обладаете опытом работы с Linux и не боитесь использовать терминал, вы можете провести небольшую дополнительную оптимизацию процесса ее загрузки, заключающуюся в отключении неиспользуемых системных служб. Так как во всех упомянутых дистрибутивах с недавнего времени используется менеджер инициализации systemd, процесс их настройки будет практически идентичным. Различия в данном случае будут заключаться в наборе активированных по умолчанию системных служб.
1. Ознакомление со списком активированных системных служб
Для того, чтобы получить список активированных по умолчанию системных служб, следует открыть окно терминала и ввести в него следующую команду (используйте функции копирования/вставки, чтобы не ошибиться при вводе):
После окончания ввода команды следует нажать клавишу Enter для ее исполнения. В результате вы получите список активированных системных служб в следующем формате:
В зависимости от используемого дистрибутива, данный список может быть достаточно длинным, поэтому он был сокращен. Вам придется деактивровать лишь те службы, которые не используются в вашем случае. Но что делать в том случае, если вы не знаете назначения каждой из служб? Ну, вы можете просто воспользоваться приведенным ниже списком служб, которые могут быть максимально безболезненно деактивированы.
Предупреждение: если вы не знаете о назначении службы или не уверены в необходимости ее использования, не совершайте с этой службой никаких манипуляций, ведь в случае ошибки вам придется восстанавливать работоспособность системы вручную.
2. Деактивация системных служб
Для деактивации системной службы следует использовать последовательность из двух команд:
Так как некоторые деактивированные службы могут активироваться другими службами, в некоторых случаях для принудительной деактивации службы вам также придется использовать следующую команду:
Для того, чтобы проверить текущее состояние службы достаточно выполнить следующую команду:
В результате исполнения данной команды вы получите аналогичный вывод:
Из данного вывода очевидно, что служба активирована (enabled во второй строке), а также активна и исполняется (active (running) в третьей строке).
Совет: в некоторых материалах после деактивации системных служб рекомендуют удалять соотвествующие пакеты программного обеспечения. Я не рекомендую делать этого, так как каждая из деактивированных служб может понадобиться вам в любой момент.
3. Восстановление работоспособности системных служб
Если вы по ошибке деактивировали системную службу и желаете отменить это действие, вам придется выполнить ее повторную активацию с помощью следующей последовательности команд:
Разумеется, первая команда должна исполняться лишь в том случае, если вы осуществляли принудительную деактивацию системной службы.
4. Системные службы, которые стоит деактивировать
Ниже приведен список системных служб, которые вы можете относительно безболезненно деактивировать. В зависимости от используемого дистрибутива, вы можете не обнаружить некоторые из упомянутых служб в списке активированных, поэтому стоит деактивировать лишь те службы, которые активированы в вашем дистрибутиве.
A. Планировщики событий
Данные службы предназначены для выполнения заданных действий в определенное время или через определенные промежутки времени. В большинстве случаев они могут быть безболезненно деактивированы.
B. Службы поддержки печати
Данные службы ответственны за обнаружение и работу с принтерами. Если у вас нет принтера, можете смело деактивровать их.
C. Служба поддержки широкополносных беспроводных устройств
Данная служба позволяет использовать 2G/3G/4G модемы. Если вы не используете подобные устройства, можете деактивирвать ее.
D. Службы поддержки логических виртуальных томов и RAID-массивов
Данные службы должны использоваться лишь в том случае, если при установке системы жесткие диски были использованы для создания логических виртуальных томов или RAID-массивов. Если вы не создавали их (что рекомендуется), вам не понадобятся все эти службы.
E. Служба поддержки устройств Bluetooth
Данная служба позволяет работать с устройствами Bluetooth. Если вы не используете таких устройств, можете деактивировать ее.
F. Службы отправки информации о системных сбоях
Данные службы предназначены для сбора информации о системных сбоях и ее передачи разработчикам дистрибутива. Если вы не желаете активно участвовать в процессе разработки дистрибутива, вы можете деактивировать данные службы.
G. Служба для людей с ограниченными возможностями
Данная служба предназначена для работы с устройствами, позволяющими использовать шрифт Брайля для слабовидящих людей. Если вы не пользуетесь такими устройствами, вы можете деактивировать ее.
H. Служба обнаружения сетевых устройств
Данная служба позволяет осуществлять автоматическое распространение информации о сетевых устройствах в локальной сети. Если вы не пользуетесь ею, можете также деактивировать ее.
I. Службы поддержки виртуальных машин
Данные службы используются для работы с виртуальными машинами (обычно посредством приложения Boxes). Если вы не используете виртуальные машины для запуска операционных систем, вы можете деактивировать их.
После деактивации описанных системных служб следует перезагрузить компьютер. Теперь он должен немного быстрее загружаться.
ABRT consists of the abrtd daemon and a number of system services and utilities for processing, analyzing, and reporting detected problems. The daemon runs silently in the background most of the time 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’s 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 Ruby programming languages, as well as X.Org crashes, kernel oopses, and kernel panics. See Section 25.4, “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.
Note that ABRT report is generated only when core dump is generated. Core dump is generated only for some signals. For example, SIGKILL (-9) does not generate core dump, so ABRT cannot catch this fail. For more information about signals and core dump generating, see man 7 signal.
25.2. Installing ABRT and Starting its Services
Please note that installing the ABRT packages overwrites the /proc/sys/kernel/core_pattern file, which can contain a template used to name core-dump files. The content of this file will be overwritten to:
See Section 9.2.4, “Installing Packages” for general information on how to install packages using the Yum package manager.
25.2.1. Installing the ABRT GUI
The ABRTgraphical user interface provides an easy-to-use front end for working in a desktop environment. You can install the required package by running the following command as the root user:
Upon installation, the ABRT notification applet is configured to start automatically when your graphical desktop session starts. You can verify that the ABRT applet is running by issuing the following command in a terminal:
If the applet is not running, you can start it manually in your current desktop session by running the abrt-applet program:
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 package by running the following command as the root user:
25.2.3. Installing Supplementary ABRT Tools
By 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-console-notification package as well.
ABRT can detect, analyze, and report various types of software failures. By default, ABRT is installed with support for the most common types of failures, such as crashes of C and C++ applications. Support for other types of failures is provided by independent packages. For example, to install support for detecting exceptions in applications written using the Java language, run the following command as root :
See Section 25.4, “Detecting Software Problems” 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 various types of failures.
25.2.4. Starting the ABRT Services
The abrtd daemon requires the abrt user to exist for file system 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, any UID and GID can be chosen, because abrtd does not require a specific UID and GID.
The abrtd daemon is configured to start at boot time. You can use the following command to verify its current status:
You can use the same commands to start or check status of related error-detection services. For example, make sure the abrt-ccpp service is running if you want ABRT to detect C or C++ crashes. See Section 25.4, “Detecting Software Problems” for a list 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 boot time when their respective packages are installed. You can disable or enable any ABRT service by using the systemctl utility as described in Chapter 10, Managing Services with systemd.
25.2.5. Testing ABRT Crash Detection
To test that ABRT works properly, use the kill command to send the SEGV signal to terminate a process. For example, start a sleep process and terminate it with the kill command in the following way:
ABRT detects a crash shortly after executing the kill command, and, provided a graphical session is running, the user is notified of the detected problem by the GUI notification applet. On the command line, you can 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. See Section 25.5, “Handling Detected Problems” for more information on how to work with detected crashes.
25.3. Configuring ABRT
After the problem-data directory is created and problem data gathered, you can process the problem using either the ABRT GUI, or the abrt-cli utility for the command line. See Section 25.5, “Handling Detected Problems” for more information about the ABRT tools provided for working with recorded problems.
25.3.1. Configuring Events
ABRT events use plugins to carry out the actual reporting operations. Plugins are compact utilities that the events call to process the content of problem-data directories. Using plugins, ABRT is capable of reporting problems to various destinations, and almost 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.
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 pass it to the events they run.
Figure 25.1. Configuring ABRT Events
Table 25.1. Standard ABRT Events
Uploads a μReport to the FAF server.
Sends the problem report via the Mailx utility to a specified email address.
Reports the problem to the specified installation of the Bugzilla bug tracker.
Red Hat Customer Support
Reports the problem to the Red Hat Technical Support system.
Analyze C or C++ Crash
Sends the core dump to a remote retrace server for analysis or performs a local analysis if the remote one fails.
Runs the GDB (the GNU debugger) on the problem data of a kernel oops and generates a backtrace of the kernel.
Local GNU Debugger
Runs GDB (the GNU debugger) on the problem data of an application and generates a backtrace of the program.
Saves relevant lines from the
/.xsession-errors file to the problem report.
Creates a problem report and saves it to a specified local file.
Sends a kernel problem to the oops tracker at kerneloops.org.
25.3.2. Creating Custom Events
Each rule starts with a line with a non-space leading character, and all subsequent lines starting with the space character or the tab character are considered a part of this rule. Each rule consists of two parts, a condition part and a program part. The condition part contains conditions in one of the following forms:
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 event example:
This event would overwrite the contents of the /tmp/dt file with the current date 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 event, which is actually one of the predefined events. It saves relevant lines from the
/.xsession-errors file to the problem report of any 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:
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:
…where name_suffix is the adjustable part of the event name. This event is used to collect additional information on problems.
…where name_suffix is the adjustable part of the event name. This event is used to report a problem.
25.3.3. Setting Up Automatic Reporting
Figure 25.2. Configuring ABRT Problem Reporting
Upon detection of a crash, by default, ABRT submits a μReport with basic information about the problem to Red Hat’s ABRT server. The server determines whether the problem is known and either provides a short description of the problem along with a URL of the reported case if known, or invites the user to report it if not known.
A μReport (microreport) is a JSON object representing a problem, such as a binary crash or a kernel oops. These reports are designed to be brief, machine readable, and completely anonymous, which is why they can be used for automated reporting. The μReports make it possible to keep track of bug 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, modify the value of the AutoreportingEvent directive in the /etc/abrt/abrt.conf configuration file to point to a different ABRT event. See Table 25.1, “Standard ABRT Events” for an overview of the standard events.
25.4. Detecting Software Problems
Table 25.2. Supported Programming Languages and Software Projects
abrt-addon-ccpp
abrt-addon-python
rubygem-abrt
abrt-java-connector
abrt-addon-xorg
abrt-addon-kerneloops
Linux (kernel panic)
abrt-addon-vmcore
Linux (persistent storage)
abrt-addon-pstoreoops
25.4.1. Detecting C and C++ Crashes
25.4.2. Detecting Python Exceptions
In the above command, replace file.py with the name of the Python script you want to execute without the use of site-specific modules.
25.4.3. Detecting Ruby Exceptions
The rubygem-abrt package registers a custom handler using the at_exit feature, which is executed when a program ends. This allows for checking for possible unhandled exceptions. Every time an unhandled exception is captured, the ABRT handler prepares a bug report, which can be submitted to Red Hat Bugzilla using standard ABRT tools.
25.4.4. Detecting Java Exceptions
25.4.5. Detecting X.Org Crashes
The abrt-xorg service collects and processes information about crashes of the X.Org server from the /var/log/Xorg.0.log file. Note that no report is generated if a blacklisted X.org module is loaded. Instead, a not-reportable file is created in the problem-data directory with an appropriate explanation. You can find the list of offending modules in the /etc/abrt/plugins/xorg.conf file. Only proprietary graphics-driver modules are blacklisted by default.
25.4.6. Detecting Kernel Oopses and Panics
By 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 also 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 core-dump file is found, abrt-vmcore creates a new problem-data directory in the /var/spool/abrt/ directory and copies the core-dump file to the newly created problem-data directory. After the /var/crash/ directory is searched, the service is stopped.
25.5. Handling Detected Problems
Note that ABRT identifies duplicate problems by comparing new problems with all locally saved problems. For a repeating crash, ABRT 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, ABRT will treat it as a new crash: ABRT will alert you about it, prompt you to fill in a description, and report it. To avoid having ABRT notifying you about a recurring problem, do not delete its problem 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 like the following:
To view detected problems, enter the abrt-cli list command:
To view information about just one particular problem, use the abrt-cli info command:
To analyze and report a certain problem, use the abrt-cli report command:
Upon invocation of the above command, you will be asked to provide your credentials for opening a support case with Red Hat Customer Support. Next, abrt-cli 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.
When you are done with the report, save your changes and close the editor. If you have reported your problem to the Red Hat Customer Support database, a problem case is filed in the database. From now on, you will be informed about the problem-resolution progress via email you provided during the process of reporting. You can also monitor the problem case using the URL that is provided to you when the problem case is created or via emails received from Red Hat Support.
If you are certain that you do not want to report a particular problem, you can delete it. To delete a problem, so that ABRT does not keep information about it, use the command:
25.5.2. Using the GUI
The ABRT daemon broadcasts a D-Bus 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 can open the ABRT GUI using this dialog by clicking on the Report button. You can also open the ABRT GUI by selecting the Applications → → → Sundry → → Automatic Bug Reporting Tool → menu item.
Alternatively, you can run the ABRT GUI from the command line as follows:
The ABRT GUI 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.
Figure 25.3. ABRT GUI
To access a detailed problem description, double-click on a problem-report line or click on the Report button while the respective problem line is selected. You can then follow the instructions to proceed with the process of describing the problem, determining how it should be analyzed, and where it should be reported. To discard a problem, click on the Delete button.
25.6. Additional Resources
For more information about ABRT and related topics, see the resources listed below.
