terminal won't launch with a customized locale

Bug #1448563 reported by Rob Locher
30
This bug affects 6 people
Affects Status Importance Assigned to Milestone
gnome-terminal (Ubuntu)
Confirmed
High
Unassigned

Bug Description

Yesterday I upgraded to Ubuntu 15.04 "Vivid Vervet", and I couldn't launch a gnome-terminal. Shift+Ctrl+T didn't seem to do anything, nor did typing "terminal" into the dash. Fortunately, xterm still worked. Typing "ps aux" (into an xterm terminal) revealed a few instances marked "defunct".

The problem turns out to be my custom locale. (I didn't discover this myself, except by using Google.) I typed "LANG=en_US.UTF-8" into my xterm terminal, and then "gnome-terminal &", and then I had a gnome-terminal running.

This bug should be fairly easy to replicate once a custom locale has been installed. I'll attach my custom locale file "rob_custom" to this bug, which could be used for testing the bug. (My locale is based on en_US.UTF-8 but uses 24-hour time, YYYY-MM-DD dates, and the metric system.)

To install the custom locale, go to http://lh.2xlibre.net/help/install_locale/ and download the "install_locale.py" script. The first line of the script will need to be changed from ""#!usr/bin/env python" to "#!/usr/bin/python", and the script will need to be made executable of course. Download the "rob_custom" file from this bug, and put it in /usr/share/i18n/locales/ . Then run "install_locale.py /usr/share/i18n/locales/rob_custom", which should successfully install the locale.

Installing the locale won't make it your default locale. To change the locale temporarily, change the LANG environment variable, i.e. "LANG=rob_custom.UTF-8".

The attachment to this bug consists of a .zip file composed of two files: my custom locale "rob_custom", and a simple program file locale-test.c, which can be compiled with the command "gcc -o locale-test locale-test.c". The program displays the date and time strings according to the installed locale, which is useful for testing whether the locale has been changed successfully.

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: gnome-terminal 3.14.2-0ubuntu3
ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
Uname: Linux 3.19.0-15-generic x86_64
ApportVersion: 2.17.2-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Sat Apr 25 15:28:38 2015
InstallationDate: Installed on 2013-11-24 (517 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
SourcePackage: gnome-terminal
UpgradeStatus: Upgraded to vivid on 2015-04-24 (1 days ago)

Revision history for this message
Rob Locher (rclocher3) wrote :
Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

Gnome-terminal is unfortunately known to have troubles with non-UTF-8 locales, see e.g. https://bugzilla.gnome.org/show_bug.cgi?id=732127.

In your case, however, I suspect that you're doing something wrong with your installation (because you also seem to aim for UTF-8). It's weird to me that you use nonstandard tools to install them, rather than localedef or locale-gen.

At the very least, what does "locale charmap" print with your locale? It should be "UTF-8".

Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

You could also try setting LANG=<yourlocale> and LC_CTYPE=en_US.UTF-8 simultaneously - does this work?

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-terminal (Ubuntu):
status: New → Confirmed
Changed in gnome-terminal (Ubuntu):
importance: Undecided → High
Revision history for this message
Rob Locher (rclocher3) wrote : Re: [Bug 1448563] Re: terminal won't launch with a customized locale

> Gnome-terminal is unfortunately known to have troubles with non-UTF-8
> locales, see e.g. https://bugzilla.gnome.org/show_bug.cgi?id=732127.

> In your case, however, I suspect that you're doing something wrong with
> your installation (because you also seem to aim for UTF-8). It's weird
> to me that you use nonstandard tools to install them, rather than
> localedef or locale-gen.

> At the very least, what does "locale charmap" print with your locale? It
> should be "UTF-8".

Hi Egmont, and thanks for your attention to the bug. I certainly may have done something wrong; the online documentation about setting up a custom locale that I was able to find is confusing and sparse, and there seem to be very few tools to help an ordinary user customize a locale. I'm no locale expert; my motivation was just to use 24-hour time, YYYY-MM-DD dates, and the Metric system, even though I live in the US.

I originally tried using localedef directly, but it exited with code 1, listing a slew of errors that didn't seem to have anything to do with the modest customizations that I made to the locale. Rather than spend all day at it I tried the Python script that I mentioned in the bug description, which calls localedef. The script reported success, and my simple locale-test program verified that I had installed the locale well enough to get the date and time formats I wanted. Unfortunately, once my custom locale was installed, every time I launched a GUI program from the command line I got a fontconfig() warning complaining about the locale.

So I may have done something wrong, but I did succeed at getting the date and time formats I wanted. I filed the bug because I was able to launch a terminal under Ubuntu 14.10, but once I upgraded to Ubuntu 15.04, then I couldn't.

$ LANG="rob_custom.UTF-8"
$ locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=rob_custom.UTF-8
LANGUAGE=en_US
LC_CTYPE="rob_custom.UTF-8"
LC_NUMERIC="rob_custom.UTF-8"
LC_TIME="rob_custom.UTF-8"
LC_COLLATE="rob_custom.UTF-8"
LC_MONETARY="rob_custom.UTF-8"
LC_MESSAGES="rob_custom.UTF-8"
LC_PAPER="rob_custom.UTF-8"
LC_NAME="rob_custom.UTF-8"
LC_ADDRESS="rob_custom.UTF-8"
LC_TELEPHONE="rob_custom.UTF-8"
LC_MEASUREMENT="rob_custom.UTF-8"
LC_IDENTIFICATION="rob_custom.UTF-8"
LC_ALL=
$ locale charmap
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968
$

Aha, the charmap isn't UTF-8 for some reason.

> You could also try setting LANG=<yourlocale> and LC_CTYPE=en_US.UTF-8
> simultaneously - does this work?

No, that doesn't seem to work. The "locale" command shows LC_CTYPE as "rob_custom.UTF-8" afterwards.

- Rob

Revision history for this message
Rob Locher (rclocher3) wrote :

Egmont's email gave me enough clues to figure out that I had incorrectly installed my custom locale; the charmap was ANSI_X3.4-1968 rather than UTF-8. (I'll guess that when I used the Python script to install my custom locale, the script called localedef without the "-f UTF-8" option to set the charmap to UTF-8.) I reinstalled my custom locale correctly, using the command "localedef -i rob_custom -f UTF-8 rob_custom.UTF-8", edited /etc/default/locale to set my custom locale as the system default again, and rebooted. Now my custom locale is selected, "locale charmap" says "UTF-8", and I can launch a gnome-terminal.

So I think I've confirmed that the bug is that a gnome-terminal can't be launched when a custom locale is installed that uses the default ANSI_X3.4-1968 charmap. I had been able to launch a gnome-terminal with Ubuntu 14.10, even though my locale charmap wasn't UTF-8. I think that this bug should be fixed, because gnome-terminal should handle a locale with a non-UTF-8 charmap more gracefully, even though the situation is uncommon.

So here is a simpler procedure to demonstrate the bug, which doesn't require the custom locale file that I attached to the bug.

1) Open an xterm. Use the xterm window for the following steps.

