Zebrane informacje lub raport są przesyłane do systemu śledzenia błędów.
Jeśli jakikolwiek proces w systemie umrze z powodu sygnału, który jest powszechnie określany jako „awaria” (naruszenie segmentacji, błąd magistrali, wyjątek zmiennoprzecinkowy itp.), Lub np. Spakowana aplikacja Python zgłasza nieprzechwycony wyjątek, backend aplikacji jest wywoływany automatycznie.
Generuje początkowy raport o awarii w pliku w / var / crash / (nazwa pliku składa się z nazwy uszkodzonego pliku wykonywalnego i identyfikatora użytkownika). Jeśli proces, który się zawiesił, należy do użytkownika, który jest aktualnie zalogowany lub do procesu systemowego, a użytkownik jest administratorem, programportport informuje użytkownika o awarii i oferuje zgłoszenie problemu.
Jeśli użytkownik pozostawi zaznaczone pole wyboru „Wyślij raport o błędzie”, Apport prześle zebrane informacje do systemu śledzenia błędów. Następnie otwiera stronę zgłaszania błędów pakietów z rozsądnym domyślnym tytułem błędu i pozostawia resztę procesu zgłaszania błędów do internetowego interfejsu użytkownika.
Ubuntu codziennie otrzymuje niewiarygodnie dużą liczbę zgłoszeń błędów za pośrednictwem naszego systemu śledzenia błędów. Każdy z nich musi zostać przeczytany, oceniony i posortowany, aby można go było naprawić. W tym miejscu moglibyśmy skorzystać z Twojej pomocy przy pomocy z błędami. Aby wizualnie przedstawić proces usuwania błędów, zobacz te ładne diagramy przepływu.
Każdy raport o błędzie jest rozmową z reporterem. Pierwszym kontaktem, jaki zwykle ma każdy reporter ze społecznością Ubuntu, jest triager błędów, który próbuje skompletować pełny raport o błędzie. Bardzo ważne jest, abyśmy robili dobre wrażenie, więc bądź uprzejmy i staraj się używać swojego najlepszego angielskiego.
Praca nad prostymi, niesprawdzonymi błędami jest dobrym sposobem na rozpoczęcie i zapoznanie się z procedurą podziału na błędy, ponieważ będziesz musiał poradzić sobie z każdym aspektem cyklu życia błędu. W sekcji Błędy niezwiązane z zagadnieniami wyjaśniono, gdzie je znaleźć.
Rodzaje błędów
Raporty Apport
Raporty Apport to błędy zgłaszane przez automatyczny program do zgłaszania błędów Apport. Zgłaszanie błędów za pomocą Apport jest preferowanym sposobem zgłaszania błędu, ponieważ daje programistom wiele informacji na temat systemu, którego dotyczy luka. Gdy używana jest funkcja Apport, wymagane są mniej dodatkowych informacji, co przyspiesza cały proces.
Błędy te można rozpoznać po dodanej liście informacji o systemie w ich opisie. Niektóre programy mają haczyki dla Apport, dodając więcej informacji podczas zgłaszania błędu. Informacje te zwykle można znaleźć w załącznikach.
Potwierdzone błędy
Kiedy błąd jest oznaczony jako „Potwierdzony”, nie jest jeszcze w pełni klasyfikowany. Ten błąd jest bardzo bliski oznaczenia go jako „Triaged”, ale musisz upewnić się, że jest gotowy do naprawy przez programistów.
Żądania funkcji
Jeśli zgłoszenie błędu jest w rzeczywistości żądaniem funkcji, istnieją dwie możliwości. Jeśli żądane ulepszenie jest małe i dobrze zdefiniowane i / lub sugestia dotyczy wcześniejszego projektu, Ważność błędu powinna być ustawiona na „Lista życzeń”. Po zakończeniu raportu status należy ustawić na „Triaged”.
Tylko członkowie zespołu kontroli błędów Ubuntu mogą to zrobić. Jeśli nie jesteś członkiem, musisz zapytać kogoś, kto to zrobi za Ciebie. Wklej numer błędu w # ubuntu-bugs i powiedz, że uważasz, że błąd powinien być ustawiony na „Lista życzeń”. Ktoś to zauważy i ustawi dla ciebie, choć niekoniecznie natychmiast.
Jak to działa wewnętrznie?
Przechwytywanie awarii
Apport używa / proc / sys / kernel / core_pattern, aby bezpośrednio potokować zrzut rdzenia do apport:
$ cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport %p %s %c
$
Uwaga: nawet jeśli ulimit jest ustawiony na wyłączone pliki podstawowe (określając rozmiar pliku podstawowego zero za pomocą ulimit -c 0), apport nadal przechwytuje awarię. Aby przechwycić awarie Pythona, instaluje /etc/python*/sitecustomize.pyapport do wywołania w nieobsługiwanych wyjątkach.
Przykład
Apport jest nawet w stanie przechwycić podstawowe pliki, jeśli PID 1 (Upstart) umrze:
- Jeśli Upstart wykryje wewnętrzną niespójność, podnosi sygnał SIGABRT.
- Program obsługi awarii Upstart jest wywoływany w SIGABRT.
- Upstart obsługi awarii powoduje rozwiązywanie procesu potomnego.
- Proces potomny Upstart ponownie podnosi sygnał, który powoduje, że dziecko wychodzi nienormalnie.
- Jądro wykrywa nienormalne zakończenie procesu potomnego i wywołuje apport, przesyłając plik rdzenia do domyślnego wejścia (z powodu / proc / sys / kernel / core_pattern).
- apport zapisuje plik podstawowy na dysk w / var / crash /.
- PID 1 czeka na zakończenie swojego potomka (co dzieje się dopiero po zakończeniu zapisywania pliku podstawowego przez apport).
- Wyjście PID 1.
- panika jądra.
- Przy następnym uruchomieniu Whoopsie wykryje plik awarii i przetworzy go.
Backend
Aby utrzymać opóźnienie i wpływ procesora / IO na możliwie najniższym poziomie, /usr/share/apport/apportgromadzone są tylko dane, które należy zebrać, dopóki proces zawieszony nadal istnieje: informacje z /proc/pidzrzutu pamięci, ścieżki wykonywalnej i numeru sygnału. Raport jest napisany do /var/crash/executable_path.uid.crash.
Wywołanie frontonu
W Gnome update-notifier utrzymuje obserwację inotify /var/crash. Ilekroć pojawia się coś nowego, wywołuje / usr / share / apport / apport-checkreports. Jeśli pojawią się nowe raporty, wywołuje / usr / share / apport / apport-gtk, czyli frontend pokazany na powyższych zrzutach ekranu.
Frontend następnie zbiera dodatkowe informacje, takie jak wersje pakietu, sumy kontrolne pliku pakietu lub wersja systemu operacyjnego, i wywołuje wszystkie pasujące pakiety. Aby to wyłączyć, możesz uruchomić gsettings, ustawiając com.ubuntu.update-notifier show-apport-crash zawiesza false (jako zwykły użytkownik pulpitu).
Auto-retracer oparty na Launchpad
Centrum danych Canonical prowadzi usługę, która automatycznie wyszukuje błędy przy pomocy apport. Po oznaczeniu błędów zgodnie z architekturą w Launchpad, nastąpi powrót i tag zostanie usunięty. Używane tagi to need-i386-retrace lub need-amd64-retrace. Zobacz ogłoszenie.
Haczyki Apport na pakiet
Pakiety mogą określać informacje zebrane z systemu i zawarte w zgłoszeniu błędu. Dokonuje się tego za pomocą haków apport zawartych w pakietach. Kilka przydatnych przykładów:
- source_xorg.py - dodaje dodatkowe raporty i szczegóły sprzętu do raportów błędów
- usplash - ignoruje awarie w określonych ścieżkach kodu
- source_totem.py - zadaje reporterowi pytania i zbiera różne informacje na podstawie odpowiedzi
w / usr / share / apport / package-hooks. Istnieje również lista pakietów udostępniających haczyki apport.
Jeśli raport o awarii lub błędzie zostanie przesłany przez apport, odpowiednie haki zostaną uruchomione automatycznie. Jeśli masz już zgłoszony błąd, który został zgłoszony bez apportu, i interesują Cię informacje z tych haków, możesz poprosić reportera błędów o użycie numeru błędu apport-collect.
Użyj źródła, Luke!
- Możesz pobrać archiwum wyjściowe ze strony projektu Launchpad lub archiwum źródłowego Ubuntu z archiwum Ubuntu.
- apport jest rozwijany z bazarem RCS na Launchpad. Jeśli chcesz się do tego przyczynić lub opracować własny system na jego podstawie, możesz uzyskać własny oddział za pomocą bzr get lp: apport for trunk lub debcheckout -a apport dla gałęzi Ubuntu.
Przyszłe plany
Różne ulepszenia wydajności, lepsze narzędzia do pracy z raportami oraz integracja większej liczby języków (ślady stosu Mono / Python, komunikaty asercji itp.) Zobacz odpowiednią specyfikację.
Źródła: Apport , How to Triage i jak włączyć Apport
