Le applicazioni X avvertono "Impossibile connettersi al bus di accessibilità:" su stderr

30

Sembra che ogni applicazione dal terminale fornisca avvisi e messaggi di errore, anche se sembra funzionare correttamente.

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

Firefox:

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

L'elenco continua. Questo comportamento è comune o c'è qualcosa che non va nel mio sistema? Come risolvo questi problemi?

— vosov
fonte

Nella mia esperienza, sì, questo è abbastanza comune. Ci sono molti avvisi, guadagni ed errori che vengono riscontrati da vari pacchetti. Quando vengono avviati dal terminale, questi guadagni vengono inviati al terminale, in modo da poterli vedere. Quando lanciato come si avvia normalmente un'app X, non li sembri. Potrebbero essere registrati da qualche parte ma di solito non lo sono, in base all'applicazione. Per anni ho seguito questa semplice regola empirica "se l'app funziona e l'errore non è troppo spaventoso, ignoralo"

— Karl Wilbur,

53

Sfortunatamente, le librerie GTK (usate in particolare da GNOME) tendono ad emettere molti messaggi dall'aspetto spaventoso. A volte questi messaggi indicano potenziali bug, a volte sono totalmente falsi, ed è impossibile dire quale sia senza approfondire il codice. Come utente finale, non puoi farci nulla. Puoi segnalarli come bug (anche se il programma si comporta diversamente, l'emissione di messaggi di errore spuri è un bug), ma quando il programma funziona sostanzialmente, questi bug sono comprensibilmente trattati con priorità molto bassa.

L'avviso di accessibilità è un bug noto con una soluzione semplice se non si utilizza alcuna funzionalità di accessibilità:

export NO_AT_BRIDGE=1

Nella mia esperienza, i Gtk-CRITICALbug sono completamente falsi; mentre indicano un errore di programmazione da qualche parte, non dovrebbero essere segnalati agli utenti finali, ma solo allo sviluppatore che ha scritto il programma (o la libreria sottostante), spesso lo sviluppatore del programma stesso non può farci nulla perché è un bug in una libreria chiamata da una libreria chiamata da una libreria utilizzata nel programma).

— Gilles 'SO- smetti di essere cattivo'
fonte

Quindi ottengo questo errore mentre il windowmanager (fantastico) sta iniziando. Quindi dove dovrei mettere il- exportcosa?

— UlfR

@UlfR: lo inseriresti nel tuo .bashrc.

— Ben Crowell,

@UlfR Nella ~/.profileo nella tua fantastica configurazione (non so quale sia la sintassi nella fantastica). O ~/.xinitrcse si utilizza startxo ~/.xsessionse si utilizza una sessione X11 classica (al contrario del gestore di sessioni di un ambiente desktop).

— Gilles 'SO- smetti di essere malvagio' il

@BenCrowell No, non presente .bashrc: si applica solo a un programma avviato da un terminale. Definire una variabile d'ambiente in .bashrcè quasi sempre sbagliato.

— Gilles 'SO- smetti di essere malvagio' il

2

L'ho trovato da qualche parte ma ho dimenticato il link ad esso.

Per risolverlo, esegui:

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

Se non hai dbus-uuidgen, è nel pacchetto dbus, che può essere installato emettendo:

yum install dbus

— PK.Shrestha
fonte

3

Non risolve il problema per me.

— Zeimyth,

1

Non sono sicuro dei primi errori, ma sembra che Firefox abbia risolto il problema g_slice_set_config nella versione 42. Secondo la loro segnalazione di bug , interessa glib 2.35 e successivi.

— MVanOrder
fonte

1

NON cambiare / var / lib / dbus / machine-id! Per prima cosa vedi se è vuoto! Leggi la pagina man!

da: man dbus-uuidgen

Se provi a cambiare un id macchina esistente su un sistema in esecuzione, probabilmente si verificheranno cose brutte. Non provare a cambiare questo file. Inoltre, non farlo allo stesso modo su due sistemi diversi; deve essere diverso ogni volta che ci sono due kernel diversi in esecuzione

io ho il

connessione al bus di accessibilità: impossibile connettersi alla presa / tmp / dbus-oYuNBK96uX: connessione rifiutata

messaggio di errore, connessione da un altro computer con:

ssh -YC nome_utente@1.2.3.4

e correndo thunar ed evince.

Ho anche provato lo stesso nel sistema locale e non è stato segnalato alcun errore Ho anche digitato

cat / var / lib / dbus / machine-id

e ne ha già uno uuid

Ciò che penso possa essere la causa di questo errore è che l'xserver in esecuzione nella macchina utilizzata come terminale ha un uuid diverso rispetto al sistema remoto.

Non ho fatto più esperimenti, perché la modifica dell'ID macchina durante l'esecuzione termina in qualche comportamento scorretto, secondo la pagina man sopra citata.

— user350102
fonte