Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#50069 - [gnome-terminal] gnome-terminal cannot be opened after a few uses.

Attached to Project: Arch Linux
Opened by Javier Fernández (WyRe) - Saturday, 16 July 2016, 12:15 GMT
Last edited by Jan Alexander Steffens (heftig) - Thursday, 02 February 2017, 12:00 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Jan Alexander Steffens (heftig)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 6
Private No


First time, just when OS is loaded gnome-terminal works fine (at least this first time) after one or few uses it crashes and I cannot open again. I've checking locale and even I've regenerated it but issue still persist. If I try to open gnome terminal from xterm I get the following msg:

Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: Timeout was reached

Thank you so much.
This task depends upon

Closed by  Jan Alexander Steffens (heftig)
Thursday, 02 February 2017, 12:00 GMT
Reason for closing:  Fixed
Additional comments about closing:  gnome-session 3.22.2-2
Comment by Jan Alexander Steffens (heftig) - Friday, 22 July 2016, 12:45 GMT
Sounds like the gnome-terminal-server process froze. Can you get a backtrace from gdb?
Comment by Javier Fernández (WyRe) - Friday, 22 July 2016, 15:05 GMT
How could I do a backtrace from gdb? xD

I'm having more issues with locales, because for example, when I restart nautilus with "nautilus -q && nautilus" is not restarted in muy locale language :(
Comment by rdeckard (rdeckard) - Friday, 22 July 2016, 15:53 GMT
I came here from this bug:

In that one I solved the issue by downgrading gnome-session to 3.20.1. Does that work for this issue? Can you post your entire journal for the boot where terminal won't open?
Comment by Javier Fernández (WyRe) - Friday, 22 July 2016, 16:21 GMT
That's all journal from that boot (just rebooted) I've also noticed that tty and first login in gdm are not in my locale language also. That's so strange :(

   journalterm (263.2 KiB)
Comment by rdeckard (rdeckard) - Friday, 22 July 2016, 17:32 GMT
Here's the simplest way to reproduce the bug. Open gnome-terminal and type the following:


Then close gnome-terminal and try to re-open it.

I've noticed that some scripts that depend on getting the version of gnome-session call "gnome-session --version" after setting the locale to C in their script as above (i.e. screenfetch). This might be related
Comment by Javier Fernández (WyRe) - Friday, 22 July 2016, 17:41 GMT
Well, really today I cannot even open gnome-terminal xD
Comment by Jan Alexander Steffens (heftig) - Friday, 22 July 2016, 18:42 GMT
Seems that gnome-session pushes its environment to DBus no matter the arguments.
Comment by Javier Fernández (WyRe) - Monday, 25 July 2016, 10:25 GMT
Gedit doesn't keep right locale, I'm begin to suspect what could it be general Gnome issue ... :S
Comment by Richard Potter (rpotter28) - Sunday, 11 September 2016, 17:51 GMT
I also just had this problem, same error message. Turns out it was caused by screenFetch, which was being loaded from my .bashrc.
If you are using screenFetch, try not loading it.

Comment by Javier Fernández (WyRe) - Tuesday, 27 September 2016, 18:52 GMT
I still have this issue, even removing screenfetch from my bashrc
Comment by Javier Fernández (WyRe) - Tuesday, 11 October 2016, 22:22 GMT
Well certainly I've noticed a performance improvement since I've removed screenfetch from my .bashrc, but I don't know if is entirely due this.
Comment by Alexander (xander) - Saturday, 29 October 2016, 17:03 GMT
Patching to revert it to its 3.20.1 state solved this problem for me (screenfetch broke my locale from ru_RU to en_US on every execution).
You may try to build gnome-session package using PKGBUILD and patch from attachment. Actually it removes dbus-update-activation-environment call upon GNOME session startup.
Comment by Javier Fernández (WyRe) - Saturday, 29 October 2016, 17:51 GMT
There is no any alternative to screenfetch?
Comment by Alexander (xander) - Saturday, 29 October 2016, 17:53 GMT
This is NOT a screenfetch bug, but gnome-session one.
There are pretty many alternatives to screenfetch, from archey/archey3 to neofetch.
Comment by George (kouros17) - Monday, 31 October 2016, 11:39 GMT
The patch by Alexander (xander) solved my problem!
Please push the patch to the official repos.
Comment by Alexander (xander) - Monday, 31 October 2016, 11:50 GMT
This patch really may be a good temporary fix of this annoying problem, until this will be resolved upstream (at least I hope so, but I also hoped that 3.22 would fix this).
Comment by Alexander (xander) - Tuesday, 08 November 2016, 16:37 GMT
The above patch is also compatible with new gnome-session-3.22.2-1, although I'm sad that it hasn't been applied upstream or in Arch's official PKGBUILD.
Comment by Jan Alexander Steffens (heftig) - Thursday, 02 February 2017, 11:55 GMT
Is this fixed with gnome-session 3.22.2-2?
Comment by Alexander (xander) - Thursday, 02 February 2017, 11:57 GMT
Yup, 3.22.2-2 introduces cherry-pick of some newer git commits that resolve this prob.