Fehler:GNOME

aus openSUSE, der freien Wissensdatenbank

Um einen Fehler in GNOME zu melden sind einige Dinge nötig:

• Installieren Sie die -debuginfo-Pakete; diese enthalten Symbolinformationen für alle Binärdateien und sind sehr hilfreich beim Erstellen von Informationen über Abstürze.
• Installieren Sie Bug-Buddy. Diese Anwendung wird jedes mal gestartet, wenn eine GNOME-Anwendung abstürzt und sammelt alle Informationen, die sie über die abgestürzte Anwendung zusammentragen kann.
• Schauen Sie sich die Abschnitte weiter unten an, um zu sehen, ob die von ihnen verwendete Software eventuell noch weitere Schritte benötigt.

Um nach Fehlern beim Ursprungsprojekt zu schauen, besuchen Sie http://bugzilla.gnome.org

Stapelverlaufsrückverfolgungen manuell erhalten

Falls Bug-Buddy bei einem Programmabsturz nicht erscheint, gehen Sie wie folgt vor (was Sie eingeben müssen ist fett gedruckt):

$ gdb gedit             # oder der Name des abgestürzten Prozesses
(gdb) r
... viel Zeug ...             # lösen Sie den Absturz aus
(gdb) thread apply all bt
... HÄNGEN SIE DIESEN TEIL AN EINEN FEHLERBERICHT AN ...
(gdb)

Wenn der Prozess, den Sie zurückverfolgen wollen, schon während der Anmeldung startet, dann gehen Sie wie folgt vor:

$ pidof nautilus        # oder der Name des abgestürzten Prozesses
12345
$ gdb
(gdb) attach 12345
... viel Zeug ...
(gdb) thread apply all bt
... HÄNGEN SIE DIESEN TEIL AN EINEN FEHLERBERICHT AN ...
(gdb)

Zusätzliche debugging-Informationen

Einige Anwendungen verfügen über einen eigenen Protokollierungsmechanismus, welcher weitere Informationen über den Ablauf des Programms bereitstellt.

Beagle

http://beagle-project.org/Troubleshooting

GNOME Power Manager

GNOME Power Manager stellt einen Weg bereit, detaillierte Schritt-für-Schritt-Informationen darüber zu erlangen, was das Programm macht. Um detailliertere Informationen zu erhalten, müssen einige Argumente an gnome-power-manager übergeben werden, weshalb folgendes nötig ist:

$ killall -9 gnome-power-manager
$ gnome-power-manager --no-daemon --verbose > /tmp/gpm.log 2>&1

Diese beiden Kommandos brechen gnome-power-manager ab und starten ihn dann mit den notwendigen Parametern neu (--no-daemon --verbose), danach werden dann alle Ausgaben von g-p-m in der Datei /tmp/gpm.log gespeichert, welche Sie dann an ihren Fehlerbericht anhängen sollten.

Sollten die g-p-m-Protokolle keine nützlichen Informationen enthalten, dann können die Probleme auch aus den darunter liegenden Architekturen herrühren (HAL und pm-utils), so dass Sie dort weitere Informationen erhalten:

• pm-utils Protokolldatei ist /var/log/pm-suspend.log
• Weitere Informationen zur Fehlersuche in ACPI finden Sie hier.

GNOME-Bildschirmschoner

Am einfachsten lassen sich Fehler in gnome-screensaver folgendermaßen finden:

$ killall -9 gnome-screensaver
$ gnome-screensaver --no-daemon --debug > /tmp/gs.log 2>&1

Alle Protokollierungen werden dann in der Datei /tmp/gs.log gespeichert, welche Sie ihrem Fehlerbericht anhängen sollten.

Nautilus

Nautilus verfügt über eine eigene Infrastruktur zur Fehlerprotokollierung. Wenn Nautilus abstürzt schreibt es eine Datei namens nautilus-debug-log.txt ins Heimatverzeichnis des Nutzers, welche Sie ihrem Fehlerbericht anhängen können. Diese Datei enthält ein Protokoll ihrer letzten Aktionen und zusätzliche Informationen, welche bei der Analyse des Problems hilfreich sein können.

