Locale variables have no effect in remote shell (perl: warning: Setting locale failed.)

Question

I have a fresh ubuntu 12.04 installation. When i connect to my remote server i got errors like this:

~$ ssh example.com sudo aptitude upgrade
...
Traceback (most recent call last):
  File "/usr/bin/apt-listchanges", line 33, in <module>
    from ALChacks import *
  File "/usr/share/apt-listchanges/ALChacks.py", line 32, in <module>
    sys.stderr.write(_("Can't set locale; make sure $LC_* and $LANG are correct!\n"))
NameError: name '_' is not defined
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
    LANGUAGE = (unset),
    LC_ALL = (unset),
    LC_TIME = "de_DE.UTF-8",
    LC_MONETARY = "de_DE.UTF-8",
    LC_ADDRESS = "de_DE.UTF-8",
    LC_TELEPHONE = "de_DE.UTF-8",
    LC_NAME = "de_DE.UTF-8",
    LC_MEASUREMENT = "de_DE.UTF-8",
    LC_IDENTIFICATION = "de_DE.UTF-8",
    LC_NUMERIC = "de_DE.UTF-8",
    LC_PAPER = "de_DE.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_ALL to default locale: No such file or directory
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
...

I don't have this problem when i connect from an older ubuntu installation. This is output from my ubuntu 12.04 installation, LANG and LANGUAGE are set

$ locale
LANG=de_DE.UTF-8
LANGUAGE=de_DE:en_GB:en
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC=de_DE.UTF-8
LC_TIME=de_DE.UTF-8
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY=de_DE.UTF-8
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION=de_DE.UTF-8
LC_ALL=

Does anybody know what has changed in ubuntu to get this error message on remote servers?

possible duplicate of How do I fix my locale issue? – Fabby Feb 23 '15 at 12:03 — Fabby, Feb 23 '15 at 12:03

David Planella · Accepted Answer · 2012-05-31T05:47:38.707

185

That's because your locale in your local machine is set to German, which SSH forwards to and tries to use on the server, but your server does not have it installed.

You've got several options:

Generate the locale. Generate the German locale on the server with sudo locale-gen de.
Stop forwarding locale from the client. Do not forward the locale environment variable from your local machine to the server. You can comment out the SendEnv LANG LC_* line in the local /etc/ssh/ssh_config file.
Stop accepting locale on the server. Do not accept the locale environment variable from your local machine to the server. You can comment out the AcceptEnv LANG LC_* line in the remote /etc/ssh/sshd_config file.
Set the server locale to English. Explicitly set the locale to English on the server. As an example, you can add the following lines to your remote ~/.bashrc or ~/.profile files:
```
export LANGUAGE="en"
export LANG="C"
export LC_MESSAGES="C"
```

If you don't have root access to the server, the Stop forwarding locale from the client option might be the best (and only) way to go.

edited May 31 '12 at 05:47

answered May 31 '12 at 05:16

David Planella

15,520

3

Hah! I totally missed the fact that he listed the client's locale settings! Great job... – ish May 31 '12 at 07:29
13

I decided to "Stop forwarding locale from the client". Works fine. For future reference: you can't override SendEnv settings from /etc/ssh/ssh_config in your local ~/.ssh/config. See https://bugzilla.mindrot.org/show_bug.cgi?id=1285 – Janning Jun 03 '12 at 23:50
4

Combined with https://bugs.php.net/bug.php?id=18556, SSH's sending of locales can cause real problems (and caused for me actually), see https://bugzilla.mindrot.org/show_bug.cgi?id=1285#c9 ... – Halil Özgür Nov 14 '13 at 17:00
1

In my case, setting locale in ~/.profile solved my issue. Thanks. – Francisco Apr 06 '17 at 18:27
If the server does not have German locale, why is it acceptable for it to overwrite the user-requested value of LANG with something else?.. – Mikhail T. Jul 11 '17 at 20:38
You cannot generate the locale if it's not available in the system. To make it available you first have to run sudo dpkg-reconfigure locales. See also the Debian wiki page on locales. – Paul Rougieux Dec 13 '17 at 21:21
Stop forwarding locale from the client saved me from getting crasy, thanks – Setop Dec 14 '21 at 20:56

score 30 · Answer 2 · answered May 30 '12 at 19:19

This can happen sometimes on fresh minimal/alternate installs or in other situations. The fix is pretty simple. Try these, in the following order, testing after each to see if the situation is fixed:

1. Reconfigure locales

sudo dpkg-reconfigure locales
- if that doesn't work,

2. Reinstall locale language-pack

sudo apt-get --reinstall install language-pack-de
- if that doesn't work,

3. Manually force locale settings (persistent)

sudo update-locale LC_ALL=de_DE.UTF-8 LANG=de_DE.UTF-8

I have a JVM problem and I'm trying to set the system locale in 12.04 also. Only problem is I can't seem to set the LC_ALL no matter what I try, locales still shows it as empty. — Dark Star1, Dec 11 '12 at 01:09

score 19 · Answer 3 · edited Jun 01 '14 at 21:25

19

Comment the line SendEnv LANG LC_* in /etc/ssh/ssh_config, so it should looks like:

#SendEnv LANG LC_*

edited Jun 01 '14 at 21:25

gertvdijk

67,947

answered Dec 21 '13 at 14:12

Zhengpeng Hou

354
2
2

score 15 · Answer 4 · edited Jan 23 '17 at 17:30

The Problem

By default, the ssh client command forwards locale-related environment variables to the SSH server. That's specified in /etc/ssh/ssh_config on the client side:

Host *
    SendEnv LANG LC_*

And by default, the SSH server happens to accept them (in /etc/ssh/sshd_config on the server):

AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE

So, if there are locale-related environment variables in your shell, they will be populated to the SSH session on the server side.

Unfortunately, the SendEnv option is cumulative. According to man 5 ssh_config:

 SendEnv
         ... Multiple environment variables may be separated
         by whitespace or spread across multiple SendEnv directives.  The
         default is not to send any environment variables.

which means it can't be overridden.

The Solution

Sometimes it's impossible or unwise to change a system-wide configuration, especially on the server side. However, you may bypass it. And that's the side effect of the -F option in ssh command. According to man ssh:

 -F configfile
         Specifies an alternative per-user configuration file.  If a con-
         figuration file is given on the command line, the system-wide
         configuration file (/etc/ssh/ssh_config) will be ignored.  The
         default for the per-user configuration file is ~/.ssh/config.

By default the per-user configuration file ~/.ssh/config is used if it presents. But you can explicitly specify it on the command line to bypass /etc/ssh/ssh_config:

$ touch ~/.ssh/config
$ ssh -F ~/.ssh/config your_user@your_host

It would be more convenient if you make an alias in ~/.bashrc:

alias ssh="ssh -F ~/.ssh/config"

This way, the default SendEnv directives in system-wide configuration are not effective, making no environment variables be sent to the SSH server by default.

Bear in mind that the system configuration file in /etc/ssh/config may contain additional lines that you wish to retain in your user configuration. You'll have to copy them over to your user config file in ~/.ssh/config to keep those settings. — Steven Maude, Jan 23 '17 at 16:35

score 6 · Answer 5 · answered Feb 29 '16 at 10:30

I had a similar issue. My solution was to comment the SendEnv lines in /etc/ssh/ssh_config (since these cannot be overriden), and to add the following entry in ~/.ssh/config:

Host *,!<somehost>
    SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
    SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
    SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
    SendEnv XMODIFIERS

with <somehost> being the hostname to which I didn't want to send any environment variable.

score 1 · Answer 6 · edited Jan 09 '23 at 01:50

1

I was facing the issue that I attributed to ssh passing the locale settings, so I tried with disabling it on client site, then on server site as well and still the locale was complaining after logging in.

Turned out to be a messy locale on the destination server itself, where the setting was taken from /etc/default/locale

I had to clean it completely, and run sudo dpkg-reconfigure locales which fixed the issue.

edited Jan 09 '23 at 01:50

karel

114,770

answered May 21 '20 at 19:46

remigiusz boguszewicz

111
1

thanks it solve my issue. I had to add sudo to let it work under su https://serverfault.com/a/992110/962047 – AKMalkadi Jan 09 '23 at 00:34

score 0 · Answer 7 · answered Nov 08 '19 at 14:12

This is fixed in OpenSSH 7.8, i.e. older than the current version in Debian stable. The documentation now includes:

It is possible to clear previously set SendEnv variable names by prefixing patterns with -. The default is not to send any environment variables.

See #573316

Locale variables have no effect in remote shell (perl: warning: Setting locale failed.)

7 Answers7

1. Reconfigure locales

2. Reinstall locale language-pack

3. Manually force locale settings (persistent)

The Problem

The Solution

Linked

Related