On 02/22/2015 11:18 AM, jd1008 wrote:
[...]
I have Postgresql-9.3 installed from the Fedora 21 yum repo in order to satisfy any packages that need postgresql. But I need to run Postgresql-9.4 so I disabled the yum postgresql startup via systemd and installed the EDB version of 9.4 into /opt/postgresql [*].
To make the 9.4 one the "system" version, I did two things
- Replaced the postgresql-9.3 executables in /bin/ with
symlinks to their counterparts in /opt/postgresql/bin/. 2) Added a file to /etc/ld.so.d that adds /opt/postgresql/lib to the load library cache and ran ldconfig.
That seems to work well, I can run all the Postgresql tools and everything seems to work correctly, I get the expected 9.4 versions of the tools, etc. Except...
- It breaks openldap. Apparently one of the libraries in
/opt/postgresql/lib is also used by openldap and is not compatible. When trying to start the openldap server: slapd: symbol lookup error: slapcat: undefined symbol: ber_sockbuf_io_udp 2) Some programs still don't work. For example, a simple python cgi script using the psycopg2 module to talk to the database and run under Apache-2.4 that claims it can't find the postgresql socket "/tmp/.s.PGSQL.5432" even though the [...]
I recall I had run into a similar problem many years ago. It was solved by putting a shell wrapper around the apps the broke. In the shell wrapper you set up the not only the execution PATH, but also the LD_LIBRARY_PATH.
Since the number of packages that can be broken might be greater than the packages you desire to be in /opt/.... then you might want to not set up symlinks in /bin and /usr/bin. Instead set up the wrapper shells only for the binaries and libraries and even the man pages pathways in /bin for the specific package(s) you prefer; but be sure to name them differently so they do not clash with existing names in /bin and /usr/bin; just for starting them up from startup scripts which you are aware of. Those starter scripts will set up the env variables from the wrapper shell.
This does not always work, because some programs fork and exec a fixed path in the binaries, a path that might not be what you want.
Thanks. For one of the problem programs I've found I can reproduce the problem running it from a command line. However all my attempts to get it to run by adjusting the environment have been futile so far and its error messages are not very helpful. Don't think it is the forking problem you mentioned because, although it normally runs as a daemon process, it has a foreground option which I presume disables that.
Anyway, for now I'm using the source rpm from fedora-22 suggested in another message which worked well so I can look into the problem more leisurely and wrap it (and the others) once I find the magic incantation.