Обсуждение: fgets failure in Solaris after patching

Поиск
Список
Период
Сортировка

fgets failure in Solaris after patching

От
"Stephan, Richard"
Дата:

Rebuilt the PostgreSQL server software because we were patching up from 9.0.4 to 9.0.8.  Deployed software and received the following error when trying to restart server.

 

fgets failure: Error 0

The program postgres is needed by pg_ctl but was not found in the same directory as pg_ctl

 

9.0.4 works.  9.0.8 does not.

 

 

The information in this email is confidential and may be legally privileged against disclosure other than to the intended recipient. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please immediately delete this message and inform the sender of this error.

Re: fgets failure in Solaris after patching

От
Tom Lane
Дата:
"Stephan, Richard" <RStephan@nyiso.com> writes:
> Rebuilt the PostgreSQL server software because we were patching up from 9.0.4 to 9.0.8.  Deployed software and
receivedthe following error when trying to restart server. 
> fgets failure: Error 0
> The program postgres is needed by pg_ctl but was not found in the same directory as pg_ctl

Is that a verbatim copy of the error message?  When I try intentionally
provoking this type of failure (by renaming the postgres executable out
of the way), 9.0 pg_ctl gives me this:

$ pg_ctl start
The program "postgres" is needed by pg_ctl but was not found in the
same directory as "/home/tgl/version90/bin/pg_ctl".
Check your installation.
$

The lack of double quotes and the lack of a full path to the pg_ctl
program make me wonder if you're running some really old copy of
pg_ctl instead of the 9.0 version as intended.

Anyway, if you didn't copy-and-paste exactly, what the error indicates
is that pg_ctl tried to execute "postgres -V" and didn't get any output.
What happens when you try that directly?

            regards, tom lane

Re: fgets failure in Solaris after patching

От
"Stephan, Richard"
Дата:
Sorry, that was not the verbatim message, (a cut & paste mistake).

More information (9.0.8):

$ pg_ctl start
Killed
fgets failure: Error 0
The program "postgres" is needed by pg_ctl but was not found in the
same directory as "/opt/postgres/9.0/bin/pg_ctl".
Check your installation.