Zusätzlich können Sie Nautilus jederzeit dazu veranlassen, dass Fehlerprotokoll zu schreiben, indem Sie das Signal SIGUSR1 an den Prozess senden. Dies ist bspw. nützlich, wenn Sie ein Problem analysieren wollen, welches Nautilus nicht zum Absturz bringt, Sie aber dennoch Informationen benötigen. Sie können das Signale folgendermaßen absetzen:

 killall -USR1 nautilus

Ein Entwickler könnte Sie auch darum bitten, eine nautilus-debug-log.conf-Datei in ihrem Heimatverzeichnis mit dem folgenden Inhalt zu erstellen:

 [debug log]
 max lines = 1000
 enable domains = <Liste von Domänen, durch ";" getrennt>

Sie müssen Nautilus nach dem Erstellen dieser Datei neu starten! Sie erreichen dies, indem Sie sich einfach ab- und wieder anmelden.

Die folgenden Protokollierungsdomänen sind verfügbar:

• async - um asynchrone Benachrichtigungen zu debuggen.
• GLog - nur verwendet, um g_debug()-Nachrichten ins Protokoll zu integrieren; diese sind standardmäßig ausgeschlossen. Andere GLog-Ausgaben sind enthalten, da sie normalerweise aus wichtigen Meldungen bestehen.
• drives-volumes - um das Erkennen von Laufwerken, Medien und Wechseldatenträgern zu debuggen.
• desktop-links - um das Erstellen von Arbeitsflächenverknüpfungen (Arbeitsflächensymbole) zu debuggen.

Eine ~/nautilus-debug-log.conf könnte etwa so aussehen:

 [debug log]
 max lines = 5000
 enable domains = drives-volumes;async

Sabayon

Sabayon schreibt bei einem Absturz seine Fehlerprotokolle in /root/sabayon-debug-log-xxxxxxx.txt (oder was sonst das Heimatverzeichnis von root ist). Es legt diese Datei auch dann an, wenn es in eine abnorme Situation gerät, aus der es aber wieder zum Normalzustand zurückkehren kann (bspw. bei einem Fehler der beim Speichern eines Teils des Nutzerprofils auftritt).

Für debugging-Zwecke kann der Administrator eine detailliertere Protokollierung aktivieren. Um diese einzuschalten müssen Sie im Heimatverzeichnis von root eine Datei namens sabayon-debug-log.conf erstellen. Fügen Sie in diese Datei den folgenden Inhalt ein:

 [debug log]
 max lines = 1000
 enable domains = <Liste von Domänen, durch ";" getrennt>

Um zum Beispiel Protokolle für die Module storage und files-source zu erstellen, würde die letzte Zeile so aussehen:

 enable domains = storage;files-source

Im folgenden nun die verfügbaren Domänennamen. Beachten Sie, dass diese standardmäßig nicht eher protokolliert werden, bevor sie nicht in der sabayon-debug-log.conf-Datei eingetragen werden:

• user-profile - Hauptmodul zur Verarbeitung von Nutzerprofilen.
• storage - Modul zur Speicherung von Nutzerprofilen in einem .zip-Bündel.
• panel-delegate - Erkennt Änderungen die das GNOME-Panel und seine Minianwendungen betreffen.
• gconf-source - Überwacht Änderungen an GConf-Daten und protokolliert und speichert sie und stellt sie wieder her.
• files-source - Überwacht Änderungen im temporären Heimatverzeichnis Monitoring und protokolliert und speichert sie und stellt sie wieder her.
• mozilla-source - Erkennt Änderungen in der Konfiguration von Mozilla Firefox.
• proto-session - Einrichtung der unteren Ebenen der verschachtelten Sitzung (X authority, X displays, usw.).
• usermod - Systemnahe Werkzeuge zur Erstellung temporärer Heimatverzeichnisse.
• dir-monitor - Systemnahe Überwachung des Dateisystems.
• user-db - Betreut Verknüpfungen zwischen Nutzern und Profilen.
• cache - Empfängt die Inhalte entfernter URIs und speichert sie zwischen.
• admin-tool - Operationen auf höchster Ebene im Sabyon-Program (normalerweise nicht benötigt).
• sabayon-apply - Operationen auf höchster Ebene im sabayon-apply helper-Programm (normalerweise nicht benötigt).
• sabayon-session - Operationen auf höchster Ebene im sabayon-session helper-Programm (normalerweise nicht benötigt).
• deprecated - Schaltet Warnungen über auslaufende Funktionen in Python oder pygtk ein (normalerweise nicht benötigt).