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


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


** (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


(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?

  • 1
    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" Sep 17 '15 at 14:06

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).

  • So I get this error while the windowmanager (awesome) is starting. So where should I put the export-thing?
    – UlfR
    Jan 22 '19 at 18:13
  • @UlfR: You would put it in your .bashrc.
    – user39248
    Jan 24 '19 at 21:58
  • @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). Jan 24 '19 at 22:54
  • @BenCrowell No, not in .bashrc: it would only apply to a program started from a terminal. Defining an environment variable in .bashrc is almost always wrong. Jan 24 '19 at 22:54

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 user_name@

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.


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
  • 4
    Does not fix the issue for me.
    – Zeimyth
    Oct 6 '17 at 14:21

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.