$ postgres -V
ld.so.1: postgres: fatal: libc.so.1: version `SUNW_1.22.7' not found (required by file /opt/postgres/9.0/bin/postgres)
ld.so.1: postgres: fatal: /usr/lib/libc.so.1: wrong ELF class: ELFCLASS32
Killed

$ ldd /opt/postgres/9.0/bin/postgres
        libssl.so.0.9.8 =>       /opt/postgres/externalDeps/lib/libssl.so.0.9.8
        libcrypto.so.0.9.8 =>    /opt/postgres/externalDeps/lib/libcrypto.so.0.9.8
        libnsl.so.1 =>   /lib/64/libnsl.so.1
        libsocket.so.1 =>        /lib/64/libsocket.so.1
        libm.so.2 =>     /lib/64/libm.so.2
        libldap-2.4.so.2 =>      /opt/postgres/externalDeps/lib/libldap-2.4.so.2
        libc.so.1 =>     /lib/64/libc.so.1
        libc.so.1 (SUNW_1.22.7) =>       (version not found)
        libdl.so.1 =>    /lib/64/libdl.so.1
        libgcc_s.so.1 =>         /usr/sfw/lib/64/libgcc_s.so.1
        libmp.so.2 =>    /lib/64/libmp.so.2
        libmd.so.1 =>    /lib/64/libmd.so.1
        libscf.so.1 =>   /lib/64/libscf.so.1
        liblber-2.4.so.2 =>      /opt/postgres/externalDeps/lib/liblber-2.4.so.2
        libresolv.so.2 =>        /lib/64/libresolv.so.2
        libgen.so.1 =>   /lib/64/libgen.so.1
        libsasl.so.1 =>  /usr/lib/64/libsasl.so.1
        libgss.so.1 =>   /usr/lib/64/libgss.so.1
        libdoor.so.1 =>  /lib/64/libdoor.so.1
        libuutil.so.1 =>         /lib/64/libuutil.so.1
        libcmd.so.1 =>   /lib/64/libcmd.so.1
        /platform/SUNW,Sun-Fire-V890/lib/sparcv9/libc_psr.so.1
        /platform/SUNW,Sun-Fire-V890/lib/sparcv9/libmd_psr.so.1


*******
9.0.4 for comparison:

$ postgres -V
postgres (PostgreSQL) 9.0.4

$ ldd /opt/postgres/9.0/bin/postgres
        libssl.so.0.9.8 =>       /opt/postgres/externalDeps/lib/libssl.so.0.9.8
        libcrypto.so.0.9.8 =>    /opt/postgres/externalDeps/lib/libcrypto.so.0.9.8
        libnsl.so.1 =>   /lib/64/libnsl.so.1
        librt.so.1 =>    /lib/64/librt.so.1
        libsocket.so.1 =>        /lib/64/libsocket.so.1
        libm.so.2 =>     /lib/64/libm.so.2
        libldap-2.4.so.2 =>      /opt/postgres/externalDeps/lib/libldap-2.4.so.2
        libc.so.1 =>     /lib/64/libc.so.1
        libdl.so.1 =>    /lib/64/libdl.so.1
        libgcc_s.so.1 =>         /usr/sfw/lib/64/libgcc_s.so.1
        libmp.so.2 =>    /lib/64/libmp.so.2
        libmd.so.1 =>    /lib/64/libmd.so.1
        libscf.so.1 =>   /lib/64/libscf.so.1
        libaio.so.1 =>   /lib/64/libaio.so.1
        liblber-2.4.so.2 =>      /opt/postgres/externalDeps/lib/liblber-2.4.so.2
        libresolv.so.2 =>        /lib/64/libresolv.so.2
        libgen.so.1 =>   /lib/64/libgen.so.1
        libsasl.so.1 =>  /usr/lib/64/libsasl.so.1
        libgss.so.1 =>   /usr/lib/64/libgss.so.1
        libdoor.so.1 =>  /lib/64/libdoor.so.1
        libuutil.so.1 =>         /lib/64/libuutil.so.1
        libcmd.so.1 =>   /lib/64/libcmd.so.1
        /platform/SUNW,Sun-Fire-V890/lib/sparcv9/libc_psr.so.1
        /platform/SUNW,Sun-Fire-V890/lib/sparcv9/libmd_psr.so.1



Thank you for helping to point out where the actual problem lies.  The ldd command is showing that there is a library
issuewith trying to use the 9.0.8 version. 

        libc.so.1 =>     /lib/64/libc.so.1
        libc.so.1 (SUNW_1.22.7) =>       (version not found)

Richard

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Friday, July 27, 2012 1:21 PM
To: Stephan, Richard
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] fgets failure in Solaris after patching

"Stephan, Richard" <RStephan@nyiso.com> writes:
> Rebuilt the PostgreSQL server software because we were patching up from 9.0.4 to 9.0.8.  Deployed software and
receivedthe following error when trying to restart server. 
> fgets failure: Error 0
> The program postgres is needed by pg_ctl but was not found in the same
> directory as pg_ctl

Is that a verbatim copy of the error message?  When I try intentionally provoking this type of failure (by renaming the
postgresexecutable out of the way), 9.0 pg_ctl gives me this: 

$ pg_ctl start
The program "postgres" is needed by pg_ctl but was not found in the same directory as "/home/tgl/version90/bin/pg_ctl".
Check your installation.
$

The lack of double quotes and the lack of a full path to the pg_ctl program make me wonder if you're running some
reallyold copy of pg_ctl instead of the 9.0 version as intended. 

Anyway, if you didn't copy-and-paste exactly, what the error indicates is that pg_ctl tried to execute "postgres -V"
anddidn't get any output. 
What happens when you try that directly?

            regards, tom lane
The information in this email is confidential and may be legally privileged against disclosure other than to the
intendedrecipient. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you
arenot the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in
relianceon it, is prohibited and may be unlawful. Please immediately delete this message and inform the sender of this
error. 


Re: fgets failure in Solaris after patching

От
Tom Lane
Дата:
"Stephan, Richard" <RStephan@nyiso.com> writes:
> More information (9.0.8):

> $ pg_ctl start
> Killed
> fgets failure: Error 0
> The program "postgres" is needed by pg_ctl but was not found in the
> same directory as "/opt/postgres/9.0/bin/pg_ctl".
> Check your installation.

> $ postgres -V
> ld.so.1: postgres: fatal: libc.so.1: version `SUNW_1.22.7' not found (required by file
/opt/postgres/9.0/bin/postgres)
> ld.so.1: postgres: fatal: /usr/lib/libc.so.1: wrong ELF class: ELFCLASS32
> Killed

Ah-hah, so your problem is a library mismatch between where you compiled
postgres and where you're trying to run it.

This is not the first time we've had to suggest that people run
"postgres -V" manually to debug a problem.  I see that find_other_exec()
intentionally routes the stderr output of that to /dev/null:

    snprintf(cmd, sizeof(cmd), "\"%s\" -V 2>%s", retpath, DEVNULL);

It strikes me that this is just a damfool idea.  Generally there should
be no stderr output, and if there is some, hiding it from the user is
not helpful.  Does anyone object to removing that redirection?

            regards, tom lane