46

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?

Jonas Stein
  • 3,898
  • 4
  • 34
  • 55
vosov
  • 563
  • 1
  • 4
  • 4
  • 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" – Karl Wilbur Sep 17 '15 at 14:06
  • 1
    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. – BrainSlugs83 Jul 02 '22 at 21:39

4 Answers4

75

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

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
  • 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. –  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). – Gilles 'SO- stop being evil' Jan 24 '19 at 22:54
  • 1
    @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. – Gilles 'SO- stop being evil' Jan 24 '19 at 22:54
  • **Please don’t confuse Windows software practices for normal.** You misunderstand how logging works on Unix. Yes, those things SHOULD be output by the programs! But 1. to the logging daemon (if available), and 2. depending on the log level! … And the thing with running it from the terminal, is that by doing so, you by definition say that you want the logging output to go to stderr (too)! – Evi1M4chine Nov 18 '22 at 09:17
  • @Evi1M4chine If anything, Gtk is more Windows-like: it assumes that users won't look at a program's stderr. As you say, stderr is the wrong channel to report “this program was badly written, it's using a library incorrectly, now would be a good time to pray that your data won't be completely mangled”. – Gilles 'SO- stop being evil' Nov 18 '22 at 11:03
3

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

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 X server 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.

Cristian Ciupitu
  • 2,430
  • 1
  • 22
  • 29
user350102
  • 31
  • 2
2

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
Stephen Rauch
  • 4,209
  • 14
  • 22
  • 32
PK.Shrestha
  • 21
  • 2
1

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.

MVanOrder
  • 313
  • 1
  • 7