abrt linux что это такое

Automatic Bug Reporting Tool

If you are interested in helping developers to prioritize their work and you want provide anonymous report please turn on the auto reporting of micro-reports using

Read the micro-report online documentation and abrt-auto-reporting(1) for details.

1. ABRT workflow

2. ABRT architecture

Upon a detection of a problem, ABRT creates a directory in a well known path and puts all the gathered data into that directory in form of regular files.

The well known path where the problem directories are created is:

/var/spool/abrt (CentOS 6)

And the most interesting files within a problem directory follows:

absolute path to an executable file experienced this problem

rpm package which the executable belongs to

number of times this problem has been encountered on a system

unix timestamp of the first occurrence of this problem

a core dump file for crashes of compiled programs (C/C++)

list of the active function calls

list of dynamic libraries loaded at the time of crash

lines from the system logs related to this problem

In case you want to examine the problem directory manually or you just want to know what the problem is about, ABRT provides you with several tiny utilities doing useful stuff. All the utilities have a name prefixed with «abrt-action», thus you can change the current working directory to a problem directory, type abrt-action and hit Tab key.

3. An example of getting backtrace from ‘coredump’ file:

ABRT does not extract backtrace from a core dump file automatically, because this task requires the debug info data to be available.

You can install the debug info data manually via the debuginfo-install command suggested by gdb:

or you can let ABRT to do all the necessary work instead of you:

abrt-action-analyze-ccpp-local enables all *debug* yum repositories, downloads the missing debug info packages, unpacks them in /var/cache/abrt-di/, runs gdb and stores its output in backtrace file.

However, ABRT allows users to work with the problems in a more comfortable way through its command line (abrt-cli) and graphical (gnome-abrt) interfaces.

4. Notifications

ABRT provides several configurable ways of notifying users about a crash on the OS. The default notification is desktop notification, email sent to root user (using default MTA, settings can be modified in /etc/libreport/events.d/mailx_event.conf) and console notification such as

5. Installation

Run the following command on headless systems:

or the following for desktops

abrt-cli and abrt-desktop are meta-packages pulling all the most useful packages into your system.

6. Configuration

The configuration files are stored in:

The configuration option values that you provide to the ABRT GUI are stored in GNOME Keyring.

7. Reporting to CentOS Bug Tracker

Starting with CentOS 7.1.1503, ABRT can report the crashes to bugs.centos.org. To be able to file a bug report, you have to create your own account at bugs.centos.org and provide your account details to ABRT when it prompts you for them before submitting the bug report.

This functionality also requires backtrace generated from the coredump. ABRT is capable of generating the backtrace either locally, which involves downloading debuginfo packages to /var/cache/abrt-di, or remotely to https://fedorahosted.org/abrt/wiki/AbrtRetraceServer, which involves uploading the coredump file to the Internet.

ABRT provides you with these two options to generate the backtrace because the coredump file might contain security sensitive information and the local backtrace generation might require downloading of GiBs of debug info packages. However, the retrace server has been developed with focus on security and its benefit for the users is highly appreciated.

Because the bug reports filed by ABRT are public and the crash data often contains security sensitive information such as passwords, the reporting process includes two steps of reviewing the published data. In the first step ABRT highlights «suspicious» strings and you can also search for your custom strings. In the second step you can exclude files from the published data set.

8. Automatic crash statistics submission

Besides the detection of problems and the creation of comprehensive bug reports, ABRT provides a functionality to automatically submit a short, anonymous description of a crash which is called micro-Report (uReport) at the time of crash detection.

Micro-reports are anonymous, they don’t carry any information about IP address, host-id, hostname, or even memory and filesystem snapshots. The content of the micro-report is stripped to bare minimum to allow finding duplicates on the server side.

The ABRT server collects micro-Reports to provide developers with the crash statistics useful for prioritization of their work.

This functionality of ABRT can be enabled by issuing the following command:

In the default configuration, ABRT sends the crash statistics data to the ABRT server

9. References

For more details about how ABRT works follow this link: http://abrt.readthedocs.org/en/latest/

If something does not work for you, you may find an answer at: http://abrt.readthedocs.org/en/latest/faq.html

If you are interested in more advanced ABRT capabilities, checkout the examples page at: http://abrt.readthedocs.org/en/latest/examples.html

The ABRT project lives on github.com: https://github.com/abrt

TipsAndTricks/ABRT (последним исправлял пользователь анонимно 2019-12-09 09:11:35)

Источник

8.14 Настройка службы abrtd

Abrtd (automatic bug reporting tool) — программа для сбора информации при аварийном завершении программы. Может отправлять уведомления об ошибках на почту.

Для установки воспользуйтесь утилитой yum или dnf, в зависимости от используемой версии системы:
для РЕД ОС версии 7.1 или 7.2:

для РЕД ОС версии 7.3 и старше:

Добавьте программу в автозапуск и запустите ее:

Отредактируйте параметр MaxCrashReportsSize, отвечающий за размер отчета об ошибках, в файле /etc/abrt/abrt.conf, заменив значение по умолчанию на 0 (снимает ограничение на размер):

WatchCrashdumpArchiveDir — автораспаковка архивов с отчетами об ошибках в указанную директорию.

DumpLocation — путь до места, куда следует сохранять отчеты об ошибках. Не должен совпадать с путем из WatchCrashdumpArchiveDir.

Если хотите их изменить, разрешите утилите записывать данные:

Отредактируйте файл /etc/abrt/abrt-action-save-package-data.conf изменив следующие параметры:

OpenGPGCheck — обрабатывать ошибки пакетов, не подписанных GPG-ключом.

ProcessUnpackaged — обрабатывать ошибки файлов, не принадлежащих пакетам rpm.

Также можно изменить следующие параметры:

BlackList — приложения, чьи ошибки не стоит обрабатывать.

BlackListedPaths — исполняемые файлы, чьи ошибки не стоит обрабатывать.

После правки описанных выше файлов, перезапустите утилиту.

По умолчанию, отчеты об ошибках будут хранится по этому пути: /var/spool/abrt/

Настройка отправки уведомлений на почту

Для отправки уведомлений об ошибках на почту добавьте обработчик событий в файл /etc/libreport/events.d/abrt_event.conf

И отредактируйте следующие строки в файле /etc/libreport/plugins/mailx.conf

Если вы нашли ошибку, пожалуйста, выделите текст и нажмите Ctrl+Enter.

Источник

Навигация по файлам и директориям

В прошлый раз мы хаотично вводили текст в командную строку Linux и получали сообщения об ошибках. Все это время мы находились внутри домашнего каталога. Сегодня мы попытаемся разобраться как перемещаться по папкам при помощи команд и просматривать их содержимое.

Но для начало необходимо понять устройство файловой структуры Linux. Она представляет собой иерархическую структуру. То есть файловая система организована на подобии директорий (они же папки и каталоги), в которых расположены иные директории и файлы. Верхняя директория файловой системы называется корневой директорией. Внутри корневой директории расположены файлы и директории, которые содержат файлы и директории.

В графическом интерфейсе структура директорий выглядит следующим образом.

В отличии от файловой организации Windows, где корневыми директориями являются диски, в Linux есть единственное дерево и только одна корневая директория, которая не ассоциируется с каким либо физическим дисковым устройством. Различные диски могут быть подключены как поддеревья (директории) внутри этого дерева.

Разморозим нашу виртуальную машину и сделаем первые шаги в освоении организации файловой структуры Linux 🙂

Рабочая директория и её содержание

Так как интерфейс командной строки не может графически показать файловую структуру, существует иной способ ее представления. Представим, что дерево файлов является лабиринтом, в котором мы находимся. В каждый момент мы находимся в одной из директорий данного лабиринта. Внутри нее мы видим путь к родительской директории, файлы и пути во вложенные директории.

Директория в которой мы находимся называется рабочей директорией. Чтобы узнать имя рабочей директории, воспользуемся командой pwd (print working directory — вывести рабочую директорию).

Введем команду pwd в окно терминала.

Источник

Chapter 28. Automatic Bug Reporting Tool (ABRT)

Important

Table 28.1. Basic ABRT components

Note

28.1. Installing ABRT and Starting its Services

Warning

Figure 28.1. Setting ABRT notification applet to run automatically.

Источник

Abrt linux что это такое

Автор: Станислав Лапшанский, slapsh@slapsh.pp.ru
Опубликовано: 2.7.2002

2002, Издательский дом «КОМПЬЮТЕРРА» | http://www.computerra.ru/
Журнал «СОФТЕРРА» | http://www.softerra.ru/
Этот материал Вы всегда сможете найти по его постоянному адресу:═ http://www.softerra.ru/freeos/18735/

В первой части статьи мы узнали что представляют из себя процессы, а так же как посмотреть список запущенных процессов на вашей FreeBSD. В этой части мы узнаем как процессы общаются между собой, как вы можете что-нибудь передать процессу и зачем вам это может понадобиться.

Ход общения процессов называется межпроцессным взаимодействием. Процессы не имеют права просто передавать что-нибудь кому-нибудь. В FreeBSD существует 31 предопределенное сообщение. Эти сообщения называются сигналами. Вы можете посмотреть список сигналов набрав:

Каждый сигнал имеет номер, и в этом списке они перечислены в порядку номеров. Таким образом HUP=1, INT=2 и т.д. Процесс может посылать эти сигналы другим процессам. Пользователи могут тоже самое.

Для того, что бы понять, что означает каждый из этих сигналов наберите man 2 sigaction или man 3 signal. Следующая ниже таблица кратко описывает каждый из 31 сигналов, а также результаты их применения. Поскольку пользователи так же могут посылать любые из этих сигналов, рядом с наиболее часто используемыми сигналами я поставил звездочку.

Символ «^» означает что вы должны нажать клавишу «ctrl», а затем указанную за ним букву. Обратите внимание, что три сигнала были привязаны к управляющим последовательностям:

Не путайте слово «kill» в выводе команды stty с сигналом KILL (сигнал 9). Комбинация ^U удаляет строку, а не шлет сигнал номер 9. Для того что бы в этом убедиться, напечатайте в командной оболочке длинную строку, а затем нажмите ^U.

Но как послать сигнал, который не имеет соответствующей комбинации клавиш? Используйте для этого команду kill.

Есть пара способов использования команды kill. Если вы просто напечатаете:

то по умолчанию процессу с идентификатором PID будет послан сигнал TERM. Если вы хотите послать какой-нибудь другой сигнал, то в команде укажите его название или номер:

Таким образом команды

эквивалентны. Не забывайте, что в UNIX имеет значение регистр набранных команд, если вы напечатаете:

то получите следующее сообщение об ошибке:

Итак теперь мы знаем о каждом из 31 возможных сообщений, а так же можем посылать их различным процессам. Давайте рассмотрим причины, по которым вам может потребоваться послать процессу сигнал. Когда вы прорабатываете какой-нибудь вопрос используя FreeBSD Handbook или другое руководство, их авторы часто обучают как и что менять в тех или иных конфигурационных файлах, а затем говорят вам о необходимости послать сигнал HUP. Дело в том, что большинство процессов прочитывают свои конфигурационные файлы только при первоначальном запуске. Сигнал HUP говорит процессу, что он должен прекратить выполнение. После того как процесс перезапустится, он перечитает конфигурационные файлы и внесенные в них изменения вступят в силу. Аналогичным образом, когда вы выходите командой logout из терминала, сигнал HUP рассылается всем процессам, которые были запущены на этом терминале. Это значит, что все процессы которые выполнялись на этом терминале будут остановлены.

Иногда вы можете запустить процесс и захотеть его остановки, до того, как он завершится в штатном режиме. Например в приливе вдохновения вы можете решить, что вам необходимо посмотреть имена всех файлов в вашей системе. Это можно сделать написав следующее:

Однако, вероятнее всего вы быстро утомитесь нажимать пробел и поймете, что на самом деле вам вовсе не хочется в данный момент просматривать список всех ваших файлов. Другими словами вам захочется подать прерывающий сигнал. Один из путей сделать это, нажать на терминале «Ctrl+C»:

То, что на вашем терминале появится приглашение интерпретатора команд, свидетельствует о том, что посланный вами сигнал INT сработал.

Опять выполните ту же самую команду find, но в этот раз пошлите сигнал 3, нажав на клавиатуре «Ctrl+\»:

Теперь, перед тем, как вы получите приглашение интерпретатора команд, вы увидите следующее сообщение:

Если вы воспользуйтесь комбинацией Alt+F1, что бы посмотреть сообщения системной консоли, там вы увидите сообщение примерно следующего содержания:

Если теперь вы вернетесь на предыдущий терминал и посмотрите список файлов в каталоге, среди прочего вы обязательно найдете файл more.core. Обычно вам никогда не потребуется посылать процессу сигнал номер 3, если конечно вы не программист, который знает как использовать отладчик ядра. Я включил этот пример в статью для того что бы показать разницу между сигналами 2 и 3. Удаляйте core-файлы без опаски.

Однако при повторе команды ps вы опять обнаружили этот процесс в списке, а это значит, что по каким-то причинам сигнал TERM был проигнорирован. Любая из этих двух команд исправит ситуацию:

Если вы теперь повторите команду ps, то вы должны будете получить пустой список, что свидетельствует об успешном останове процесса.

Может возникнуть ситуация, когда вам захочется остановить все принадлежащие вам процессы. Результаты этого действия будут отличаться в зависимости от того находитесь ли вы в системе как обычный или как суперпользователь.

Продемонстрируем это. Войдите в систему на другом терминале и введите команду ps:

А теперь проверим результаты, воспользовавшись командой ps:

Обратите внимание, что если вы допустите ошибку при наборе команды и напишете:

то вы получите сообщение об ошибке:

Теперь давайте поглядим что произойдет, если мы повторим то же упражнение, но только от имени суперпользователя. Для начала на моем тестовом компьютере (где выполняются следующие программы: apache, mysql, squid, nfs и т.п.) я выполню команду ps:

Эта команда произвела на меня большее впечатление чем предыдущая, поскольку я был выкинут из командного интерпретатора в котором только что набрал команду kill. После того, как я опять вошел в систему, я определил масштаб разрушений следующим образом:

Это является одной из причин, по которой только суперпользователь может выполнять команды reboot и halt. Когда одна из этих команд запускается на выполнение, то всем процессам рассылается сигнал TERM, для того что бы дать им шанс для сохранения данных, поскольку за сигналом TERM, через некоторое время, следует сигнал KILL, который посылается для того что бы гарантированно уничтожить все процессы.

В следующей статье я продолжу эту тему, заострив внимание на процессах init и getty.

Источник