Ubuntu
postgresql-common package

fails to start after install if invalid locale is set

Bug #969462 reported by Scott Moser
34
This bug affects 6 people
Affects Status Importance Assigned to Milestone
postgresql-common (Ubuntu)
Fix Released
Low
Martin Pitt

Bug Description

For more information on locale in the cloud-images, see bug 859814.

If you install postgresql-9.1 with invalid LC_ALL, then postgres will not be running after install (which causes issues with things that depend on it).

Try:
$ LC_ALL=fr_FR.UTF-8 ssh ubuntu@$HOSTNAME
% 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=en_US.UTF-8
LANGUAGE=
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=fr_FR.UTF-8
% sudo apt-get install postgresql-9.1
...
After this operation, 11.6 MB of additional disk space will be used.
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
 LANGUAGE = (unset),
 LC_ALL = "fr_FR.UTF-8",
 LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
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
Selecting previously unselected package postgresql-9.1.
(Reading database ... 26213 files and directories currently installed.)
Unpacking postgresql-9.1 (from .../postgresql-9.1_9.1.3-2_i386.deb) ...
Setting up postgresql-9.1 (9.1.3-2) ...
Error: The locale requested by the environment is invalid.
Error: could not create default cluster. Please create it manually with

  pg_createcluster 9.1 main --start

or a similar command (see 'man pg_createcluster').
update-alternatives: using /usr/share/postgresql/9.1/man/man1/postmaster.1.gz to provide /usr/share/man/man1/postmaster.1.gz (postmaster.1.gz) in auto mode.

There is no postgres service running at this point.

Related bugs:
 * bug 859814: Locale issues with beta-1/2 cloud-images
 * bug 1134036: [maas] Failure when using ssh with a locale that is not configured on the server

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: postgresql-9.1 9.1.3-2
ProcVersionSignature: User Name 3.2.0-20.33-virtual 3.2.12
Uname: Linux 3.2.0-20-virtual i686
ApportVersion: 1.95-0ubuntu1
Architecture: i386
Date: Fri Mar 30 18:16:50 2012
Ec2AMI: ami-bdea34d4
Ec2AMIManifest: (unknown)
Ec2AvailabilityZone: us-east-1c
Ec2InstanceType: t1.micro
Ec2Kernel: aki-805ea7e9
Ec2Ramdisk: unavailable
ProcEnviron:
 TERM=xterm
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: postgresql-9.1
UpgradeStatus: No upgrade log present (probably fresh install)

See original description
Revision history for this message
Scott Moser (smoser) wrote :
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in postgresql-9.1 (Ubuntu):
status: New → Confirmed
Revision history for this message
Robinpeder (robinpeder) wrote :

This also affects the result of the installation, even when using a valid locale.

If postgresql is installed in a terminal with LC_ALL="C", it is not possible to create unicode databases:

$ createdb -E UNICODE test
createdb: database creation failed: ERROR: new encoding (UTF8) is incompatible with the encoding of the template database (SQL_ASCII)

Specifying --locale when running pg_createcluster in the postinstall script will make the installation independent of the terminal.

Revision history for this message
Martin Pitt (pitti) wrote :

$ LC_ALL=fr_FR.UTF-8 ssh ubuntu@$HOSTNAME
% locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory

That means that fr_FR.UTF-8 doesn't actually exist on the target host.

Changed in postgresql-9.1 (Ubuntu):
status: Confirmed → Invalid
Scott Moser (smoser)
description: updated
Revision history for this message
Julian Edwards (julian-edwards) wrote :

I don't understand why this was marked invalid Martin. You're just confirming why the bug exists.

Revision history for this message
Martin Pitt (pitti) wrote :

If anything, this is a bug in ssh for insisting to apply your host's locale to the remote shell. I have always considered that EBW, but I don't want to work around this in PostgreSQL by picking some random locale if the one that's actually set is invalid.

Revision history for this message
Robie Basak (racb) wrote :

> picking some random locale

How about C or C.UTF-8? These should be suitable non-random fallbacks, right?

Revision history for this message
Martin Pitt (pitti) wrote : Re: [Bug 969462] Re: fails to start after install if invalid locale is set

Robie Basak [2013-06-04 8:37 -0000]:
> > picking some random locale
>
> How about C or C.UTF-8? These should be suitable non-random fallbacks,
> right?

That's still not what you would expect on the server, which is usually
to use the server's configured system locale. C or C.UTF-8 basically
means "broken for everybody", as that will have the wrong
collation/sorting for all actual languages.

I think it is better to fail with an obvious error than to silently
create a cluster with an unwanted locale.

Revision history for this message
Robie Basak (racb) wrote :

I've started a discussion thread at: https://lists.ubuntu.com/archives/ubuntu-devel/2013-June/037195.html

Scott Moser (smoser)
description: updated
Revision history for this message
Martin Pitt (pitti) wrote :

In the discussion we found the following compromise: The postinst should ignore the locale from the environment (as sudo and ssh make that unreliable), and instead do the following fallback:

 * if /etc/default/locale defines a locale, use that
 * otherwise, if /etc/environment defines a locale, use that (that's a pam_env file, so source that in a subprocess and handle errors!)
 * otherwise, use C

That will break cases where the system locale is defined someplace else, but then people can still either drop and re-create the default cluster, or specify the locale on creating new DBs.

affects: postgresql-9.1 (Ubuntu) → postgresql-common (Ubuntu)
Changed in postgresql-common (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
importance: Undecided → Low
status: Invalid → In Progress
Revision history for this message
Martin Pitt (pitti) wrote :

Fixed in p-common packaging branch r1355.

Changed in postgresql-common (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package postgresql-common - 145

---------------
postgresql-common (145) unstable; urgency=low

  [ Christoph Berg ]
  * pg_ctlcluster: Use "install" instead of File::Path to create
    unix_socket_directory. (Introduced in 141, Closes: #710093)

  [ Martin Pitt ]
  * debian/maintscripts-functions, configure_cluster(): Do not trust the
    locale from the environment, as programs like ssh and sudo propagate
    remote and user locale by default. Instead, only use the locale settings
    from /etc/environment and /etc/default/locale, to prevent trying to
    configure the default cluster with a nonexisting or hard to predict
    locale. (LP: #969462, also see Debian #700271)

 -- Christoph Berg <email address hidden> Mon, 10 Jun 2013 17:01:01 +0200

Changed in postgresql-common (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

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