Thread: PostgreSQL 9.2.4 + CentOS 6.5 64 bit - segfault error in initdb

Hi,
On Wed, 2014-06-04 at 17:50 +0530, Bhushan Pathak wrote:

> The RPM get installed successfully, but when I issue the "service
> postgresql-9.2 initdb" command, it gets stuck for 5-10 minutes & then
> says failed. The pgstartup.log file has only 1 line -
> Segmentation fault (core dumped)

Can you please edit /etc/init.d/postgresql-9.2, go to line 235 which is
like this:

http://svn.pgrpms.org/browser/rpm/redhat/9.2/postgresql/EL-6/postgresql.init#L235

and then add -d parameter after initdb, and run it again? This will
throw debug messages to log file, which may give input to the people who
can find out the issue.

Regards,

--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR


--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

On 06/04/2014 05:20 AM, Bhushan Pathak wrote:
> Hello,
>
> I have installed the following RPM on CentOS 6.5 64 bit -
> uuid-1.5.1-4.rhel5.x86_64
> postgresql92-contrib-9.2.4-1PGDG.rhel5.x86_64
> postgresql92-9.2.4-1PGDG.rhel5.x86_64
> postgresql92-server-9.2.4-1PGDG.rhel5.x86_64
> postgresql92-libs-9.2.4-1PGDG.rhel5.x86_64
>
> Kernel version is -
> kernel-2.6.32-431.17.1.el6.x86_64
> kernel-firmware-2.6.32-431.17.1.el6.noarch
>
> The CentOS server is a VM running on top of VMware with 4CPUs [2.4GHz
> each] & 9GB of RAM. No other application runs on this server.
>
> The RPM get installed successfully, but when I issue the "service
> postgresql-9.2 initdb" command, it gets stuck for 5-10 minutes & then
> says failed. The pgstartup.log file has only 1 line -
> Segmentation fault (core dumped)

Is the data directory created?

>
> Any idea what is going wrong? How to fix it? I'm open to try multiple
> installation attempts [as it is a VM & I can re-install as needed]

What happens if you use pg_ctl to initdb the cluster?

>
> Thanks
> Bhushan Pathak


--
Adrian Klaver
adrian.klaver@aklaver.com

On 06/05/2014 09:11 AM, Bhushan Pathak wrote:
> It did create the data directory as well pg_log directory. I ran the
> initdb again with -d option, but it still printed the same line in the
> startup log, nothing more.
> $SU -l postgres -c "$PGENGINE/initdb --pgdata='$PGDATA' --auth='ident'
> $LOCALESTRING -d" >> "$PGLOG" 2>&1 < /dev/null
>
> I then ran the pg_ctl command as follows
> su - postgres
> cd /usr/pgsql-9.2/bin
> ./pg_ctl initdb -D /var/lib/pgsql/data -o '--auth="ident"
> --locale=en_US.UTF-8 -d'
>

Try this with initdb directly. I personally am confused with what pg_ctl
does with -o since -d is an option to postgres not initdb and --locale
is an option to initdb not postgres.


> creating collations ... initdb: locale name has non-ASCII characters,
> skipped: "bokmål"
> initdb: locale name has non-ASCII characters, skipped: "français"
> could not determine encoding for locale "hy_AM.armscii8": codeset is
> "ARMSCII-8"
> could not determine encoding for locale "ka_GE": codeset is "GEORGIAN-PS"
> could not determine encoding for locale "ka_GE.georgianps": codeset is
> "GEORGIAN-PS"
> could not determine encoding for locale "kk_KZ": codeset is "PT154"
> could not determine encoding for locale "kk_KZ.pt154": codeset is "PT154"
> could not determine encoding for locale "tg_TJ": codeset is "KOI8-T"
> could not determine encoding for locale "tg_TJ.koi8t": codeset is "KOI8-T"
> could not determine encoding for locale "thai": codeset is "TIS-620"
> could not determine encoding for locale "th_TH": codeset is "TIS-620"
> could not determine encoding for locale "th_TH.tis620": codeset is "TIS-620"
> could not determine encoding for locale "vi_VN.tcvn": codeset is
> "TCVN5712-1"

Looks like Postgres is having a problem determining what the locale is
for your setup.

What is your locale?


> Success. You can now start the database server using:
>
>      /usr/pgsql-9.2/bin/postgres -D /var/lib/pgsql/data
> or
>      /usr/pgsql-9.2/bin/pg_ctl -D /var/lib/pgsql/data -l logfile start
>
>
> And also seemed to be successful. But when I quit the postgres shell,
> tried to restart the service as root user, it has failed with the
> following message on CLI -

So you are using the system start script?

What happens if you do pg_ctl start -D /var/lib/pgsql/data as the
postgres user?


> Stopping postgresql service:                               [  OK  ]
> Starting postgresql service:                              [FAILED]
>
> pgstartup log has the same line  -
> Segmentation fault (core dumped)
>
> Where is this core dump file generated? How do we proceed further from here?

