Was passiert, nachdem "Ubuntu-Bug" seine Sache getan hat?

Bis vor einiger Zeit bist du gelaufen apport-bugoder ubuntu-bugum einen Fehler zu melden. Das System öffnet dann das Launchpad mit Ihrem Konto, lädt die gesammelten Informationen hoch und lässt Sie weitere Informationen zum Fehlerbericht hinzufügen.

Wenn ich jetzt starte gksudo ubuntu-bug(zum Beispiel mit einer crash-Datei als Argument), erscheint der allgemeine Fehlerdialog

und das ist alles.

Wohin wird der Bericht gesendet? Auf keinen Fall Launchpad als Fehlerbericht (obwohl die Leute in der konkreten Situation in der Lage waren, einen Bericht über diesen Fehler einzureichen).

Also: wohin wird dieser Bericht gesendet (und vielleicht auch), wie kann ich trotzdem einen Fehlerbericht von meinem System aus einreichen (erleichtert das Hochladen der betreffenden Dateien erheblich)?

Könnte es sein, dass "das System" entschieden hat, dass dies ein Duplikat eines bereits vorhandenen Fehlers ist?

Technisch wird ubuntu-bugder Absturzbericht nur lokal protokolliert. Ein separates Programm whoopsieüberwacht protokollierte Berichte und lädt sie in eine zentrale Datenbank hoch, in der sie automatisch gruppiert werden, um übergreifende Probleme zu identifizieren.

Die resultierenden Daten werden auf dem Ubuntu Error Tracker angezeigt :

Aggregierte Trends sind öffentlich verfügbar, und vertrauenswürdigen Entwicklern stehen Berichtsdetails zur Verfügung. Weitere Details finden Sie im Ubuntu-Wiki .

Standardmäßig werden ubuntu-bugauf Launchpad keine Fehler für Absturzberichte in stabilen Releases angezeigt. Sie können diese jedoch konfigurieren, wenn Sie dies möchten. Nachdem Sie diese Änderung vorgenommen haben, können Sie einen Fehler für einen vorhandenen Absturzbericht durch Ausführen von öffnen ubuntu-bug /var/crash/foo.crash.

Die gesammelten Informationen oder Berichte werden in ein Fehlerverfolgungssystem hochgeladen.

Wenn ein Prozess im System aufgrund eines Signals abstürzt, das allgemein als "Absturz" (Segmentierungsverletzung, Busfehler, Gleitkomma-Ausnahme usw.) bezeichnet wird, oder z. B. eine gepackte Python-Anwendung eine nicht abgefangene Ausnahme auslöst, wird das Apport-Backend ausgeführt wird automatisch aufgerufen.

Es wird ein Erstabsturzbericht in einer Datei in / var / crash / erstellt (der Dateiname setzt sich aus dem Namen der abgestürzten ausführbaren Datei und der Benutzer-ID zusammen). Wenn der abgestürzte Prozess dem derzeit angemeldeten Benutzer oder einem Systemprozess gehört und der Benutzer ein Administrator ist, informiert apport den Benutzer über den Absturz und bietet an, das Problem zu melden.

Wenn der Benutzer das Kontrollkästchen "Fehlerbericht senden" aktiviert lässt, lädt Apport die gesammelten Informationen in das Fehlerverfolgungssystem hoch. Danach öffnet es die Seite zur Fehlerarchivierung der Pakete mit einem sinnvollen Standard-Fehlertitel und überlässt den Rest des Prozesses zur Fehlerarchivierung der Web-Benutzeroberfläche.

Ubuntu erhält jeden Tag eine unglaublich große Anzahl von Fehlerberichten über unser Fehlerverfolgungssystem. Jedes dieser Elemente muss gelesen, bewertet und sortiert werden, damit es behoben werden kann. Hier könnten wir Ihre Hilfe bei der Hilfe bei Fehlern gebrauchen. Eine visuelle Darstellung des Bug-Triage-Prozesses finden Sie in diesen schönen Flussdiagrammen.

