ubuntu apport что это
Уведомление об ошибках в Ubuntu Server Edition
Содержание
View Report Выбор просмотра отчета приведет к показу собранной информации в терминал для повторного просмотра.
После просмотра отчета вы будете снова перенаправлены в меню с вопросом что вы собираетесь делать с отчетом.
Keep Report File Выбор сохранения файла отчета приведет к записи в файл собранной информации. Этот файл может быть использован для дальнейшей регистрации отчета об ошибке или передан для отчета иной Ubuntu системе. Чтобы передать файл отчета, просто укажите его в качестве аргумента команды ubuntu-bug:
Cancel Выбор отмены приведет к тому, что собранная информация будет сброшена.
Уведомление о крушениях приложений
Пакет программ, который предоставляет утилиту ubuntu-bug, apport может быть настроен на срабатывание при падении приложений. По умолчанию это отключено, поскольку захват падений может быть достаточно ресурсоёмким в зависимости от памяти, которую использовало упавшее приложение, а apport захватывает и обрабатывает память ядра.
Настройка apport на захват информации о падении приложений требует выполнения пары шагов. Сначала требуется установить gdb; он не устанавливается по умолчанию при установке Ubuntu Server Edition.
Смотрите раздел Управление пакетами для дополнительной информации об управлении пакетами в Ubuntu.
Как только вы убедитесь, что gdb установлен, откройте файл /etc/default/apport в вашем текстовом редакторе и измените настройку enabled в 1, как показано ниже:
Как только вы завершите редактирование /etc/default/apport, запустите сервис:
После падения приложения используйте команду apport-cli для поиска информации о сохраненном отчете падения:
Выбор Report Problem (сообщить о проблеме) проведет вас по шагам, аналогичным при использовании ubuntu-bug. Одним важным отличием будет то, что отчет о падении будет помечен как частный (private) при регистрации на Launchpad, что означает что он будет виден только ограниченному количеству сортировщиков. Эти сортировщики будут просматривать собранные данные на наличие частной информации перед тем как отчет об ошибке станет публично доступным.
Ссылки
Также смотрите страницу Apport для дополнительной полезной информации. Часть информации касается использования графического интерфейса.
Исправляем обнаружена ошибка в системной программе Ubuntu
Иногда после установки некоторых программ, обновлений или изменения настроек системы, мы можем начать получать уведомление об ошибке содержащее сообщение «Обнаружена ошибка в системной программе». Конечно, это сообщение можно игнорировать, но очень частое его появление со временем просто начинает раздражать.
Проблему, которая вызывает ошибку можно решить, но решение есть не всегда. Например, вы будете не очень рады когда увидите вот такое сообщение при каждом входе в систему после неправильного монтирования диска:
Обнаружена ошибка в системной программе
Сообщить о проблеме разработчикам?
Хотя если вы не используете Ubuntu, вы точно никогда не столкнетесь с такой проблемой. В этой статье мы рассмотрим что же делать с уведомлением обнаружена ошибка в системной программе в Ubnutu 16.04 или других версий.
Что делать если возникла «обнаружена ошибка в системной программе»
Что это вообще значит?
В основном это означает что в вашей системе произошел сбой. Но не беспокойтесь, это не очень критическая проблема и систему по-прежнему можно использовать. Просто одна программа неожиданно завершилась и Ubuntu спрашивает вас не хотите ли вы отправить отчет об ошибке разработчикам чтобы те смогли исправить проблему.
Canonical использует специальную утилиту Apport, которая собирает данные об ошибках в системе и отправляет их разработчикам. Как только какая-нибудь программа в системе завершается с сигналом SIGSEGV, SIGBUS, SIGFPE или другим, вызывающим ошибку, запускается демон Apport, собирает данные об ошибке и компьютере, затем создает crash файл в каталоге /var/crash. Информация из этого файла поможет разработчикам решить проблему. С другой стороны, когда в этом каталоге появляется новый файл, запускается графическая утилита, которая показывает информацию об ошибке и предложение отправить отчет разработчикам.
Если в других дистрибутивах такая ошибка не наблюдается, это еще не значит что дистрибутив стабильнее и программы не падают. Просто там некому палить такое их поведение.
Как только я нажму сообщить о проблеме, она исчезнет?
Нет, не совсем. После того как вы нажмете на кнопку отправки отчета, вы получите следующее окно:
Утилита Apport соберет всю возможную информацию об ошибке, затем откроется браузер где вы сможете оформить отчет, используя свою или создав новую учетную запись Launchpad. Как вы видите это сложная процедура, которая займет около четырех шагов.
Кроме того, возможно, вы сможете решить проблему сами, если это не баг в программе, а ошибка, вызванная тем, что вы что-то неправильно установили. Посмотрите подробности (Show details) об ошибке в этом окне и попытайтесь сами или с помощью поисковых систем решить что с ней делать.
А если я хочу сообщить разработчикам о проблеме?
Это очень мило с вашей стороны. Вы поступаете правильно, но есть два но. Во-первых есть вероятность что кто-то уже сообщил об этой проблеме. Во-вторых, даже если вы сообщите разработчикам, это не гарантирует что вы не увидите ошибку снова. Точнее, наоборот, если программа падает регулярно, вы будете видеть это сообщение постоянно, пока с этим что-то не сделаете. Конечно, можно установить галочку не показывать больше для этой программы, но если программы разные, этот путь не поможет.
Вы предлагаете не сообщать о проблеме?
И да, и нет. Сообщите об ошибке когда увидите ее впервые если хотите. Информацию об ошибке вы можете увидеть, нажав кнопку Show details, как на картинке выше. Но если вы сталкиваетесь с ошибкой повторно и не можете ее решить или не хотите сообщать разработчикам советую вам избавиться от нее навсегда.
Исправляем проблему обнаружена ошибка в системной программе
Отчеты об ошибках хранятся в каталоге /var/crash. Если вы посмотрите содержимое этого каталога, можете увидеть там несколько файлов с данными о предыдущих ошибках.
Отчеты о сбоях лучше удалить, так как со временем они будут накапливаться и занимать дисковое пространство. Для этого выполните команду:
Теперь у вас не останется данных о прежних сбоях, но если сбой произойдет снова, вы опять увидите то сообщение. Можно каждый раз удалять отчеты, но лучше отключить Apport (отладочный инструмент) и навсегда забыть о всплывающих окнах.
Отключение Apport в Ubuntu
Если вы это сделаете, вы больше не получите ни одного сообщения о неожиданном завершении программы в вашей системе. По-моему это не так уж плохо, если вы не отправляете отчеты об ошибках. Если вы не готовы отправлять отчеты об ошибках, то отсутствие уведомлений о сбоях не будет иметь никакого значения.
Вы можете отключить только утилиту, которая показывает вам уведомления, но оставить службу, собирающую данные в /var/crash работающей. Для этого выполните:
gsettings set com.ubuntu.update-notifier show-apport-crashes false
Для полного отключения Apport откройте терминал и введите команду:
gksu gedit /etc/default/apport
Вот содержимое этого файла:
set this to 0 to disable apport, or to 1 to enable it
# you can temporarily override this with
# sudo service apport start force_start=1
enabled=1
Замените enable=1 на enable=0 и сохраните изменения. Теперь вы не увидите никаких отчетов о сбоях в программах. Программа не будет собирать отчеты об ошибках и вы о них никогда не узнаете. Если вы снова захотите видеть уведомления достаточно просто вернуть флаг enabled в положение 1.
Выводы
Надеюсь, эта статья помогла вам решить проблему обнаружена ошибка в системной программе Ubuntu 16.04. Конечно, это только косметическое решение, и от этого программа не перестанет аварийно завершаться, но большинство из нас обычные пользователи и мы не можем понять почему не работает та или иная программа. Нам остается только сообщить разработчикам, и отключить уведомления дабы они не мешали нормально работать.
Что означает ошибка и почему она продолжает появляться при запуске? Я сообщил об ошибке, но ничего не изменилось.
Ubuntu имеет программу под названием Apport, которая отвечает за обнаружение таких сбоев и, с согласия пользователя, сообщает об этих сбоях разработчикам. Этот процесс предназначен для решения проблемы разработчиков.
Однако это может быть очень раздражающим для обычных пользователей, и нет смысла показывать ошибки пользователям, когда они сами ничего не могут с этим поделать. Так что вы можете отключить их.
Система apport создает файлы отчетов о сбоях в каталоге / var / crash. Эти файлы отчетов об ошибках приводят к появлению сообщения об ошибке при каждой загрузке Ubuntu.
Выключить аппорт
Просто установите значение enabled в 0, и это отключит apport.
Сохраните файл и закройте его. Начиная со следующей загрузки, сообщений об ошибках не должно быть никогда. Если вы не хотите перезагружать систему, перезапустите apport из командной строки.
(Пишу новый ответ, потому что пока не могу комментировать.)
Добавление к ответу @Vlad Савицкого:
Аппорт должен показать вам каждую проблему только один раз. Кажется, проблема в том, что само приложение может запутаться и не может записать, что оно уже сообщило о проблеме, или забывает, что оно имело место. Это может привести к целой серии диалогов, что раздражает. Это может произойти при обновлении системы.
Одним из решений является удаление всех отчетов о сбоях в /var/crash каталоге. Эта команда может сделать это для вас:
Конечно, если произойдут новые сбои, apport уведомит вас о тех, которые должны.
Kubuntu Wiki
Apport
We are sure that this will lead to a much better level of quality assurance in the future.
If you want to make crash reports of your software even more useful when being reported through apport, please see /DeveloperHowTo.
What does it look like for users?
The user side of apport is designed to be extremely simple and as unannoying as possible.
If any process in the system dies due to a signal that is commonly referred to as a ‘crash’ (segmentation violation, bus error, floating point exception, etc.), or e. g. a packaged Python application raises an uncaught exception, the apport backend is automatically invoked. It produces an initial crash report in a file in /var/crash/ (the file name is composed from the name of the crashed executable and the user id). If the crashed process belongs to the user who is currently logged in, or it belongs to a system process and the user is an administrator, apport informs the user about the crash and offers to report the problem:
You can click on «Show Details. » to see what data it collected:
If the user leaves the «Send error report» checkbox enabled, Apport uploads the collected information to the bug tracking system. After that it opens the packages’ bug filing page with a sensible default bug title and leaves the rest of bug filing process to the web UI.
Why is apport disabled by default?
Note apport does not trap SIGABRT signals. If you are getting such a signal, then please see DebuggingProgramCrash.
How to enable apport
Apport itself is running at all times because it collects crash data for whoopsie (see ErrorTracker). However, the crash interception component is still disabled. To enable it permanently, do:
. and add a hash symbol # in the beginning of the following line:
To disable crash reporting just remove the hash symbol.
I’m a developer. How do I use these crash reports?
Report format
apport internally uses the standard Debian control syntax for reports, i. e. keeps everything in a flat file that looks like this:
Only a tiny subset of the available fields are shown here. Apport reports include a core dump in a compressed and encoded format, which is useful for post-mortem debugging and post-mortem generation of a symbolic stack trace.
However, when uploading the data to a bug tracking system, a different format can be used. e. g. when using Launchpad, the data is uploaded in Multipart/MIME format so that the small parts land directly in the bug summary and the big parts become separate bug attachments.
Fields
Some fields warrant further details:
SegvAnalysis: when examining a Segmentation Fault (signal 11), Apport attempts to review the exact machine instruction that caused the fault, and checks the program counter, source, and destination addresses, looking for any virtual memory address (VMA) that is outside an allocated range (as reported in the ProcMaps attachment).
SegvReason: a VMA can be read from, written to, or executed. On a SegFault, one of these 3 CPU actions has taken place at a given VMA that either not allocated, or lacks permissions to perform the action. For example:
SegvReason: reading NULL VMA would mean that a NULL pointer was most likely dereferenced while reading a value.
SegvReason: writing unknown VMA would mean that something was attempting to write to the destination of a pointer aimed outside of allocated memory. (This is sometimes a security issue.)
SegvReason: executing writable VMA [stack] would mean that something was causing code on the stack to be executed, but the stack (correctly) lacked execute permissions. (This is almost always a security issue.)
Tools
There are several tools available for working with a crash report:
Ubuntu Bug Patterns: These are patterns for packages (writable by Ubuntu Bug Control) that prevent bugs from being filed by apport. Complete details are found in the README.
apport-unpack: Unpack a report into single files (one per attribute). This is most useful for extracting the core dump. Please see the manpage for further details. This tool is not necessary when working with Launchpad, since it already splits the parts into separate attachments.
python-problem-report: This package ships a Python module problem_report which provides general dictionary access to a crash report and loading/saving methods (not specific to apport reports).
python-apport: This ships a Python package apport which encapsulates core functionality of apport and is specific to crash and bug reports. You can use it to implement your own frontends and backends.
apport-collect: This checks the source package(s) of an existing Launchpad bug, runs apport hooks for them, and uploads their collected information back to the bug report.
How does it work internally?
Crash interception
Apport uses /proc/sys/kernel/core_pattern to directly pipe the core dump into apport:
For intercepting Python crashes it installs a /etc/python*/sitecustomize.py to call apport on unhandled exceptions.
Example
Apport is even able to capture core files if PID 1 (Upstart) dies:
If Upstart detects an internal inconsistency, it raises the SIGABRT signal.
The kernel detects the child process has exited abnormally and calls apport, piping the core file to apports standard input (due to /proc/sys/kernel/core_pattern).
apport writes the core file to disk in /var/crash/.
Backend
Frontend invocation
In Gnome, update-notifier keeps an inotify watch on /var/crash. Whenever there is something new, it calls /usr/share/apport/apport-checkreports. If there are new reports, it calls /usr/share/apport/apport-gtk, which is the frontend shown in the screenshots above.
The frontend then collects additional information like package versions, package file checksums, or OS version, and calls all matching package hooks.
To disable this, you can run gsettings set com.ubuntu.update-notifier show-apport-crashes false (as your ordinary desktop user).
Launchpad-based auto-retracer
The Canonical data center runs a service which automatically retrace bugs with apport. By tagging the bugs according to architecture in Launchpad, a retrace will be done and the tag will be removed. Tags that are used are need-i386-retrace or need-amd64-retrace. See the announcement.
Per-package Apport Hooks
in /usr/share/apport/package-hooks. There is also a list of packages providing apport hooks.
Please see /DeveloperHowTo for further information.
If a crash or bug report is submitted through apport, the relevant hooks will be run automatically. If you have an already reported bug that was filed without apport, and you are interested in the information from those hooks, you can ask the bug reporter to use apport-collect bugnumber (see #Tools).
Use the source, Luke!
You can download the upstream tarball from the Launchpad project page, or the Ubuntu source tarball from the Ubuntu archive.
Future plans
Various improvements to performance, better tools to work with reports, and integration of more languages (Mono/Python stack traces, assertion messages, etc.) See the relevant specification.
Further links
Whoopsie is a newer Ubuntu crash submission system that doesn’t require any input from the user and integrates with Apport
Please do not hesitate to report bugs and feature requests to the bug tracker.
Brian Murray gave a class at Ubuntu Developer week regarding writing package hooks.
Apport (последним исправлял пользователь penalvch 2017-05-25 20:03:48)
The material on this wiki is available under a free license, see Copyright / License for details.
Apport Ubuntu.
Система StableReleaseUpdate (SRU). Путешествие от ошибки до её исправления.
Что это и зачем?
Отладка сбоящей программы без автоматизированных средств очень трудоёмка для пользователей. Множество сбоев в программах на компьютерах пользователей оставались без отчёта для разработчика программы и следовательно без исправления, потому что:
Apport позволяет в будущем существенно поднять уровень качества программ.
Если разработчик хочет сделать отчёты о падении программы ещё лучше, то нужно обратиться к DeveloperHowTo.
Как это выглядит для пользователя?
Со стороны пользователя Apport выглядит очень просто и не навязчиво.
Apport автоматически будет вызван:
Происходит создание первоначального отчёта об ошибке в каталоге /var/crash. Имя файла генерируется из пути к упавшей программе и пользовательского ID.
Если упавший процесс «принадлежит» пользователю, который в данный момент вошёл в систему, или процесс системный и в систему зашёл администратор, то Apport информирует об аварии и предлагает сообщить о проблеме разработчикам.
Если пользователь оставляет флажок «Отправить отчёт о неполадке в систему учёта ошибок», то Apport отправляет собранную информацию в систему отслеживания ошибок. Затем открывает в дефолтном браузере вебсайт трекера ошибок, чтобы пользователь смог добавить что-то от себя.
Как включить Apport и почему он выключен по умолчанию?
Apport по умолчанию отключён в стабильных релизах, даже если установлен. Компонент Apport, который осуществляет автоматический перехват падений программ, отключён в стабильных релизах по ряду причин:
Заметьте, что Apport не перехватывает SIGABRT сигнал. Если программа получает именно такой сигнал, то нужно ознакомиться с DebuggingProgramCrash.
Ubuntu 12.04 и новее.
Начиная с релиза Ubuntu 12.04, Apport работает постоянно для сбора данных падений программ для демона whoopsie (смотри ErrorTracker).
Инструменты.
Есть несколько инструментов для работы с отчётами по ошибкам:
Как это всё работает?
Apport использует /proc/sys/kernel/core_pattern для получения дампа.
$ cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport %p %s %c
Для перехвата необработанных исключений в Python программах используется /etc/python*/sitecustomize.py для вызова Apport.
Backend.
Для того, чтобы задержка и нагрузка на CPU и I/O была как можно меньше, /usr/share/apport/apport собирает данные только, когда падающий процесс ещё существует в памяти. Информация из /proc/pid, дампы, путь к исполняемому файлу, номер сигнала записывается в /var/crash/executable_path.uid_user.crash.
Вызов Frontend.
Update-notifier следит с помощью inotify за каталогом /var/crash/. Если там появляется что-то новое, то он вызывает /usr/share/apport/apport-checkreports. Если есть новые отчёты, то вызывается /usr/share/apport/apport-gtk, который и показывает окна, иллюстрированные выше.
Сам frontend и собирает дополнительную информацию о версиях пакетов, версии операционной системы и вызывает нужные хуки для данной программы.
Для отключения можно запустить
gsettings set com.ubuntu.update-notifier show-apport-crashes false
Хуки Apport.
Можно указать, что нужно дополнительно указать при создании отчёта для конкретной программы. Это делается через хуки Apport.
Для примера из каталога /usr/share/apport/package-hooks/:
Будущие планы.
Ожидаются улучшения в скорости сбора данных и интеграция с бо́льшим количеством языков (трассировка стека вызовов Mono и Python, сообщений assert() и другое).
Сбор другой интересной информации для отчёта, но в тоже время удержать размер дампов в разумных пределах.
Исключение из отчёта упоминаний о пакетах сторонних производителей.