2) In the /usr/share/i18n/locales directory, make a copy of a locale file. This will be your "customized" locale.

3) Install the copied locale file using localedef without using the -f option.
4) Set the LANG environment variable to the newly installed locale.
5) Use the "locale" command and the "locale charmap" commands to verify that the locale is set to the new "customized" locale, and that the charmap isn't UTF-8.
6) If you have any gnome-terminal windows open, close them. Now try to launch a terminal by typing "gnome-terminal" in the xterm window; if no window appears, then you've demonstrated the bug.

$ sudo cp /usr/share/i18n/locales/en_US /usr/share/i18n/locales/en_US2
$ sudo localedef -i en_US2 en_US2.UTF-8
$ LANG="en_US2.UTF-8"
$ locale
LANG=en_US2.UTF-8
LANGUAGE=en
LC_CTYPE="en_US2.UTF-8"
LC_NUMERIC="en_US2.UTF-8"
LC_TIME="en_US2.UTF-8"
LC_COLLATE="en_US2.UTF-8"
LC_MONETARY="en_US2.UTF-8"
LC_MESSAGES="en_US2.UTF-8"
LC_PAPER="en_US2.UTF-8"
LC_NAME="en_US2.UTF-8"
LC_ADDRESS="en_US2.UTF-8"
LC_TELEPHONE="en_US2.UTF-8"
LC_MEASUREMENT="en_US2.UTF-8"
LC_IDENTIFICATION="en_US2.UTF-8"
LC_ALL=
$ locale charmap
ANSI_X3.4-1968

$ gnome-terminal

I hope I've been helpful.

- Rob

Revision history for this message
Simon K (simon-kitching) wrote :

I also encountered this problem (gnome-terminal not launching) and in my case the problem was an invalid $HOME/.pam_environment file from a previous OS installation. Xterm worked fine. Removing the .pam_environment file fixed the problem; putting it back triggered the problem again.

Debian 8 does not have the same problem; although the .pam_environment file is still invalid there, gnome-terminal launches fine.

$ more .pam_environment
LC_NUMERIC="en_IE.UTF-8"
LC_TIME="en_US.UTF-8"
LC_MONETARY="en_IE.UTF-8"
LC_PAPER="en_IE.UTF-8"
LC_IDENTIFICATION="en_IE.UTF-8"
LC_NAME="en_IE.UTF-8"
LC_ADDRESS="en_IE.UTF-8"
LC_TELEPHONE="en_IE.UTF-8"
LC_MEASUREMENT="en_IE.UTF-8"

Revision history for this message
lukas (lbboelen) wrote :

dont know why or how, and i dont wanna know xD cause it took me way to long to fix it but this did the trick

eval $(dbus-launch --sh-syntax)

export DBUS_SESSION_BUS_ADDRESS
export DBUS_SESSION_BUS_PID

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.