Jeder Fehlerbericht ist ein Gespräch mit dem Reporter. Der erste Kontakt, den ein Reporter normalerweise mit der Ubuntu-Community hat, ist ein Bug-Triager, der versucht, einen vollständigen Bug-Report zusammenzustellen. Es ist sehr wichtig, dass wir einen guten Eindruck hinterlassen. Seien Sie daher höflich und versuchen Sie, Ihr bestes Englisch zu verwenden.

Die Arbeit an einfachen, nicht getesteten Fehlern ist eine gute Möglichkeit, sich mit dem Testverfahren vertraut zu machen, da Sie sich mit allen Aspekten des Lebenszyklus eines Fehlers befassen müssen. Im Abschnitt Nicht vermittelte Fehler wird erläutert, wo sie zu finden sind.

Fehlertypen

Berichte zuordnen

Apport-Berichte sind Fehler, die über das automatische Fehlerberichterstattungsprogramm Apport gemeldet werden. Das Melden von Fehlern mit Apport ist die bevorzugte Methode zum Melden eines Fehlers, da die Entwickler viele Informationen über das betroffene System erhalten. Wenn Apport verwendet wird, sind weniger zusätzliche Informationen erforderlich, wodurch der gesamte Prozess beschleunigt wird.

Sie erkennen diese Fehler an der hinzugefügten Liste der Systeminformationen in ihrer Beschreibung. Einige Programme haben Hooks für Apport, die beim Melden eines Fehlers zusätzliche Informationen hinzufügen. Diese Informationen finden Sie normalerweise in den Anhängen.

Bestätigte Fehler

Wenn ein Fehler als "Bestätigt" markiert ist, wird er noch nicht vollständig überprüft. Dieser Fehler steht kurz davor, als "Triaged" markiert zu werden, aber Sie müssen sicherstellen, dass er für die Entwickler zur Behebung bereit ist.

Funktionsanfragen

Wenn der Fehlerbericht tatsächlich eine Funktionsanforderung ist, gibt es zwei Möglichkeiten. Wenn die gewünschte Verbesserung klein und klar definiert ist und / oder der Vorschlag ein vorgelagertes Projekt betrifft, sollte die Bedeutung des Fehlers auf "Wunschliste" gesetzt werden. Nach Abschluss des Berichts sollte der Status auf "Triaged" gesetzt werden.

Dies können nur die Mitglieder des Ubuntu Bug Control-Teams. Wenn Sie kein Mitglied sind, müssen Sie jemanden fragen, der das für Sie erledigt. Fügen Sie die Fehlernummer in # ubuntu-bugs ein und sagen Sie, dass der Fehler auf "Wishlist" gesetzt werden sollte. Jemand wird es bemerken und für Sie einstellen, wenn auch nicht unbedingt sofort.

Wie funktioniert es intern?

Abfangen von Abstürzen

Apport verwendet / proc / sys / kernel / core_pattern, um den Core-Dump direkt in apport zu leiten:

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

Hinweis: Auch wenn ulimit auf deaktivierte Core-Dateien gesetzt ist (durch Angabe einer Core-Dateigröße von Null mit ulimit -c 0), erfasst apport den Absturz. Zum Abfangen von Python-Abstürzen wird ein /etc/python*/sitecustomize.pyAufruf von apport für nicht behandelte Ausnahmen installiert .

Beispiel

Apport ist sogar in der Lage, Kerndateien zu erfassen, wenn PID 1 (Upstart) stirbt:

1. Wenn Upstart eine interne Inkonsistenz feststellt, wird das SIGABRT-Signal ausgelöst.
2. Der Upstart-Crash-Handler wird bei SIGABRT aufgerufen.
3. Der Upstart-Crash-Handler gibt einen untergeordneten Prozess aus.
4. Der untergeordnete Upstart-Prozess löst das Signal erneut aus, was dazu führt, dass das untergeordnete Element abnormal beendet wird.
5. Der Kernel erkennt, dass der untergeordnete Prozess nicht normal beendet wurde, und ruft apport auf, wobei die Kerndatei an die Standardeingabe weitergeleitet wird (aufgrund von / proc / sys / kernel / core_pattern).
6. apport schreibt die Core-Datei in / var / crash / auf die Festplatte.
7. PID 1 wartet darauf, dass sein untergeordnetes Element beendet wird (was nur geschieht, wenn apport das Schreiben der Kerndatei abgeschlossen hat).
8. PID 1 wird beendet.
9. Kernel-Panik.
10. Beim nächsten Start erkennt Whoopsie die Absturzdatei und verarbeitet sie.

