Что происходит после того, как `ubuntu-bug` сделал свое дело?

Технически, ubuntu-bug просто регистрирует отчет о сбое локально. Отдельная программа whoopsie отслеживает зарегистрированные отчеты и загружает их в центральную базу данных, где они автоматически группируются для выявления общих проблем.

Полученные данные отображаются на трекере ошибок Ubuntu :

Совокупные тренды доступны для общественности, и детали отчета доступны для доверенных разработчиков. Более подробная информация доступна в Ubuntu Wiki .

По умолчанию ubuntu-bug не открывает ошибки на Launchpad для отчетов о сбоях в стабильных выпусках, но вы можете настроить его на , если хотите. После внесения этого изменения вы можете открыть ошибку для существующего отчета о сбое, выполнив ubuntu-bug /var/crash/foo.crash.

Собранная информация или отчет загружаются в систему отслеживания ошибок.

Если какой-либо процесс в системе умирает из-за сигнала, который обычно называют «сбоем» (нарушение сегментации, ошибка шины, исключение с плавающей запятой и т. д.) или e. г. упакованное приложение Python вызывает необработанное исключение, автоматически вызывается серверная часть приложения.

Он создает первоначальный отчет о сбое в файле в / var / crash / (имя файла составлено из имени сбойного исполняемого файла и идентификатора пользователя). Если сбойный процесс принадлежит пользователю, который в данный момент вошел в систему, или он принадлежит системному процессу, а пользователь является администратором, apport информирует пользователя о сбое и предлагает сообщить о проблеме.

Если пользователь оставляет флажок «Отправить отчет об ошибках», Apport загружает собранную информацию в систему отслеживания ошибок. После этого он открывает страницу регистрации ошибок пакетов с разумным заголовком ошибки по умолчанию и оставляет оставшуюся часть процесса регистрации ошибок веб-интерфейсу.

Ubuntu ежедневно получает невероятно большое количество отчетов об ошибках через нашу систему отслеживания ошибок. Каждый из них должен быть прочитан, оценен и отсортирован, чтобы его можно было исправить. Здесь мы могли бы использовать вашу помощь в помощи с ошибками. Для визуального представления процесса сортировки ошибок см. Эти симпатичные блок-схемы.

Каждый отчет об ошибке - это беседа с репортером. Первый контакт любого репортера с сообществом Ubuntu обычно происходит через триггер, который пытается составить полный отчет об ошибке. Очень важно, чтобы мы производили хорошее впечатление, поэтому будьте вежливы и старайтесь использовать свой лучший английский.

Работа с простыми, неуправляемыми ошибками - это хороший способ начать знакомство с процедурой сортировки, поскольку вам придется иметь дело со всеми аспектами жизненного цикла ошибки. В разделе «Неисправленные ошибки» объясняется, где их найти.

Типы ошибок

Отчеты об Apport

Отчеты об Apport - это ошибки, о которых сообщается с помощью автоматизированной программы отчетов об ошибках Apport. Сообщение об ошибках с помощью Apport является предпочтительным способом сообщения об ошибках, так как оно дает разработчикам много информации об уязвимой системе. Когда используется Apport, требуется меньше дополнительной информации, что ускоряет весь процесс.

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

Подтвержденные ошибки

Когда ошибка помечена как «Подтвержденная», она еще не полностью устранена. Эта ошибка очень близка к тому, чтобы пометить ее как «Triaged», но вы должны убедиться, что она готова для разработчиков.

Запросы функций

Если отчет об ошибке фактически является запросом функции, есть две возможности. Если запрошенное улучшение является небольшим и четко определенным, и / или предложение относится к вышестоящему проекту, важность ошибки должна быть установлена ​​на «Список пожеланий». По завершении отчета статус должен быть установлен на «Triaged».

Только члены Ubuntu Bug Control могут сделать это. Если вы не являетесь участником, вам нужно будет спросить кого-то, кто сделает это за вас. Вставьте номер ошибки в # ubuntu-bugs и скажите, что вы думаете, что ошибка должна быть установлена ​​в «Wishlist». Кто-то заметит и установит это для вас, хотя не обязательно сразу.

