Зібрану інформацію чи звіт завантажують у систему відстеження помилок.
Якщо будь-який процес у системі відмирає через сигнал, який зазвичай називають «аварією» (порушення сегментації, помилка шини, виняток з плаваючою точкою тощо), або, наприклад, упакований додаток Python викликає неперевершене виняток, підпорядкований випуск автоматично викликається.
Він створює початковий звіт про збій у файлі в / var / crash / (ім'я файлу складається із імені збійного виконуваного файлу та ідентифікатора користувача). Якщо процес збоїв належить користувачеві, який зараз увійшов у систему, або він належить до системного процесу, а користувач є адміністратором, apport повідомляє користувача про збій і пропонує повідомити про проблему.
Якщо користувач залишає прапорець "Надіслати звіт про помилку" увімкненим, Apport завантажує зібрану інформацію в систему відстеження помилок. Після цього він відкриває сторінку подання помилок з чутливою назвою помилки за замовчуванням та залишає решту процесів подання помилок у веб-інтерфейсі.
Ubuntu щодня отримує неймовірно велику кількість повідомлень про помилки через нашу систему відстеження помилок. Кожну з них потрібно прочитати, оцінити та сортувати, щоб її можна було виправити. Тут ми можемо скористатись вашою допомогою щодо допомоги з помилками. Для наочного подання про процес помилок, див. Ці приємні діаграми потоків.
Кожен звіт про помилку - це розмова з репортером. Перший контакт, який зазвичай має будь-який репортер із спільнотою Ubuntu, здійснюється через тригер помилок, який намагається скласти повний звіт про помилку. Дуже важливо, щоб ми справили гарне враження, тому будь ласка, будьте ввічливі та намагайтеся використовувати свою найкращу англійську мову.
Робота над простими, незмінними помилками - це хороший спосіб розпочати роботу та ознайомитись із процедурою триагінгу, оскільки вам доведеться мати справу з усіма аспектами життєвого циклу помилки. У розділі "Недотримані помилки" пояснюється, де їх знайти.
Типи помилок
Доповідь про звіт
Звіти про звіт - це помилки, про які повідомляється через автоматизовану програму звітування про помилки Apport. Повідомлення про помилки за допомогою Apport є кращим способом повідомлення про помилку, оскільки він дає розробникам багато інформації про систему, про яку йдеться. Коли використовується Apport, потрібно менше додаткової інформації, що прискорює весь процес.
Ви можете розпізнати ці помилки за доданим списком системної інформації в їх описі. Деякі програми мають гачки для Apport, додаючи більше інформації під час повідомлення про помилку. Цю інформацію зазвичай можна знайти в додатках.
Підтверджені помилки
Коли помилка позначена як "Підтверджена", вона ще не повністю спрацьована. Цей помилка дуже близький до того, що він позначається як "Triaged", але вам потрібно переконатися, що він готовий виправити розробників.
Запити на функції
Якщо звіт про помилку - це фактично запит на функції, є дві можливості. Якщо запитуване вдосконалення є невеликим і чітко визначеним та / або пропозиція стосується вищезазначеного проекту, важливість помилки має бути встановлено у "Список бажань". Після завершення звіту статус слід встановити на "Оброблений".
Це можуть робити лише члени команди Ubuntu Bug Control. Якщо ви не є членом, вам доведеться запитати когось, хто повинен зробити це за вас. Вставте номер помилки в # ubuntu-bugs і скажіть, що ви вважаєте, що помилку слід встановити на "Список бажань". Хтось помітить і встановить це для вас, хоча не обов’язково відразу.
Як це працює внутрішньо?
Звільнення перехоплення
Apport використовує / proc / sys / kernel / core_pattern, щоб безпосередньо передати дамп ядра в 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 навіть може захоплювати основні файли, якщо PID 1 (Upstart) гине:
- Якщо Upstart виявить внутрішню невідповідність, вона підвищує сигнал SIGABRT.
- Обробник збоїв Upstart викликається на SIGABRT.
- Обробник аварійних ситуацій на випаді розгортає дочірній процес.
- Дочірній процес Upstart повторно подає сигнал, що призводить до того, що дитина виходить ненормально.
- Ядро виявляє, що дочірній процес закінчився ненормально і викликає apport, передаючи основний файл для призначення стандартного вводу (за рахунок / proc / sys / kernel / core_pattern).
- apport записує основний файл на диск в / var / crash /.
- PID 1 чекає, коли його дитина закінчиться (що відбувається лише після того, як аплікація закінчила запис основного файлу).
- PID 1 виходить.
- ядра паніки.
- Під час наступного завантаження Whoopsie виявить файл збою та обробить його.
Бекенд
З метою збереження затримки та впливу CPU / IO якомога менше, /usr/share/apport/apportвін збирає лише ті дані, які необхідно отримати, поки процес збоїв все ще існує: інформація /proc/pid, основний дамп, виконуваний шлях та номер сигналу. Звіт написано на /var/crash/executable_path.uid.crash.
Виклик переднього телефону
У Gnome оновлення-сповіщувач продовжує тримати режим ініціації /var/crash. Кожного разу, коли є щось нове, він дзвонить / usr / share / apport / apport-checkreports. Якщо є нові звіти, він викликає / usr / share / apport / apport-gtk, що є фронтендом, показаним на знімках екрана вище.
Потім фронтенд збирає додаткову інформацію, наприклад версії пакунків, контрольні суми файлів пакунків чи версію ОС, і закликає всі гачки відповідних пакетів. Щоб відключити це, можна запустити набір gsettings com.ubuntu.update-notifier show-apport-crashes false (як звичайний користувач на робочому столі).
Автоматичний ретранслятор на основі стартової панелі
Центр обробки даних Canonical запускає послугу, яка автоматично відслідковує помилки при застосуванні. Позначивши помилки відповідно до архітектури в Launchpad, буде виконано повторне вилучення та тег буде видалено. Теги, які використовуються, мають потребу-i386-retrace або need-amd64-retrace. Дивіться оголошення.
Гачки для ввезення за упаковку
Можна для пакетів вказати інформацію, зібрану з системи та включену у звіт про помилку. Це робиться за допомогою гачків для підключення, що містяться в упаковках. Деякі корисні приклади див .:
- source_xorg.py - додає додаткові файли журналу та деталі обладнання до звітів про помилки
- usplash - ігнорує збої в конкретних кодових шляхах
- source_totem.py - задає питання репортеру та збирає різну інформацію на основі відповідей
в / usr / share / apport / пакет-гачки. Також є перелік пакунків, що надають гачки для підвезення.
Якщо звіт про аварійну ситуацію чи помилку подається через apport, відповідні гачки запускаються автоматично. Якщо у вас вже повідомляється про помилку, яку було подано без прихильності, і вас цікавить інформація з цих гаків, ви можете попросити репортера помилки використати програму buport, яка збирає apport.
Користуйся джерелом, Лука!
- Ви можете завантажити тарбол вище за течією зі сторінки проекту Launchpad або вихідний тарбол Ubuntu з архіву Ubuntu.
- apport розроблений на базарі RCS на Launchpad. Якщо ви хочете внести свій внесок у нього або розробити на його основі власну систему, ви можете отримати свою власну гілку за допомогою bzr get lp: apport for trunk, або debcheckout - додаток для гілки упаковки Ubuntu.
Плани на майбутнє
Різні поліпшення продуктивності, кращі інструменти для роботи зі звітами та інтеграція більшої кількості мов (сліди стека Mono / Python, повідомлення про твердження тощо) Дивіться відповідну специфікацію.
Джерела: Apport , How to Triage та How to enable Apport
