X-Anwendungen warnen "Konnte keine Verbindung zum Accessibility-Bus herstellen:" auf stderr

30

Es scheint, als ob jede Anwendung vom Terminal Warnungen und Fehlermeldungen ausgibt, obwohl sie gut zu funktionieren scheint.

Emacs:

** (emacs:5004): WARNING **: Couldn't connect to accessibility bus:    
Failed to connect to socket /tmp/dbus-xxfluS2Izg: Connection refused

Evince:

** (evince:5052): WARNING **: Couldn't connect to accessibility bus:    
Failed to connect to socket /tmp/dbus-xxfluS2Izg: Connection refused

(evince:4985): Gtk-CRITICAL **: gtk_widget_show: assertion 
'GTK_IS_WIDGET (widget)' failed

(evince:4985): Gtk-CRITICAL **: gtk_widget_show: assertion 
'GTK_IS_WIDGET (widget)' failed

Feuerfuchs:

(process:5059): GLib-CRITICAL **: g_slice_set_config: assertion 
'sys_page_size == 0' failed

Die Liste geht weiter. Ist dieses Verhalten häufig oder stimmt etwas mit meinem System nicht? Wie behebe ich diese Probleme?

— vosov
quelle

Nach meiner Erfahrung ist dies durchaus üblich. Es gibt viele Hinweise, Einnahmen und Fehler, auf die verschiedene Pakete stoßen. Beim Start über das Terminal werden diese Einnahmen an das Terminal gesendet, sodass Sie sie sehen können. Wenn Sie eine X-App wie gewohnt starten, scheinen Sie sie nicht zu haben. Sie werden möglicherweise an einem beliebigen Ort protokolliert, in der Regel jedoch nicht, je nach Anwendung. Seit Jahren befolge ich diese einfache Faustregel: "Wenn die App funktioniert und der Fehler nicht zu gruselig ist, ignoriere ihn"

— Karl Wilbur,

53

Leider neigen GTK-Bibliotheken (die insbesondere von GNOME verwendet werden) dazu, viele beängstigend aussehende Nachrichten auszusenden. Manchmal weisen diese Meldungen auf potenzielle Fehler hin, manchmal sind sie völlig fälschlich, und es ist unmöglich zu sagen, welcher Fehler welcher ist, ohne tief in den Code einzutauchen. Als Endbenutzer können Sie nichts dagegen tun. Sie können diese als Fehler melden (auch wenn das Programm sich ansonsten korrekt verhält und falsche Fehlermeldungen ausgibt). Wenn das Programm jedoch im Grunde funktioniert, werden diese Fehler verständlicherweise als Fehler mit sehr niedriger Priorität behandelt.

Die Eingabehilfenwarnung ist ein bekannter Fehler, der sich leicht umgehen lässt, wenn Sie keine Eingabehilfenfunktion verwenden:

export NO_AT_BRIDGE=1

Nach meiner Erfahrung sind Gtk-CRITICALBugs völlig falsch. Obwohl sie irgendwo auf einen Programmierfehler hinweisen, sollten sie nicht an Endbenutzer weitergeleitet werden, sondern nur an den Entwickler, der das Programm geschrieben hat (oder die zugrunde liegende Bibliothek - oft kann der Entwickler des Programms selbst nichts dagegen unternehmen, weil dies der Fall ist ein Fehler in einer Bibliothek, die von einer Bibliothek aufgerufen wird, die von einer im Programm verwendeten Bibliothek aufgerufen wird).

— Gilles 'SO - hör auf böse zu sein'
quelle

So bekomme ich diesen Fehler, während der Windowmanager (awesome) startet. Also, wo soll ich das export-Ding hinstellen?

— UlfR

@UlfR: Sie würden es in Ihre .bashrc einfügen.

— Ben Crowell

@UlfR In ~/.profileoder in Ihrer fantastischen Konfiguration (ich weiß nicht, wie die Syntax fantastisch ist). Oder in, ~/.xinitrcwenn Sie verwenden startx, oder in, ~/.xsessionwenn Sie eine klassische X11-Sitzung verwenden (im Gegensatz zum Sitzungsmanager einer Desktop-Umgebung).

— Gilles 'SO - hör auf böse zu sein'

@BenCrowell Nein, nicht in .bashrc: Dies gilt nur für ein Programm, das von einem Terminal aus gestartet wurde. Das Definieren einer Umgebungsvariablen in .bashrcist fast immer falsch.

— Gilles 'SO - hör auf böse zu sein'

2

Ich habe es irgendwo gefunden, aber den Link dazu vergessen.

Führen Sie Folgendes aus, um das Problem zu beheben:

dbus-uuidgen > /var/lib/dbus/machine-id

Wenn Sie nicht über dbus-uuidgen verfügen, befindet es sich im dbus-Paket, das durch Folgendes installiert werden kann:

yum install dbus

— PK.Shrestha
quelle

3

Behebt das Problem nicht für mich.

— Zeimyth

1

Ich bin mir bei den ersten Fehlern nicht sicher, aber es scheint, dass Firefox das Problem g_slice_set_config in Version 42 behoben hat. Laut ihrem Fehlerbericht betrifft es glib 2.35 und neuer.

— MVanOrder
quelle

1

Ändern Sie / var / lib / dbus / machine-id NICHT! Zuerst sehen, ob es leer ist! Lesen Sie die Manpage!

von: man dbus-uuidgen

Wenn Sie versuchen, eine vorhandene Computer-ID auf einem laufenden System zu ändern, kann dies möglicherweise zu schlechten Ergebnissen führen. Versuchen Sie nicht, diese Datei zu ändern. Machen Sie es auch nicht auf zwei verschiedenen Systemen gleich. Es muss immer dann unterschiedlich sein, wenn zwei verschiedene Kernel ausgeführt werden

ich habe das

Verbindung zum Accessibility-Bus herstellen: Verbindung zum Socket / tmp / dbus-oYuNBK96uX fehlgeschlagen: Verbindung abgelehnt

Fehlermeldung, Verbindung von einem anderen Computer mit:

ssh -YC benutzername@1.2.3.4

und laufen thunar und zeugen.

Auch versucht das gleiche im lokalen System und es wurde kein Fehler gemeldet, den ich auch getippt habe

cat / var / lib / dbus / Rechner-ID

und es hat schon eine uuid

Was ich denke, kann die Ursache für diesen Fehler sein, dass der xserver, der auf dem als Terminal verwendeten Computer ausgeführt wird, eine andere UUID als das ferne System hat.

Ich habe nicht mehr experimentiert, da das Ändern der Rechner-ID während der Ausführung zu einem Fehlverhalten führt, wie in der oben zitierten Manpage angegeben.

— user350102
quelle