Take a look at this Wiki page:

https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD

>
> Thanks
> Bhushan Pathak
>
>
>


--
Adrian Klaver
adrian.klaver@aklaver.com

On 06/06/2014 12:29 AM, Bhushan Pathak wrote:
> My locale is set to en_US.UTF-8, that's what the service script is using.
>
>   If I try to start the server with pg_ctl command, it does start -
> ./pg_ctl start -D /var/lib/pgsql/data -l /tmp/logfile
> server starting
>
> What would this mean? The service script does not work but manually
> issuing pg_ctl commands work.

The service script is not correct?

Could you post the contents of the script?

Do you have another instance of Postgres installed by any chance?

Have you had another instance/version installed in the past, something
that might have left parts of itself around?

>
> Thanks
> Bhushan Pathak
>



--
Adrian Klaver
adrian.klaver@aklaver.com

On 06/06/2014 12:29 AM, Bhushan Pathak wrote:
> My locale is set to en_US.UTF-8, that's what the service script is using.
>
>   If I try to start the server with pg_ctl command, it does start -
> ./pg_ctl start -D /var/lib/pgsql/data -l /tmp/logfile
> server starting
>
> What would this mean? The service script does not work but manually
> issuing pg_ctl commands work.

Meant to add to my previous post:

Does anything show up in the system log when the service script fails,
beside the segfault?

>
> Thanks
> Bhushan Pathak



--
Adrian Klaver
adrian.klaver@aklaver.com

Bhushan Pathak <bhushan.pathak02@gmail.com> writes:
>>> Stopping postgresql service:                              [  OK  ]
>>> Starting postgresql service:                              [FAILED]
>>>
>>> pgstartup log has the same line  -
>>> Segmentation fault (core dumped)
>>>
>>> Where is this core dump file generated? How do we proceed further from
>>> here?

FWIW, I'd expect any such core to be generated either in postgres'
home directory or the $PGDATA directory, depending on what is
failing when.  If you don't see a core, it's likely because the failing
program is running under "ulimit -c 0", which is the default environment
for daemons (for security reasons).  Try adding "ulimit -c unlimited"
to the start script and/or the postgres user's ~/.bash_profile to see
if you can get a core file for debugging.

The issue seems like it must trace back to some difference in the
normal shell environment of the postgres user versus the environment
set up by "service" ... but it's not clear yet what that difference
is.

Also, it's not very clear whether you're trying to use the Red Hat/CentOS
packaging of PG, or the PGDG packaging.  As Adrian alluded to, those are
not terribly compatible --- if you've got fragments of both laying about,
that could be causing issues.

            regards, tom lane

Hi,

On Mon, 2014-06-09 at 14:23 +0530, Bhushan Pathak wrote:
> A core file was not generated.

Can you please also install the -debuginfo package?

Regards,

--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

On 06/09/2014 04:02 AM, Bhushan Pathak wrote:
> Trying to figure out shell environment differences between the service
> script & postgres shell, if I comment out the following variable in
> profile file/add them after performing initdb operation, the postgresql
> operations seem to work fine -


In the init script the only thing that is exported that could possibly
conflict is PGDATA which is the same as your PG_HOME, but they are
assigned to different variables so I am not sure where the conflict
would occur.

> PATH=$PATH:/usr/pgsql-9.2/bin
> export PATH
This seems alright, though not needed by the script as it uses the full
path when calling the binaries.

> export POSTGRESQL_JDBC_DRIVER=/opt/lib/postgresql-9.2-1003.jdbc4.jar
Not sure how the above would have any effect with the initdb as Java is
not involved.

> export PG_HOME=/var/lib/pgsql/data/
This is redundant, I would just use the PGDATA environment variable
exported by the script.

>
> These variables are needed by a few cron scripts that would be installed
> later on after my postgres config completes successfully.
>
> The yum postgresql link I used earlier to download the RPM dos not the
> debuginfo package for 9.2.4 version. Will it be OK to use the latest
> debuginfo package with the rest being on version 9.2.4? Or I will have
> to use all the latest RPM packages?
>
> Thanks
> Bhushan Pathak
>
>
>



--
Adrian Klaver
adrian.klaver@aklaver.com

On 06/09/2014 01:53 AM, Bhushan Pathak wrote:
>
> I do not have any earlier versions of postgres installed, neither a
> parallel instance running. In the pgstartup.log file, only the segfault
> error is recorded, nothing else.
>
> I have downloaded the following RPMs from
> http://yum.postgresql.org/9.2/redhat/rhel-5.6-x86_64/

I thought you where on Centos 6.5 would you not need?:

http://yum.postgresql.org/9.2/redhat/rhel-6-x86_64/repoview/




--
Adrian Klaver
adrian.klaver@aklaver.com