Starting X applications from the terminal and the warnings that follow
Clash Royale CLAN TAG#URR8PPP
up vote
24
down vote
favorite
I am trying to get to grips with using the terminal for most of my computing activities. One thing that has been bothering me for a while is launching X applications from the terminal.
It seems like every such application likes to give 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 behaviour common or is there something wrong with my system? Should I take note of all these messages? Can I actually fix these issues on my end or are these just small bugs in the software?
terminal x11
add a comment |Â
up vote
24
down vote
favorite
I am trying to get to grips with using the terminal for most of my computing activities. One thing that has been bothering me for a while is launching X applications from the terminal.
It seems like every such application likes to give 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 behaviour common or is there something wrong with my system? Should I take note of all these messages? Can I actually fix these issues on my end or are these just small bugs in the software?
terminal x11
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
add a comment |Â
up vote
24
down vote
favorite
up vote
24
down vote
favorite
I am trying to get to grips with using the terminal for most of my computing activities. One thing that has been bothering me for a while is launching X applications from the terminal.
It seems like every such application likes to give 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 behaviour common or is there something wrong with my system? Should I take note of all these messages? Can I actually fix these issues on my end or are these just small bugs in the software?
terminal x11
I am trying to get to grips with using the terminal for most of my computing activities. One thing that has been bothering me for a while is launching X applications from the terminal.
It seems like every such application likes to give 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 behaviour common or is there something wrong with my system? Should I take note of all these messages? Can I actually fix these issues on my end or are these just small bugs in the software?
terminal x11
terminal x11
asked Sep 17 '15 at 9:32
vosov
223124
223124
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
add a comment |Â
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
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
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
add a comment |Â
4 Answers
4
active
oldest
votes
up vote
44
down vote
accepted
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).
add a comment |Â
up vote
1
down vote
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.
add a comment |Â
up vote
1
down vote
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
2
Does not fix the issue for me.
â Zeimyth
Oct 6 '17 at 14:21
add a comment |Â
up vote
0
down vote
no permission to run this command as end user.
New contributor
1
This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review
â Jeff Schaller
20 mins ago
add a comment |Â
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
44
down vote
accepted
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).
add a comment |Â
up vote
44
down vote
accepted
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).
add a comment |Â
up vote
44
down vote
accepted
up vote
44
down vote
accepted
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).
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).
answered Sep 18 '15 at 1:59
Gilles
517k12310311559
517k12310311559
add a comment |Â
add a comment |Â
up vote
1
down vote
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.
add a comment |Â
up vote
1
down vote
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.
add a comment |Â
up vote
1
down vote
up vote
1
down vote
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.
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.
answered Sep 17 '15 at 13:43
MVanOrder
1786
1786
add a comment |Â
add a comment |Â
up vote
1
down vote
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
2
Does not fix the issue for me.
â Zeimyth
Oct 6 '17 at 14:21
add a comment |Â
up vote
1
down vote
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
2
Does not fix the issue for me.
â Zeimyth
Oct 6 '17 at 14:21
add a comment |Â
up vote
1
down vote
up vote
1
down vote
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
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
edited May 1 '17 at 14:56
Stephen Rauch
3,278101328
3,278101328
answered May 1 '17 at 14:32
PK.Shrestha
111
111
2
Does not fix the issue for me.
â Zeimyth
Oct 6 '17 at 14:21
add a comment |Â
2
Does not fix the issue for me.
â Zeimyth
Oct 6 '17 at 14:21
2
2
Does not fix the issue for me.
â Zeimyth
Oct 6 '17 at 14:21
Does not fix the issue for me.
â Zeimyth
Oct 6 '17 at 14:21
add a comment |Â
up vote
0
down vote
no permission to run this command as end user.
New contributor
1
This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review
â Jeff Schaller
20 mins ago
add a comment |Â
up vote
0
down vote
no permission to run this command as end user.
New contributor
1
This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review
â Jeff Schaller
20 mins ago
add a comment |Â
up vote
0
down vote
up vote
0
down vote
no permission to run this command as end user.
New contributor
no permission to run this command as end user.
New contributor
New contributor
answered 42 mins ago
Nan Reid
1
1
New contributor
New contributor
1
This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review
â Jeff Schaller
20 mins ago
add a comment |Â
1
This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review
â Jeff Schaller
20 mins ago
1
1
This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review
â Jeff Schaller
20 mins ago
This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review
â Jeff Schaller
20 mins ago
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f230238%2fstarting-x-applications-from-the-terminal-and-the-warnings-that-follow%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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