Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

I am getting this message every time I do something like starting or stopping a service.

perl: warning: Setting locale failed.   
perl: warning: Please check that your locale settings:   
        LANGUAGE = "en_US:en",   
        LC_ALL = (unset),   
        LC_MESSAGES = "en_US.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   
(Reading database ... 21173 files and directories currently installed.)  
Removing bind9 ...  
 * Stopping domain name service... bind9                                        [ OK ]
Processing triggers for man-db ...   
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   

How do I fix this error ?

share|improve this question
Related: How to set locale? –  Lucio Nov 6 '14 at 18:10

14 Answers 14

up vote 159 down vote accepted

First run locale to list what locales currently defined for the current user account:

$ locale

Then generate the missing locale and reconfigure locales to take notice:

$ sudo locale-gen fi_FI.UTF-8
Generating locales...
  fi_FI.UTF-8... done
Generation complete.

$ sudo dpkg-reconfigure locales
Generating locales...
  en_US.UTF-8... done
  fi_FI.UTF-8... up-to-date
Generation complete.

Now you will not see any errors anymore!

share|improve this answer
did not work for me –  Umair Ayub Apr 24 '14 at 7:43
Did not work for me. –  Joe Murray Nov 10 '14 at 3:34
This has worked for me on a number of systems. Is there a way to avoid this issue on newly installed systems? –  Brylie Oxley Jan 12 at 17:34

Nothing suggested above worked in my case (Ubuntu Server 12.04LTS). What finally helped was putting to the file /etc/environment:


For some reason it was missing. The outputs for locale and other commands appeared like the variables were properly defined. In other words don't take for granted all the basic stuff is declared where it should be declared.

share|improve this answer
Yes, none other worked except this one, perhaps due to updated version. But I rather prefer to put this in /etc/default/locale. –  cmnajs Feb 22 '13 at 20:18
Updated /etc/default/locale and no more warnings. Thanks –  ohho Feb 26 '13 at 7:00
Yep, the others didn't work for me. This one did. Here is the one-liner I used for unattended updating of this. sudo sh -c "echo 'LC_ALL=en_US.UTF-8\nLANG=en_US.UTF-8' >> /etc/environment" –  dman Mar 22 '14 at 6:01
@user163207 your solution is incorrect because it appends (instead of overwriting), it's not the recommended file, and echo needs to be run with the interpretation of backslash escapes enabled. This is the same as yours but with the aforementioned fixed: sh -c "echo -e 'LANG=en_US.UTF-8\nLC_ALL=en_US.UTF-8' > /etc/default/locale" –  glarrain Apr 9 '14 at 21:22
I am facing the same issue in my Ubuntu Cloud Image –  Umair Ayub Apr 24 '14 at 16:03

They should disappear after issuing:

sudo locale-gen en_US en_US.UTF-8
dpkg-reconfigure locales 

dpkg-reconfigure reconfigures packages after they have already been installed. Pass it the names of a package or packages to reconfigure. It will ask configuration questions, much like when the package was first installed.

share|improve this answer
Thanks it works :) –  HackToHell Jul 11 '12 at 14:21
I am glad my troubles a year ago helped you get this fixed ;) –  Rinzwind Jul 11 '12 at 14:34
Shouldn't this locale be generated by default? I mean en, en_AU, en_CA, en_GB are present by default but not en_US? –  Daniel Serodio Aug 15 '12 at 16:05
Ping! Your troubles are still useful. :-D –  Brian Visel Sep 27 '12 at 21:35
What does the dpkg-reconfigure locales command do in more detail? –  Victor Nov 17 '12 at 3:38

Just add the following to your .bashrc file (assuming you're using bash)

export LC_ALL="en_US.UTF-8"
share|improve this answer
This sweet fix worked for me on my Amazon-EC2 image (Was running their default RHEL AMI) Thanks so much! :) –  gideon Dec 1 '12 at 15:07
This one worked for me with my digitalocean's Ubuntu 12.04 image. –  Inan Berbatov Sep 25 '13 at 11:49

