Thread: BUG #12241: uninitialized value $lib_path

The following bug has been logged on the website:

Bug reference:      12241
Logged by:          Aleks
Email address:      aleks.dark@inbox.ru
PostgreSQL version: 9.3.5
Operating system:   Debian
Description:

Similar error to case in 2011, but this time no upgrade available. Any hints
what is going wrong?


In command line:
$ psql --version

Use of uninitialized value $lib_path in concatenation (.) or string at
/usr/bin/psql line 132.
psql (PostgreSQL) 9.3.5


------
$ ldd /usr/lib/postgresql/9.3/bin/psql
    linux-vdso.so.1 =>  (0x00007ffff1559000)
    libpq.so.5 => /usr/lib64/libpq.so.5 (0x00007f95adb92000)
    libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 (0x00007f95ad932000)
    libedit.so.2 => /usr/lib64/libedit.so.2 (0x00007f95ad709000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f95ad37d000)
    libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x00007f95acf85000)
    libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00007f95accb0000)
    libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2
(0x00007f95acaac000)
    libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00007f95ac86d000)
    libldap_r-2.4.so.2 => /usr/lib64/libldap_r-2.4.so.2 (0x00007f95ac61b000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f95ac3ff000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f95ac1fb000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f95abfe3000)
    libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f95abdd6000)
    libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f95abbad000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f95ae097000)
    libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00007f95ab983000)
    libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007f95ab77a000)
    libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1
(0x00007f95ab576000)
    libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2
(0x00007f95ab35f000)
    liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007f95ab150000)
    libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00007f95aaf35000)
    libgnutls.so.26 => /usr/lib64/libgnutls.so.26 (0x00007f95aac74000)
    libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11
(0x00007f95aa9f5000)
    libtasn1.so.3 => /usr/lib64/libtasn1.so.3 (0x00007f95aa7e3000)
    libp11-kit.so.0 => /usr/lib64/libp11-kit.so.0 (0x00007f95aa5d1000)
    libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0
(0x00007f95aa3ce000)


----------
apt-cache policy libedit2
libedit2:
  Installed: 2.11-20080614-5
  Candidate: 2.11-20080614-5
  Version table:
 *** 2.11-20080614-5 0
        500 http://ftp.fi.debian.org/debian/ wheezy/main amd64 Packages
        100 /var/lib/dpkg/status

aleks.dark@inbox.ru writes:
> Similar error to case in 2011, but this time no upgrade available. Any hints
> what is going wrong?

> Use of uninitialized value $lib_path in concatenation (.) or string at
> /usr/bin/psql line 132.
> psql (PostgreSQL) 9.3.5

> $ ldd /usr/lib/postgresql/9.3/bin/psql

Note that the complaint is specifically about /usr/bin/psql, not
/usr/lib/postgresql/9.3/bin/psql.

I would guess that /usr/bin/psql is a Perl script that is supposed to
invoke the real psql but is going off the rails somehow.  You will need
to speak with whoever produced the PG package you're using, because any
such script would've been supplied by the packager, not by the Postgres
community.

            regards, tom lane

aleks.dark wrote
> The following bug has been logged on the website:
>
> Bug reference:      12241
> Logged by:          Aleks
> Email address:

> aleks.dark@

> PostgreSQL version: 9.3.5
> Operating system:   Debian
> Description:
>
> Similar error to case in 2011, but this time no upgrade available. Any
> hints
> what is going wrong?
>
>
> In command line:
> $ psql --version
>
> Use of uninitialized value $lib_path in concatenation (.) or string at
> /usr/bin/psql line 132.
> psql (PostgreSQL) 9.3.5
>
>     libedit.so.2 => /usr/lib64/libedit.so.2 (0x00007f95ad709000)

Assuming this psql wrapper is the same as can be obtained via:

https://wiki.postgresql.org/wiki/Apt

The specific problem is two-fold:

1) Your version does not have libreadline linked in
2) The location of libedit is under "/usr/lib64" instead of "/lib" which is
where the wrapper script checks for it.

A little out of my experience here but:

The wrapper script assumes it will find libedit in the "/lib" subdirectory
and uses the portion of the path between "/lib" and "libedit" to go and try
to find a usable sibling readline.so.  Since there is none no valid value of
"$lib_path" is captured from the regular expression and no useful default is
provided in its absence.

Since libedit is indeed linked and the failure to load readline is non-fatal
you simply get the warning about the lib_path variable not being set but the
call to the underlying psql command succeeds.

As Tom said this is a packaging issue for "Debian" - though I suspect that
you have something unusual going on relative to what a typically
installation would look like.  The link above will launch you into the
proper area for finding information and support for Debian-based
distributions.

David J.





--
View this message in context:
http://postgresql.nabble.com/BUG-12241-uninitialized-value-lib-path-tp5830809p5830826.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.

Hello All,

Issue can be closed, found the solution, sorry for disturbance.

Thanks, Tom, for an attempt, but actually the issue was in 3 things of postgresql:

1. /tmp/.s.**** and /var/run/postgresql ownage and chmod settings. (+ pid deleting if not helping and killing all (theoretically) running servers by reported ports.)
2. The server is meant to be started by postgres user, not '-u postgres' . (Don't know why, it just is so... Took long time to figure it out, would be great if someone can give a logical explanation.)
3. Database must by initiated by postgres, and chmod settings of global/pg_filenode.map should be checked. (Default were misconfigured in Debian...)

P.S. /usr/bin/psql is recommended install dir by guide if building postgresql from sources, or using distributed package manager.
P.P.S. Just in case someone used guide, and this solution didn't help to fix the issue, extrainfo: Manual build was installed to other than recommended place ( to avoid messing with package manager.), so extraissues are possible.

--
Lex


Mon, 15 Dec 2014 20:19:38 -0500 от Tom Lane <tgl@sss.pgh.pa.us>: