Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm using Arch Linux, and I've followed the directions on the wiki about setting my locale.

Nearly every program that runs complains about the locale - even locale. It looks like this:

% locale
locale: Cannot set LC_ALL to default locale: No such file or directory


% perl
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
    LANGUAGE = (unset),
    LC_ALL = (unset),
    LC_TIME = "en-US",
    LC_NUMERIC = "en-US",
    LC_MONETARY = "en-US",
    LC_CTYPE = "en_US.UTF-8",
    LANG = (unset)
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C")

Something slightly confusing is that the /etc/locale.gen has several examples; all the UTF-8 lines have "something.UTF-8", and running locale-gen shows en_US.UTF-8... done while it's running, but locale -a, which is supposed to show you the available locales shows en_US.utf8. I've tried various combinations of both formats in /etc/locale-gen and LOCALE= in /etc/rc.conf, but nothing has fixed the problem.

Additional information:

% locale -a

Bruce Ediger's suggestion of setting LANG=C and LC_ALL=en_US.UTF-8 worked (in fact, setting LC_ALL fixed it, setting LANG didn't matter), but I'd like to know what's happening. According to SUS, LC_ALL will override all the other LC_* variables if it is set and not null. In my system, it is set, but it is null, so it should be ignored, and other values should be used instead. That's not what's happening, it seems that applications are calling setlocale with LC_ALL, getting a NULL back, and generating an error, even when other calls to setlocale return a good string.

Here is the top of an ltrace of locale (scroll right to see function return values)

% ltrace locale
(0, 0, 0, -1, 0x7f5c1ae44510)                                                                      = 0x7f5c1ae47140
__libc_start_main(0x401d70, 1, 0x7fff7c8cfbf8, 0x404610, 0x4046a0 <unfinished ...>
setlocale(0, "")                                                                                   = "en_US.UTF-8"
setlocale(5, "")                                                                                   = "en_US.UTF-8"
textdomain("libc")                                                                                 = "libc"
argp_parse(0x607280, 1, 0x7fff7c8cfbf8, 0, 0x7fff7c8cfad4)                                         = 0
setlocale(6, "")                                                                                   = NULL
dcgettext(0, 0x405aa8, 5, 0, 0)                                                                    = 0x405aa8
error(0, 2, 0x405aa8, 1, 0locale: Cannot set LC_ALL to default locale: No such file or directory)  
share|improve this question
can you share the output of locale -a? – njsg Jul 14 '12 at 16:02
I was going to point that you should use .utf8 in LOCALE and LC_*, but apparently .UTF-8 works here too... As for en-US: does it appear (without .utf8) in locale -a? – njsg Jul 14 '12 at 16:09
Do export LANG=C and export LC_ALL=en_US.UTF-8 and see what happens. My Arch linux laptop has LOCALE="en_US.UTF-8" in /etc/rc.conf, and I can't figure out where my laptop sets LANG=C . – Bruce Ediger Jul 14 '12 at 16:31
Can you post the contents of your /etc/locale.conf? It looks like you accidentally wrote LANG=en-US (with hyphen) instead of LANG=en_US (with underscore). – Mikel Aug 3 '12 at 20:18
And the contents of /etc/locale.gen would be useful too. – Mikel Aug 3 '12 at 20:33
up vote 6 down vote accepted

You're missing a file which would be used to default the locale in the absence of $LANG or $LC_ALL (or all of the more specific $LC_whatever) being set.

On older glibc, it's /usr/lib/locale/locale-archive. Because GNU/Linux is chaotic, you should use strace to determine which files are expected in the particular versions in use on your machine:

strace -e file locale
execve("/usr/bin/locale", ["locale"], [/* 36 vars */]) = 0
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib/libc.so.6", O_RDONLY)        = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3

----------------------Comments added 1 day later:

"ltrace -S" should be okay, since it shows syscalls.

Otherwise, "ltrace" is not very helpful (i.e. it's counterproductive versus strace), because it only shows the uppermost calls. Those are obvious (setlocale(3)), whereas the real problem happens within libc.

It sounds like you have the raw locale data installed, since en_US.UTF-8 works.

If so, then something like this should fix your problem, setting a system-wide default:

localedef -f UTF-8 -i en_US en_US.UTF-8
share|improve this answer

I had the same issue after setting up /etc/locale.conf just today (relating to the recent changes to /etc/rc.conf. In my case, it turned out that the locales were not installed.

Check /etc/locale.gen. All the locales which your environment variables reference must be activated (i.e. not commented out) in there. After having made your changes, run sudo locale-gen to install the selected locales.

share|improve this answer

I had similar problems recently, all unicode file names were incorrectly displayed, when I accidentally removed the 'LOCALE=en_US.utf8' in /etc/rc.conf. So I checked the boot script:

if [[ $DAEMON_LOCALE != [nN][oO] ]]; then
    export LANG=${LOCALE:-C}
    if [[ -r /etc/locale.conf ]]; then
        parse_envfile /etc/locale.conf "${localevars[@]}"
    export LANG=C

Simple solution is check both DAEMON_LOCALE and LOCALE in /etc/rc.conf, make sure the first one wasn't no and the second one wasn't empty.

share|improve this answer

Following this link solves my problem :

sudo localectl set-locale LANG=en_CA.UTF-8
# or change to en_US.UTF-8 depends on your locale-gen

it generates a file /etc/locale.conf that fixes this issue

share|improve this answer

Maybe one of your settings is invalid? These are my locale settings for reference; they don't cause any errors (KUbuntu 12.04):

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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