Как это работает внутри?

Перехват сбоев

Apport использует / proc / sys / kernel / core_pattern для прямой передачи ядра dump to apport:

$ cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport %p %s %c
$ 

Примечание: даже если для ulimit заданы отключенные файлы ядра (указав нулевой размер файла ядра с помощью ulimit -c 0), apport все равно сохранит сбой. Для перехвата сбоев Python он устанавливает /etc/python*/sitecustomize.py для вызова apport для необработанных исключений.

Пример

Apport может даже захватывать файлы ядра, если PID 1 (Upstart) умирает:

1. Если Upstart обнаруживает внутреннюю несогласованность , он поднимает сигнал SIGABRT.
2. Обработчик сбоя Upstart вызывается в SIGABRT.
3. Обработчик аварийного запуска Upstart разветвляет дочерний процесс.
4. Дочерний процесс Upstart повторно поднимает сигнал, что приводит к ненормальному выходу ребенка.
5. Ядро обнаруживает, что дочерний процесс завершился ненормально, и вызывает apport, передавая файл ядра в соответствии со стандартным вводом (из-за / proc / sys / kernel / core_pattern).
6. apport записывает файл ядра на диск в / var / crash /.
7. PID 1 ожидает завершения дочернего процесса (что происходит только после того, как apport завершит запись файла ядра).
8. PID 1 выходит.
9. паника ядра.
10. При следующей загрузке Whoopsie обнаружит файл сбоя и обработает его.

Бэкэнд

Для того, чтобы задержка и влияние ЦП / ввода-вывода были как можно ниже, /usr/share/apport/apport собирает только те данные, которые должны быть получены, пока сбойный процесс все еще существует: информация из /proc/pid, дамп ядра, путь к исполняемому файлу и номер сигнала. Отчет написан в /var/crash/executable_path.uid.crash.

Вызов внешнего интерфейса

В Gnome модуль уведомлений об обновлениях отслеживает inotify на /var/crash. Когда появляется что-то новое, он вызывает / usr / share / apport / apport-checkreports. Если появляются новые отчеты, он вызывает / usr / share / apport / apport-gtk, который является интерфейсом, показанным на скриншотах выше.

Затем внешний интерфейс собирает дополнительную информацию, такую ​​как версии пакета, контрольные суммы файла пакета или версия ОС, и вызывает все соответствующие перехваты пакета. Чтобы отключить это, вы можете запустить gsettings set com.ubuntu.update-notifier show-apport-crashes false (как обычный пользователь рабочего стола).

Auto-retracer на основе панели запуска

В центре обработки данных Canonical работает служба, которая автоматически отслеживает ошибки с помощью apport. Помечая ошибки в соответствии с архитектурой в Launchpad, будет произведен повторный просмотр и тег будет удален. Используются следующие теги: need-i386-retrace или need-amd64-retrace. Смотрите объявление.

Пакетные зацепки Apport

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

• source_xorg.py - добавляет дополнительные файлы журналов и сведения об оборудовании в отчеты об ошибках
• usplash - игнорирует сбои в определенных путях кода
• source_totem .py - задает вопросы репортеру и собирает различную информацию на основе ответов

в / usr / share / apport / package-hooks. Существует также список пакетов, обеспечивающих перехват приложений.

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

Использовать источник, Люк!

• Вы можете загрузить вышеприведенный архив со страницы проекта Launchpad или исходный архив Ubuntu из архива Ubuntu. [ 1122]
• apport разработан с базаром RCS на Launchpad. Если вы хотите внести в него свой вклад или разработать собственную систему на его основе, вы можете получить свою собственную ветку с помощью bzr get lp: apport для trunk или debcheckout -a apport для ветки упаковки Ubuntu.

Планы на будущее

Различные улучшения производительности, улучшенные инструменты для работы с отчетами и интеграция большего количества языков (трассировки стека Mono / Python, сообщения подтверждения и т. Д.) Смотрите соответствующую спецификацию.

^{Источники: Apport , Как выполнить сортировку и Как включить Apport}