What worked for me on 12.10 was this:

apt-get install language-pack-en-base  

This was after dpkg-reconfigure locales produced no results.

share|improve this answer
This is the best answer. It's not that my locales were setup incorrectly, but they didn't actually exist. I think this is similar to the OP's problem as well ("No such file or directory" is pretty clear if your locale is set right!). –  Breakthrough Oct 27 '13 at 21:49
I was getting the OPs issue ever time i was using apt-get on Ubuntu 12.04 This solved it perfectly without having to edit any files. –  Deepend Jun 10 '14 at 10:13

There is a command for that:

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

It updates /etc/default/locale with provided values.

share|improve this answer

For Ubuntu 12.10 none of the above worked except for ratzs' solution. I recommend adding this to your /etc/bash.bashrc file:

export LC_ALL="en_ZA.UTF-8"
export LC_CTYPE="en_ZA.UTF-8"
share|improve this answer

You can try:

export LANGUAGE=ru_RU.UTF-8
export LC_CTYPE=ru_RU.UTF-8
export LC_NUMERIC=ru_RU.UTF-8
export LC_TIME=ru_RU.UTF-8
export LC_COLLATE=ru_RU.UTF-8
export LC_MONETARY=ru_RU.UTF-8
export LC_MESSAGES=ru_RU.UTF-8
export LC_PAPER=ru_RU.UTF-8
export LC_NAME=ru_RU.UTF-8
export LC_ADDRESS=ru_RU.UTF-8
export LC_ALL=ru_RU.UTF-8

where ru_RU is your country code.

share|improve this answer

This is a common problem if you are connecting remotely, so the solution is to not forward your locale. Edit /etc/ssh/ssh_config and comment out SendEnv LANG LC_* line.

share|improve this answer
I was trying other answers, but forgot I was connecting remotely until I saw your answer. Different locales on the ssh server and client was causing the problem. –  Hieu Feb 27 at 6:32

Don't forget exit your SSH session (or your X11) by exiting and logging back in again. All of these suggestions didn't work for me unless I logged back in....

share|improve this answer
$ cat ~/.kde/env/setlocale.sh 
export LANG=en_US.UTF-8
export LANGUAGE=en_US:ru:en

if you run KDE check file setlocale.sh

share|improve this answer

As said here in the Debian Wiki, you can edit /etc/locales.gen and add all locales (or uncomment them, I had a list of all locales but all except the one I used as comments) you wish to have support for on your system. Then, execute

sudo dpkg-reconfigure locales

to update the locales on your system. Now, all of the locales you added/uncommented in /etc/locales.gen are available on your system without any warnings.

share|improve this answer
  1. You may need to run sudo dpkg-reconfigure also for the application you have installed while "locale" settings have been invalid / not matching.

    While system locale was incorrectly setup I installed vim. Later when system locale was fixed I saw a situation that vim was showing utf-8 characters incorrectly as strange symbols while nano and less were showing them correctly. Running

    sudo dpkg-reconfigure vim

    appeared to fix the issue after the system settings were fixed.

  2. I also noticed the same thing as already mentioned: You may need to disconnect/reconnect SSH to make changes visible.

share|improve this answer

This worked for me when I had the same problem (solution provided by dman):

sudo sh -c "echo 'LC_ALL=en_US.UTF-8\nLANG=en_US.UTF-8' >> /etc/environment"
share|improve this answer
I wasn't quite sure how to add the url to the comment. @EliahKagan –  pythonhunter Aug 27 '14 at 6:28
No problem--the date/timestamp next to a comment is what links to it directly. ...So, I've noticed glarrain's comment (calling for > instead of >>) seems like a reply to dman's. I don't actually know which way is right or best, but if you have any insight into this you could expand this answer with more information. (You don't have to though.) –  Eliah Kagan Aug 27 '14 at 6:32

protected by Community Jan 1 at 19:12

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.