Os aplicativos X alertam "Não foi possível conectar ao barramento de acessibilidade:" no stderr

30

Parece que todo aplicativo do terminal envia avisos e mensagens de erro, mesmo que pareça funcionar bem.

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

Raposa de fogo:

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

A lista continua. Esse comportamento é comum ou há algo errado com meu sistema? Como corrijo esses problemas?

— vosov
fonte

Na minha experiência, sim, isso é bastante comum. Existem muitos avisos, ganhos e erros encontrados por vários pacotes. Quando lançados no terminal, esses ganhos são enviados para o terminal, para que você possa vê-los. Quando iniciado, como normalmente se inicia um aplicativo X, você não parece. Eles podem estar registrados em algum lugar, mas geralmente não são, com base no aplicativo. Há anos que tenho seguido esta regra simples "se o aplicativo está funcionando e o erro não é muito assustador, ignorá-lo"

— Karl Wilbur

53

Infelizmente, as bibliotecas GTK (usadas em particular pelo GNOME) tendem a emitir muitas mensagens assustadoras. Às vezes, essas mensagens indicam possíveis erros, às vezes são totalmente falsas, e é impossível dizer qual é qual sem aprofundar no código. Como usuário final, você não pode fazer nada sobre isso. Você pode relatá-los como bugs (mesmo que o programa se comporte corretamente, emitir um erro espúrio é um bug), mas quando o programa está basicamente funcionando, esses bugs são compreensivelmente tratados como prioridade muito baixa.

O aviso de acessibilidade é um bug conhecido, com uma solução fácil se você não usar nenhum recurso de acessibilidade:

export NO_AT_BRIDGE=1

Na minha experiência, os Gtk-CRITICALbugs são completamente espúrios; embora indiquem um erro de programação em algum lugar, eles não devem ser relatados aos usuários finais, apenas ao desenvolvedor que escreveu o programa (ou à biblioteca subjacente - geralmente o desenvolvedor do próprio programa não pode fazer nada a respeito, porque é um bug em uma biblioteca chamada por uma biblioteca chamada por uma biblioteca usada no programa).

— Gilles 'SO- parar de ser mau'
fonte

Então, eu recebo esse erro enquanto o gerenciador de janelas (incrível) está sendo iniciado. Então, onde devo colocar a exportcoisa?

— UlfR 22/01

@UlfR: Você colocaria no seu .bashrc.

— Ben Crowell

@UlfR Na ~/.profileou na sua configuração incrível (não sei qual é a sintaxe incrível). Ou ~/.xinitrcse você usar startx, ou ~/.xsessionse você usar uma sessão clássica do X11 (em oposição ao gerenciador de sessões do ambiente de área de trabalho).

— Gilles 'SO- stop be evil'

@BenCrowell Não, não em .bashrc: isso se aplicaria apenas a um programa iniciado a partir de um terminal. Definir uma variável de ambiente .bashrcquase sempre está errado.

— Gilles 'SO- stop be evil'

2

Encontrei em algum lugar, mas esqueci o link.

Para corrigi-lo, execute:

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

Se você não possui o dbus-uuidgen, ele está no pacote dbus, que pode ser instalado emitindo:

yum install dbus

— PK.Shrestha
fonte

3

Não corrige o problema para mim.

— 58517 Ze Zeythth

1

Não tenho certeza dos primeiros erros, mas parece que o Firefox corrigiu o problema g_slice_set_config na versão 42. De acordo com o relatório de erros , isso afeta o glib 2.35 e mais recente.

— MVanOrder
fonte

1

NÃO altere / var / lib / dbus / id da máquina! Primeiro veja se está vazio! Leia a página de manual!

de: man dbus-uuidgen

Se você tentar alterar um ID de máquina existente em um sistema em execução, provavelmente resultará em coisas ruins acontecendo. Não tente alterar este arquivo. Além disso, não faça o mesmo em dois sistemas diferentes; precisa ser diferente a qualquer momento, existem dois kernels diferentes em execução

Eu tenho o

conectar ao barramento de acessibilidade: falha ao conectar ao soquete / tmp / dbus-oYuNBK96uX: conexão recusada

mensagem de erro, conectando de outro computador com:

ssh -YC nome_do_usuário@1.2.3.4

e executando thunar e evince.

Também tentei o mesmo no sistema local e nenhum erro foi relatado Eu também digitei

cat / var / lib / dbus / ID da máquina

e já tem um uuid

O que eu acho que pode ser a causa desse erro é que o xserver em execução na máquina usada como terminal possui um uuid diferente do sistema remoto.

Não fiz mais experimentos, porque alterar o ID da máquina durante a execução acaba com algum comportamento inadequado, de acordo com a página de manual citada acima.

— user350102
fonte