Thread: Installation problem: failed to initialize lc_messages to ""
Hi there, I am trying to install Postgres 8.1.11 on Mac Leopard. Compilation was ok. Now, the initdb has some problems: $ /usr/local/pgsql/bin/initdb -D --locale=C /Users/schwarzer/Documents/ data_postgres ... selecting default max_connections ... 10 selecting default shared_buffers ... 50 creating configuration files ... ok creating template1 database in /Users/schwarzer/Documents/ data_postgres/base/1 ... FATAL: XX000: failed to initialize lc_messages to "" LOCATION: InitializeGUCOptions, guc.c:2666 child process exited with exit code 1 initdb: removing contents of data directory "/Users/schwarzer/ Documents/data_postgres" What is it? What do I have to do? Can anyone give me a hint please?! Thanks a lot, Stef
Stefan Schwarzer <stefan.schwarzer@grid.unep.ch> writes:
> FATAL: XX000: failed to initialize lc_messages to ""
> LOCATION: InitializeGUCOptions, guc.c:2666
Typically what this means is that you have an improper setting of LANG
or LC_ALL in your environment ("improper" meaning that it doesn't match
any of the locales that are actually installed on your system). You
can use "locale -a" to find out what's installed.
regards, tom lane
>> FATAL: XX000: failed to initialize lc_messages to ""
>> LOCATION: InitializeGUCOptions, guc.c:2666
>
> Typically what this means is that you have an improper setting of LANG
> or LC_ALL in your environment ("improper" meaning that it doesn't
> match
> any of the locales that are actually installed on your system). You
> can use "locale -a" to find out what's installed.
Hmm... Did the "locale -a"... and lot's of things appeared. Beneath
them this one:
en_US
en_US.ISO8859-1
en_US.ISO8859-15
en_US.US-ASCII
en_US.UTF-8
I guess it's the most widely used. What am I supposed to do now? I
tried to specify a --locale=C, which I read somewhere.... no idea.
Please, give me a hint what I should do to proper set postgres up.
Thanks a lot,
Stef
>> FATAL: XX000: failed to initialize lc_messages to ""
>> LOCATION: InitializeGUCOptions, guc.c:2666
>
> Typically what this means is that you have an improper setting of LANG
> or LC_ALL in your environment ("improper" meaning that it doesn't
> match
> any of the locales that are actually installed on your system). You
> can use "locale -a" to find out what's installed.
I tried this:
/usr/local/pgsql/bin/initdb -D --locale=en_US.UTF-8 /Users/schwarzer/
Documents/data_postgres
but still the same message.
On 10/01/2008 12:30, Stefan Schwarzer wrote: > /usr/local/pgsql/bin/initdb -D --locale=en_US.UTF-8 > /Users/schwarzer/Documents/data_postgres Dunno if it'll make a difference, but I'd put the "-D" immediately before the path to the data directory. Ray. --------------------------------------------------------------- Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland rod@iol.ie ---------------------------------------------------------------
>> /usr/local/pgsql/bin/initdb -D --locale=en_US.UTF-8 /Users/ >> schwarzer/Documents/data_postgres > > Dunno if it'll make a difference, but I'd put the "-D" immediately > before the path to the data directory. Thanks for the hint. But unfortunately same error message....
"Raymond O'Donnell" <rod@iol.ie> writes:
> On 10/01/2008 12:30, Stefan Schwarzer wrote:
>> /usr/local/pgsql/bin/initdb -D --locale=en_US.UTF-8
>> /Users/schwarzer/Documents/data_postgres
> Dunno if it'll make a difference, but I'd put the "-D" immediately
> before the path to the data directory.
Also, pay attention to the first few lines of initdb output ---
it will tell you what it thinks it's supposed to use for locale.
regards, tom lane
>>> /usr/local/pgsql/bin/initdb -D --locale=en_US.UTF-8 >>> /Users/schwarzer/Documents/data_postgres > >> Dunno if it'll make a difference, but I'd put the "-D" immediately >> before the path to the data directory. > > Also, pay attention to the first few lines of initdb output --- > it will tell you what it thinks it's supposed to use for locale. It tells me the following: The files belonging to this database system will be owned by user "schwarzer". This user must also own the server process. The database cluster will be initialized with locale en_US.UTF-8. The default database encoding has accordingly been set to UTF8. fixing permissions on existing directory /Users/schwarzer/Documents/ data_postgres ... ok creating directory /Users/schwarzer/Documents/data_postgres/global ... ok creating directory /Users/schwarzer/Documents/data_postgres/ pg_xlog ... ok creating directory /Users/schwarzer/Documents/data_postgres/pg_xlog/ archive_status ... ok creating directory /Users/schwarzer/Documents/data_postgres/ pg_clog ... ok creating directory /Users/schwarzer/Documents/data_postgres/ pg_subtrans ... ok creating directory /Users/schwarzer/Documents/data_postgres/ pg_twophase ... ok creating directory /Users/schwarzer/Documents/data_postgres/ pg_multixact/members ... ok creating directory /Users/schwarzer/Documents/data_postgres/ pg_multixact/offsets ... ok creating directory /Users/schwarzer/Documents/data_postgres/base ... ok creating directory /Users/schwarzer/Documents/data_postgres/base/1 ... ok creating directory /Users/schwarzer/Documents/data_postgres/ pg_tblspc ... ok selecting default max_connections ... 10 selecting default shared_buffers ... 50 creating configuration files ... ok creating template1 database in /Users/schwarzer/Documents/ data_postgres/base/1 ... FATAL: XX000: failed to initialize lc_messages to "" LOCATION: InitializeGUCOptions, guc.c:2666 child process exited with exit code 1 initdb: removing contents of data directory "/Users/schwarzer/ Documents/data_postgres" How can I control/verify the "server process"? To see if it's running correctly and that "schwarzer" is as well its owner? Perhaps it's related with this?
Stefan Schwarzer <stefan.schwarzer@grid.unep.ch> writes:
>> Also, pay attention to the first few lines of initdb output ---
>> it will tell you what it thinks it's supposed to use for locale.
> It tells me the following:
> The files belonging to this database system will be owned by user
> "schwarzer".
> This user must also own the server process.
> The database cluster will be initialized with locale en_US.UTF-8.
> The default database encoding has accordingly been set to UTF8.
> ...
> creating template1 database in /Users/schwarzer/Documents/
> data_postgres/base/1 ... FATAL: XX000: failed to initialize
> lc_messages to ""
> LOCATION: InitializeGUCOptions, guc.c:2666
Hmph. That seems to eliminate the bad-locale-setting theory.
In the past, when we've seen instances of this, it's been either
an improper setting or something missing/broken in the platform's
locale support. I'd have thought OS X was relatively impervious
to this type of problem because it's a monolithic install instead
of package-based, but maybe not. What have you got under
/usr/share/locale? On my OS X 10.4 laptop, I see
g42:~ tgl$ ls -lR /usr/share/locale/en_US.UTF-8
total 40
lrwxr-xr-x 1 root wheel 28 Apr 26 2006 LC_COLLATE -> ../la_LN.US-ASCII/LC_COLLATE
lrwxr-xr-x 1 root wheel 17 Apr 26 2006 LC_CTYPE -> ../UTF-8/LC_CTYPE
drwxr-xr-x 3 root wheel 102 Mar 20 2005 LC_MESSAGES
lrwxr-xr-x 1 root wheel 30 Apr 26 2006 LC_MONETARY -> ../en_US.ISO8859-1/LC_MONETARY
lrwxr-xr-x 1 root wheel 29 Apr 26 2006 LC_NUMERIC -> ../en_US.ISO8859-1/LC_NUMERIC
lrwxr-xr-x 1 root wheel 26 Apr 26 2006 LC_TIME -> ../en_US.ISO8859-1/LC_TIME
/usr/share/locale/en_US.UTF-8/LC_MESSAGES:
total 8
lrwxr-xr-x 1 root wheel 45 Apr 26 2006 LC_MESSAGES -> ../../en_US.ISO8859-1/LC_MESSAGES/LC_MESSAGES
g42:~ tgl$ ls -lLR /usr/share/locale/en_US.UTF-8
total 200
-r--r--r-- 1 root wheel 4642 Mar 20 2005 LC_COLLATE
-r--r--r-- 1 root wheel 80744 Mar 20 2005 LC_CTYPE
drwxr-xr-x 3 root wheel 102 Mar 20 2005 LC_MESSAGES
-r--r--r-- 1 root wheel 34 Mar 20 2005 LC_MONETARY
-r--r--r-- 1 root wheel 8 Mar 20 2005 LC_NUMERIC
-r--r--r-- 1 root wheel 377 Mar 20 2005 LC_TIME
/usr/share/locale/en_US.UTF-8/LC_MESSAGES:
total 8
-rw-r--r-- 1 root wheel 18 Mar 20 2005 LC_MESSAGES
I'm wondering if some of those files are missing, or the symlinks are
dangling, on yours.
regards, tom lane
> > g42:~ tgl$ ls -lR /usr/share/locale/en_US.UTF-8 > total 40 > lrwxr-xr-x 1 root wheel 28 Apr 26 2006 LC_COLLATE -> ../ > la_LN.US-ASCII/LC_COLLATE > lrwxr-xr-x 1 root wheel 17 Apr 26 2006 LC_CTYPE -> ../UTF-8/ > LC_CTYPE > drwxr-xr-x 3 root wheel 102 Mar 20 2005 LC_MESSAGES > lrwxr-xr-x 1 root wheel 30 Apr 26 2006 LC_MONETARY -> ../ > en_US.ISO8859-1/LC_MONETARY > lrwxr-xr-x 1 root wheel 29 Apr 26 2006 LC_NUMERIC -> ../ > en_US.ISO8859-1/LC_NUMERIC > lrwxr-xr-x 1 root wheel 26 Apr 26 2006 LC_TIME -> ../ > en_US.ISO8859-1/LC_TIME > > /usr/share/locale/en_US.UTF-8/LC_MESSAGES: > total 8 > lrwxr-xr-x 1 root wheel 45 Apr 26 2006 LC_MESSAGES -> ../../ > en_US.ISO8859-1/LC_MESSAGES/LC_MESSAGES > > g42:~ tgl$ ls -lLR /usr/share/locale/en_US.UTF-8 > total 200 > -r--r--r-- 1 root wheel 4642 Mar 20 2005 LC_COLLATE > -r--r--r-- 1 root wheel 80744 Mar 20 2005 LC_CTYPE > drwxr-xr-x 3 root wheel 102 Mar 20 2005 LC_MESSAGES > -r--r--r-- 1 root wheel 34 Mar 20 2005 LC_MONETARY > -r--r--r-- 1 root wheel 8 Mar 20 2005 LC_NUMERIC > -r--r--r-- 1 root wheel 377 Mar 20 2005 LC_TIME > > /usr/share/locale/en_US.UTF-8/LC_MESSAGES: > total 8 > -rw-r--r-- 1 root wheel 18 Mar 20 2005 LC_MESSAGES > > I'm wondering if some of those files are missing, or the symlinks are > dangling, on yours. > Hmmm..... here is what I have. Looks pretty similar.... gridmac7:~ schwarzer$ ls -lR /usr/share/locale/en_US.UTF-8 total 40 lrwxr-xr-x 1 root wheel 28 Dec 19 15:24 LC_COLLATE -> ../la_LN.US- ASCII/LC_COLLATE lrwxr-xr-x 1 root wheel 17 Dec 19 15:24 LC_CTYPE -> ../UTF-8/ LC_CTYPE drwxr-xr-x 3 root wheel 102 Dec 19 15:24 LC_MESSAGES lrwxr-xr-x 1 root wheel 30 Dec 19 15:24 LC_MONETARY -> ../ en_US.ISO8859-1/LC_MONETARY lrwxr-xr-x 1 root wheel 29 Dec 19 15:24 LC_NUMERIC -> ../ en_US.ISO8859-1/LC_NUMERIC lrwxr-xr-x 1 root wheel 26 Dec 19 15:24 LC_TIME -> ../ en_US.ISO8859-1/LC_TIME /usr/share/locale/en_US.UTF-8/LC_MESSAGES: total 8 lrwxr-xr-x 1 root wheel 45 Dec 19 15:24 LC_MESSAGES -> ../../ en_US.ISO8859-1/LC_MESSAGES/LC_MESSAGES gridmac7:~ schwarzer$ ls -lLR /usr/share/locale/en_US.UTF-8 total 192 -r--r--r-- 1 root wheel 2086 Sep 24 03:38 LC_COLLATE -r--r--r-- 1 root wheel 80752 Sep 24 03:38 LC_CTYPE drwxr-xr-x 3 root wheel 102 Dec 19 15:24 LC_MESSAGES -r--r--r-- 1 root wheel 34 Sep 24 03:38 LC_MONETARY -r--r--r-- 1 root wheel 8 Sep 24 03:38 LC_NUMERIC -r--r--r-- 1 root wheel 377 Sep 24 03:39 LC_TIME /usr/share/locale/en_US.UTF-8/LC_MESSAGES: total 8 -rw-r--r-- 1 root wheel 18 Sep 24 03:38 LC_MESSAGES
Stefan Schwarzer <stefan.schwarzer@grid.unep.ch> writes:
>> I'm wondering if some of those files are missing, or the symlinks are
>> dangling, on yours.
> Hmmm..... here is what I have. Looks pretty similar....
Running out of easy answers, aren't we :-(
The next thing I can think of is to run initdb under "ktrace -i" and
compare the results with a working system. The output of this is likely
to be voluminous, so don't send it to the list --- but if you'll send it
to me off-list I'll compare it to what I get here.
regards, tom lane
>>> I'm wondering if some of those files are missing, or the symlinks >>> are >>> dangling, on yours. > >> Hmmm..... here is what I have. Looks pretty similar.... > > Running out of easy answers, aren't we :-( > > The next thing I can think of is to run initdb under "ktrace -i" and > compare the results with a working system. The output of this is > likely > to be voluminous, so don't send it to the list --- but if you'll > send it > to me off-list I'll compare it to what I get here. Ufff..... I completely reinstalled Leopard (cause was a bit messy, meanwhile). And thought: Hey, now it should be any problem anymore.... But oups.... it did it again. Gush! So, looked around again on the net and found this message: I found this referenced under bug #1344: locale problem The problem appears to be in going from Linux 2.6.9-5.0.5 to 2.6.9-11 the default LANG environment variable changed from LANG=en_US.UTF-8 to LANG=english_us.8859. Error could be identified by typing locale at the opsys prompt. I fixed by adding to posgres .bash_profile: LANG=en_US.UTF-8; export LANG (http://www.mail-archive.com/pgsql-bugs@postgresql.org/msg12073.html) Also mentioned Linux, it seems to be the same problem with Mac... Putting the LANG... into the .bash_profile settled the problem. Hope this helps! Stef