X applications warn "Couldn't connect to accessibility bus:" on stderr

Question

It seems like every application from the terminal gives warnings and error messages, even though it appears to run fine.

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

The list goes on. Is this behavior common or is there something wrong with my system? How I fix these issues?

Solution 1

Unfortunately, GTK libraries (used in particular by GNOME) tend to emit a lot of scary-looking messages. Sometimes these messages indicate potential bugs, sometimes they're totally spurious, and it's impossible to tell which is which without delving deep into the code. As an end user, you can't do anything about it. You can report those as bugs (even if the program otherwise behaves correctly, emitting spurious error messages is a bug), but when the program is basically working, these bugs are understandably treated as very low priority.

The accessibility warning is a known bug with an easy workaround if you don't use any accessibility feature:

export NO_AT_BRIDGE=1

In my experience, Gtk-CRITICAL bugs are completely spurious; while they do indicate a programming error somewhere, they shouldn't be reported to end-users, only to the developer who wrote the program (or the underlying library — often the developer of the program itself can't do anything about it because it's a bug in a library that's called by a library that's called by a library that's used in the program).

Solution 2

DON'T change /var/lib/dbus/machine-id! First see if it is empty! Read the man page!

from: man dbus-uuidgen

If you try to change an existing machine-id on a running system, it will probably result in bad things happening. Don't try to change this file. Also, don't make it the same on two different systems; it needs to be different anytime there are two different kernels running

I got the

connect to accessibility bus: Failed to connect to socket /tmp/dbus-oYuNBK96uX: Connection refused

error message, connecting from other computer with:

ssh -YC [email protected]

and running thunar and evince.

Also tried the same in the local system and no error was reported I also typed

cat /var/lib/dbus/machine-id

and it already has one uuid

What I think may be the cause of that error is that the xserver running in the machine used as terminal has a different uuid than the remote system.

I did not more experiments, because changing the machine-id during execution ends in some misbehavior, according to the man page quoted above.

Solution 3

I found it somewhere but I forgot the link to it.

To fix it, run:

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

If you don’t have dbus-uuidgen , it’s in the dbus package, which can be installed by issuing:

yum install dbus

Solution 4

I'm not sure about the first errors, but it appears Firefox fixed the g_slice_set_config issue in version 42. According to their bug report, it affects glib 2.35 and newer.

View more solutions

Comments

[Admin]

In my experience, yes, this is quite common. There are many notices, earnings and errors that are encountered by various packages. When launched from the terminal, these earnings are sent to the terminal, so you get to see them. When launched as one would normally launch an X app, you don't seem them. They might be logged somewhere but usually aren't, based on the application. For years I have followed this simple rule of thumb "if the app is working and the error isn't too scary, ignore it"

[Admin]

That is a terrible rule of thumb... that warning isn't for nothing... it means something is wrong and unexpected... (possibly the system you're running on... or possibly the developer's brain...) ... either way, getting into the habbit of ignoring warnings and errors is bad practice.

[UlfR]

So I get this error while the windowmanager (awesome) is starting. So where should I put the export-thing?

[Gilles 'SO- stop being evil']

@UlfR In ~/.profile or in your awesome configuration (I don't know what the syntax is in awesome). Or in ~/.xinitrc if you use startx, or in ~/.xsession if you use a classic X11 session (as opposed to a desktop environment's own session manager).