*SOLVED* Problem with PostgreSQL on CentOS VPS
Greetings, I have verified that I do not have this problem on a non-VPS CentOS 4.4 install. This is a fresh vps creation and none of the system files have been altered. I installed postgresql-server in a VPS. I attempt to start it for the first time (service postgresql start) and it goes through the initdb to create all of the runtime files... but then it fails to start. In an effort to get more info, looking at the /etc/init.d/postgresql script, it turns off logging... so I turned logging on to have it log to /var/log/postgresql so I can at least see what the problem is. During the initdb and the start, it appears that there is a locale problem. Here's the error I get: - - - The files belonging to this database system will be owned by user "postgres". This user must also own the server process. The database cluster will be initialized with locale en_US.UTF-8. fixing permissions on existing directory /var/lib/pgsql/data... ok creating directory /var/lib/pgsql/data/base... ok creating directory /var/lib/pgsql/data/global... ok creating directory /var/lib/pgsql/data/pg_xlog... ok creating directory /var/lib/pgsql/data/pg_clog... ok selecting default max_connections... 10 selecting default shared_buffers... 50 creating configuration files... ok creating template1 database in /var/lib/pgsql/data/base/1... FATAL: XX000: failed to initialize lc_messages to "" LOCATION: InitializeGUCOptions, guc.c:1881 initdb: failed FATAL: XX000: failed to initialize lc_messages to "" LOCATION: InitializeGUCOptions, guc.c:1881 - - - Yes, I did some googling but only found one reported fix (unrelated to OpenVZ, and it didn't work). Anyone know how to successfully get postgresql working on a CentOS 4.4 VPS?
Re: Problem with PostgreSQL on CentOS VPS
Hi, I saw this problem several months ago. Something about initializing the database. I have attached my init.d script which fixes this problem. You can diff the files to see what is different. Tell me if this helps you.
Harold, I spent some time going through the script you provided, and while there were some changes, there wasn't really anything significant. Yours was listed as being for postgresql 8.x whereas the stock CentOS postresql is 7.x. Yours had the locale section removed... but that didn't seem to help... as the database initialization and the starting of the server still failed with the following errors: FATAL: XX000: failed to initialize lc_messages to "" LOCATION: InitializeGUCOptions, guc.c:1881 I do appreciate you trying to help.
Hello, is there something in /proc/user_beancounters after unsuccessful start of PostgreSQL?
No, nothing related. I checked sometime later and the ony thing I saw was: tcprcvbuf 0 329808 319488 524288 10 Everything in the VPS has been tuned up quite a bit as part of my default install.
Can anyone else verify this behavior on their machine? 1) Do you have a CentOS 4.4 vps? 2) yum install postgresql-server 3) service postgresql start Does the startup fail?
Yes. Me too. Can't start postgresql. HN : CentOS 4.4 VPS : CentOS 4.4 Postgre : CentOS EL4 (yum repo) Still working around... pls kindly supply me any debug commands, i will post it.. thanks.
Hello, have you managed to get rid of these failcounters? Thanks.
is locale en_US.UTF-8 installed in the VE? I remember Kir was minimizing VE template size and removed most of unneeded locales. Maybe this is the problem for postgresql? Also try stracing it and you will find out what exact file and directory is missing.
I don't know... how does one install "locale en_US.UTF-8"? I don't see any packages for that?!? My guess is that it is not installed... and that that is the problem. Tell me what to do to install it.
I haven't noticed any increase in that failcounter with subsquent tries and I don't it is related.
# ls /usr/lib/locale/en_US.utf8/ -bash-3.00# rpm -qf /usr/lib/locale/en_US.utf8/LC_COLLATE glibc-common-2.3.4-2.19 So just reinstall glibc-common RPM.
also you can strace you postgres to find out exact file name which is missing.
Problem resolved by re-installing glibc-common
Ok, I verified the glibc-common package rpm -V glibc-common ...and nothing was missing... but yes indeed, I had no /usr/lib/locale/en_US.utf8/ directory. I did a force install of a stock CentOS 4.4 glibc-common package and it did include the directory in question. Then I removed postgresql-server... restarted the vps... reinstalled postgresql-server, set it to run in runlevel 3, and started it and it worked fine. - - - - - So does this mean that the package installed by vzcreate from the distro template cache is a subset of glibc-common? And if so, how can I fix that? How can I rebuild my template cache with the full package rather than the minimal one?
Re: Problem resolved by re-installing glibc-common
if you use precreated template, then you just need to reinstall glibc-common in freshly created VE based on this template. Check that required locale was really installed and then pack your VE private area to template.tgz to /vz/template/... check that it works.
- My VPS is live and already serving a few sites and users - When i yum remove glibc-common, there are a lot other packages that set to remove for deps - If so, i did these: Just remove glibc-common from rpm db [root@localhost ~]# rpm -e --justdb --nodeps glibc-common So reinstall stock glibc-common; yum install glibc-common Perhaps, this yum will just add those additional locales which stripped away in original template. Now test again: [root@localhost ~]# ls /usr/lib/locale/en_US.utf8/ LC_ADDRESS LC_IDENTIFICATION LC_MONETARY LC_PAPER LC_COLLATE LC_MEASUREMENT LC_NAME LC_TELEPHONE LC_CTYPE LC_MESSAGES LC_NUMERIC LC_TIME Now as normal: yum install postgresql postgresql-* Start service: /usr/sbin/service postgresql start Woop! p.s.. is this might applicable to other RHEL flavour VEs?
sure, it is related to all the templates where locales are stripped including RHEL (BTW, they are stipped just because consume ~50Mb of disk space)
I think you are doing it the hard... but then again I run my own repos for CentOS and all of the files are local. Just rpm -ivh --force http://whatever/packagename.rpm And that will install over the top of the original.