Backend

Um die Verzögerung und die Auswirkungen von CPU / IO so gering wie möglich zu halten, werden /usr/share/apport/apportnur Daten erfasst, die erfasst werden müssen, während der abgestürzte Prozess noch vorhanden ist: Informationen von /proc/pid, Core-Dump, ausführbarer Pfad und Signalnummer. Der Bericht wird an geschrieben /var/crash/executable_path.uid.crash.

Frontend-Aufruf

In Gnome überwacht update-notifier inotify /var/crash. Wann immer es etwas Neues gibt, ruft es / usr / share / apport / apport-checkreports auf. Wenn neue Berichte vorliegen, wird / usr / share / apport / apport-gtk aufgerufen. Dies ist das in den obigen Screenshots gezeigte Frontend.

Das Frontend sammelt dann zusätzliche Informationen wie Paketversionen, Prüfsummen für Paketdateien oder Betriebssystemversionen und ruft alle übereinstimmenden Paket-Hooks auf. Um dies zu deaktivieren, können Sie gsettings set com.ubuntu.update-notifier show-apport-crashes false ausführen (als normaler Desktop-Benutzer).

Launchpad-basierter Auto-Retracer

Das Canonical-Rechenzentrum betreibt einen Dienst, der Fehler mit apport automatisch nachverfolgt. Durch Markieren der Fehler gemäß der Architektur im Launchpad wird ein Rückverfolgungsvorgang durchgeführt und das Tag wird entfernt. Verwendete Tags sind need-i386-retrace oder need-amd64-retrace. Siehe die Ankündigung.

Apport Hooks pro Paket

Pakete können Informationen angeben, die vom System gesammelt und in den Fehlerbericht aufgenommen wurden. Dies erfolgt durch Zuweisen von Hooks, die in Paketen enthalten sind. Einige nützliche Beispiele finden Sie unter:

• source_xorg.py - Fügt den Fehlerberichten zusätzliche Protokolldateien und Hardwaredetails hinzu
• usplash - ignoriert Abstürze in bestimmten Codepfaden
• source_totem.py - Fragt den Reporter und sammelt verschiedene Informationen basierend auf den Antworten

in / usr / share / apport / package-hooks. Es gibt auch eine Liste von Paketen, die Apport Hooks bereitstellen.

Wenn ein Absturz- oder Fehlerbericht über apport übermittelt wird, werden die entsprechenden Hooks automatisch ausgeführt. Wenn Sie einen bereits gemeldeten Fehler haben, der ohne Apport abgelegt wurde, und Sie an den Informationen aus diesen Hooks interessiert sind, können Sie den Fehlerberichter bitten, die Apport-Collect-Fehlernummer zu verwenden.

Benutze die Quelle, Luke!

• Sie können den Upstream-Tarball von der Launchpad-Projektseite oder den Ubuntu-Quell-Tarball aus dem Ubuntu-Archiv herunterladen.
• Apport wird mit dem Basar RCS auf Launchpad entwickelt. Wenn Sie einen Beitrag leisten oder ein eigenes System entwickeln möchten, das darauf basiert, können Sie mit bzr get lp: apport for trunk oder debcheckout -a apport for the Ubuntu packaging branch einen eigenen Zweig erstellen.

Zukunftspläne

Verschiedene Leistungsverbesserungen, bessere Tools für die Arbeit mit Berichten und die Integration weiterer Sprachen (Mono / Python-Stack-Traces, Assertionsnachrichten usw.) Weitere Informationen finden Sie in der entsprechenden Spezifikation.

^{Quellen: Apport , How To Triage und How to Apport aktivieren}