it-swarm.com.de

X-Anwendungen warnen auf stderr "Verbindung zum Eingabehilfenbus konnte nicht hergestellt werden:"

Es scheint, als ob jede Anwendung vom Terminal Warnungen und Fehlermeldungen ausgibt, obwohl sie anscheinend einwandfrei läuft.

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?

33
vosov

Leider neigen GTK-Bibliotheken (insbesondere von GNOME verwendet) dazu, viele beängstigend aussehende Nachrichten zu senden. Manchmal weisen diese Meldungen auf potenzielle Fehler hin, manchmal sind sie völlig falsch, und es ist unmöglich zu sagen, welche welche sind, ohne tief in den Code einzutauchen. Als Endbenutzer können Sie nichts dagegen tun. Sie können diese als Fehler melden (auch wenn sich das Programm ansonsten korrekt verhält, ist das Ausgeben von falschen Fehlermeldungen ein Fehler), aber wenn das Programm im Grunde funktioniert, werden diese Fehler verständlicherweise als sehr niedrig priorisiert behandelt.

Die Barrierefreiheitswarnung ist ein bekannter Fehler mit einer einfachen Problemumgehung, wenn Sie keine Barrierefreiheitsfunktion verwenden:

export NO_AT_BRIDGE=1

Durch meine Erfahrung, Gtk-CRITICAL Bugs sind völlig falsch; Obwohl sie irgendwo auf einen Programmierfehler hinweisen, sollten sie nicht an Endbenutzer gemeldet werden, sondern nur an den Entwickler, der das Programm geschrieben hat (oder an die zugrunde liegende Bibliothek - häufig kann der Entwickler des Programms selbst nichts dagegen tun, weil dies der Fall ist ein Fehler in einer Bibliothek, der von einer Bibliothek aufgerufen wird, die von einer Bibliothek aufgerufen wird, die im Programm verwendet wird).

Ändern Sie NICHT/var/lib/dbus/machine-id! Überprüfen Sie zuerst, 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, führt dies wahrscheinlich dazu, dass schlimme Dinge passieren. Versuchen Sie nicht, diese Datei zu ändern. Machen Sie es auch auf zwei verschiedenen Systemen nicht gleich. Es muss immer anders sein, wenn zwei verschiedene Kernel ausgeführt werden

Ich habe das

verbindung zum Eingabehilfenbus herstellen: Verbindung zu Socket/tmp/dbus-oYuNBK96uX fehlgeschlagen: Verbindung abgelehnt

fehlermeldung, Verbindung von einem anderen Computer mit:

ssh -YC [email protected]

und thunar laufen und evince.

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

cat/var/lib/dbus/machine-id

und es hat schon eine uuid

Was meiner Meinung nach die Ursache für diesen Fehler sein kann, ist, dass der x-Server, der auf dem als Terminal verwendeten Computer ausgeführt wird, eine andere UUID hat als das Remote-System.

Ich habe keine weiteren Experimente durchgeführt, da das Ändern der Maschinen-ID während der Ausführung laut der oben zitierten Manpage zu einem Fehlverhalten führt.

2
user350102

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 wie folgt installiert werden kann:

yum install dbus
2
PK.Shrestha

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

1
MVanOrder