Red Hat Bugzilla – Bug 1471916
Cannot start gnome-terminal when no locale is set
Last modified: 2018-05-07 10:41:40 EDT
Description of problem:
On a fresh Fedora 26 system without any locale settings, the gnome shell terminal doesn't start. Instead, it silently fails.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install Fedora 26 without setting any locale information (i.e. empty /etc/locale.conf, skip gnome shell welcome dialog with language settings).
2. Login from GDM to gnome shell
3. Start Terminal
Nothing happens in the graphical user interface. No terminal window appears. No error dialog appears.
The system journal has these error messages:
Jul 17 15:44:40 example.org systemd: Starting GNOME Terminal Server...
Jul 17 15:44:40 example.org dbus-daemon: [session uid=1000 pid=2151] Successfully activated service 'org.gnome.Calculator.SearchProvider'
Jul 17 15:44:40 example.org gnome-terminal-server: Non UTF-8 locale (ANSI_X3.4-1968) is not supported!
Jul 17 15:44:40 example.org systemd: gnome-terminal-server.service: Main process exited, code=exited, status=8/n/a
Jul 17 15:44:40 example.org systemd: Failed to start GNOME Terminal Server.
The terminal window shows up. Or an error message is displayed - i.e. an error dialg - since this is a GUI application.
Starting an xterm from the gnome shell launcher works. There the following environment variables are set:
Bug 1185040 is related, although it is triggered by an alternative desktop setup.
This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
I doubt this will ever be fixed. Is there any particular reason that you want to have an empty /etc/locale.conf?
Well, the point of this bug report is: having an important GUI application that has the worst failure mode is quite bad.
It isn't about eliminating /etc/locale.conf.
I mean, when you are (for whatever reason, e.g. filesystem corruption, bug in the installer, accidental skipping the welcome dialog (!), ...) in the situation that you don't have the right /etc/locale.conf and gnome-terminal feels to be extravagant enough to only work with UTF-8 locales explicitly set, then the least you should expect is a properly displayed error message - e.g. in an error dialog.
As-is, it just silently fails, i.e. there is no visible feedback, it just doesn't start.
Improving this failure mode would increase the user-friendliness of the Gnome desktop, I would argue.
“Interesting” related issue (side effect?): currently there is a bug (#1574222) which makes it so that after an upgrade to F28 the language packs are not installed as they should (glibc-language-* missing amongst other things) and one cannot launch the terminal to debug the issue.
(In reply to Alexandre Franke from comment #4)
> “Interesting” related issue (side effect?): currently there is a bug
> (#1574222) which makes it so that after an upgrade to F28 the language packs
> are not installed as they should (glibc-language-* missing amongst other
> things) and one cannot launch the terminal to debug the issue.
I confirm, see bug 1570924.