Forum OpenACS Q&A: libpq.so.2 is not working for 80 port

1: libpq.so.2 is not working for 80 port

Posted by Rocael Hernández Rizzardini on 07/26/01 06:58 PM

Hi!
I have tried all the ways and postings here to resolve this problem 
when the aolserver loads postgres driver:
Notice: modload: loading '/usr/local/aolserver/bin/postgres.so'
[26/Jul/2001:10:54:28][3507.1024][-main-] Warning: modload: failed to 
load '/usr/local/aolserver/bin/postgres.so': 'libpq.so.2: cannot load 
shared object file: No such file or directory'
[26/Jul/2001:10:54:28][3507.1024][-main-] Error: dbdrv: failed to 
load driver 'postgres'
[26/Jul/2001:10:54:28][3507.1024][-main-] Error: dbinit: no such 
default pool 'main'


I'm running aolserver 3.3 + ad13 pgdriver 2.0, under linux RH7.1
when I run a service for port 8000 under nsadmin works without 
problems, but when I run the same service for port 80 under root it 
gives me that error, extrange?

the command I use to run the service for port 80 is under root:
bin/nsd76 -u nsadmin -g web -t service.tcl


please help me, I have been working around this for days and no 
solutions!
Thanks.

2: Response to libpq.so.2 is not working for 80 port (response to 1)

Posted by Antonio Laterza on 07/26/01 07:29 PM

have you already saw :
https://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0000SG&topic_id=11&topic=OpenACS

3: Response to libpq.so.2 is not working for 80 port (response to 1)

Posted by Rocael Hernández Rizzardini on 07/26/01 10:10 PM

yes, I have seen that, I have done everything, and it works when I run aolserver as nsadmin, but when I logged as root doing the command that I put before it doesn't work... why???

4: Response to libpq.so.2 is not working for 80 port (response to 1)

Posted by David Walker on 07/27/01 12:45 AM

what are the permissions on libpq.so.2?

5: Response to libpq.so.2 is not working for 80 port (response to 1)

Posted by Rocael Hernández Rizzardini on 07/28/01 02:23 AM

lrwxrwxrwx    1 postgres web            12 Jun 29 23:15 libpq.so -> libpq.so.2.1
lrwxrwxrwx    1 postgres web            12 Jun 29 23:15 libpq.so.2 -> libpq.so.2.1
lrwxrwxrwx    1 postgres web            12 Jun 29 23:22 libpq.so.2.0 -> libpq.so.2.1
-rwxr-xr-x    1 postgres web         63168 Jun 29 23:15 libpq.so.2.1

6: Response to libpq.so.2 is not working for 80 port (response to 1)

Posted by Yon Derek on 07/28/01 04:30 AM

Do ldd /usr/local/aolserver/bin/postgres.so logged in both as a root and as nsadmin. My guess is that when you're logged in as root linker cannot find libpq.so (you'll see this with ldd because the link will be empty). You can fix it by setting LD_LIBRARY_PATH to contain the path to libpq.so or add this path to /etc/ld.so.conf and running ldconfig (as root).

Of course it might be something completely else.

7: Response to libpq.so.2 is not working for 80 port (response to 1)

Posted by Rocael Hernández Rizzardini on 07/28/01 06:33 AM

The only difference that I see is the number aside the link.... any sugestions? I have alredy done this... /etc/ld.so.conf and running ldconfig (as root).

[root@localhost /root]# ldd /usr/local/aolserver/bin/postgres.so
        libpq.so.2 => /usr/local/pgsql/lib/libpq.so.2 (0x4000a000)
        libc.so.6 => /lib/i686/libc.so.6 (0x4001e000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x4014e000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x4017c000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x4018f000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000)
[root@localhost /root]# su - nsadmin
[nsadmin@localhost aol32]$ ldd /usr/local/aolserver/bin/postgres.so
        libpq.so.2 => /usr/local/pgsql/lib/libpq.so.2 (0x40010000)
        libc.so.6 => /lib/libc.so.6 (0x4001e000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x40150000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x4017e000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x40191000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000)
[nsadmin@localhost aol32]$

8: Response to libpq.so.2 is not working for 80 port (response to 1)

Posted by Jonathan Marsden on 07/28/01 10:51 PM

If this issue is a result of a difference in the environment when logged in as nsadmin compared to root, it might be worth trying:

  su - nsadmin
  su
  bin/nsd76 -u nsadmin -g web -t service.tcl

That will run the command in a root shell but with the environment set up by the nsadmin login. If it then works, you know the issue relates to the shell environment. From there you can probably work it out by doing

  su - nsadmin
  env |sort >/tmp/nsadmin.env
  su -
  env |sort >/tmp/root.env
  diff /tmp/nsadmin.env /tmp/root.env

and checking those diferences one by one until you discover which one is the cause of the problem.

BTW, if you can do an RPM install using my RPMs, that would be one way to totally avoid this sort of thing... they seem work for both port 8000 and port 80 under RH 6.2 and RH 7.1. nsd is then always started by root in the normal RH daemon startup environment.

I think that starting up server processes is best done in a known, somewhat standardized way (such as in an init script) rather than in an interactive shell which may have all sorts of modified stuff set in its environment...

In general, it may not be productive to work on OpenACS 3.x install issues for 'days', when the RPM-based approach exists and takes minutes. I created them precisely so that it wouldn't be necessary to "fight" to get OpenACS installed and working. Is there something the RPM install doesn't do that you needed, or some other special reason for your doing the installation by hand?

9: Response to libpq.so.2 is not working for 80 port (response to 1)

Posted by Rocael Hernández Rizzardini on 07/31/01 12:04 AM

Thank you all, but I haven't been able to make it work... =(

I tried the su & su -  but it didn't work, there is an interesting stuff here:

[root@localhost aol32]# su - nsadmin
[nsadmin@localhost aol32]$ env | grep LIB
LD_LIBRARY_PATH=/ora8/m01/app/oracle/product/8.1.6/lib:/lib:/usr/lib
[nsadmin@localhost aol32]$ su -
Password: 
[root@localhost /root]# env | grep LIB
LD_LIBRARY_PATH=/usr/local/pgsql/lib
[root@localhost /root]# su - nsadmin
[nsadmin@localhost aol32]$ su 
Password: 
[root@localhost aol32]# env | grep LIB
[root@localhost aol32]# su nsadmin
[nsadmin@localhost aol32]$ env | grep LIB
[nsadmin@localhost aol32]$ 

as su - the LD_LIBRARY_PATH is set correctly but doesn't work & as 
su - nsadmin the LD_LIBRARY_PATH is set for oracle (I'm running also oracle 8.1.6) but it works also for postgres...

the postgres driver works as nsadmin but not as root
the oracle driver works well with both users...

10: Response to libpq.so.2 is not working for 80 port (response to 1)

Posted by David Walker on 07/31/01 12:22 AM

another thing to try

ldd libpq.so.2 and check the existence/permissions of the filenames
it returns.

11: Response to libpq.so.2 is not working for 80 port (response to 1)

Posted by Rocael Hernández Rizzardini on 07/31/01 01:34 AM


[postgres@localhost lib]$ ldd libpq.so.2
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x40015000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x40043000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x40056000)
        libc.so.6 => /lib/i686/libc.so.6 (0x4006d000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000)

 then I did: 

[postgres@localhost lib]$ su -
Password: 
[root@localhost /root]# chown 777 /lib/libcrypt-2.2.2.so
[root@localhost /root]# chown 777 /lib/libresolv-2.2.2.so
[root@localhost /root]# chown 777 /lib/libnsl-2.2.2.so
[root@localhost /root]# chown 777 /lib/i686/libc-2.2.2.so
[root@localhost /root]# chown 777 /lib/ld-2.2.2.so


But it didn't work anyway....

12: Response to libpq.so.2 is not working for 80 port (response to 1)

Posted by Rocael Hernández Rizzardini on 07/31/01 01:47 AM

This is the main error:

[30/Jul/2001:17:34:05][7838.1024][-main-] Warning: modload: failed to load '/usr/local/aolserver/bin/postgres.so': 
'libpq.so.2: cannot load shared object file: No such file or directory'

I did this later:
[root@localhost aol32]# cd /usr/lib
[root@localhost lib]# ln -s /usr/local/pgsql/lib/libpq.so.2.1 libpq.so.2
[root@localhost lib]# ls -la libpq*
lrwxrwxrwx    1 root     root           33 Jul 30 17:41 libpq.so2 -> /usr/local/pgsql/lib/libpq.so.2.1

Then run the server again and the error was different

[30/Jul/2001:17:48:28][7924.1024][-main-] Warning: modload: failed to load '/usr/local/aolserver/bin/postgres.so':
'libpq.so.2: cannot load shared object file: Permission denied'

remember that I have:
[root@localhost aol32]# ls -la /usr/local/pgsql/lib/libpq.so.2.1
-rwxrwxrwx    1 postgres web         63168 Jun 29 23:15 
/usr/local/pgsql/lib/libpq.so.2.1


any clues???

13: Response to libpq.so.2 is not working for 80 port (response to 1)

Posted by David Walker on 07/31/01 02:07 AM

<pre>[root@localhost /root]# chown 777 /lib/libcrypt-2.2.2.so
[root@localhost /root]# chown 777 /lib/libresolv-2.2.2.so
[root@localhost /root]# chown 777 /lib/libnsl-2.2.2.so
[root@localhost /root]# chown 777 /lib/i686/libc-2.2.2.so
[root@localhost /root]# chown 777 /lib/ld-2.2.2.so
</pre>
assuming the command in your message is exactly what you typed you
changed the owner to a user 777 instead of changing the
permissions to 777<br>
<br>
the filenames don't match up. were you following symlinks or using
autocomplete or what?

14: Response to libpq.so.2 is not working for 80 port (response to 1)

Posted by Rocael Hernández Rizzardini on 07/31/01 04:10 AM

I did a mistake, now the user is again root and the files are 777 permissions, but it doesn't work any way ... =(

I was following the links in order to change the permissions, the link and the real file have 777 permissions.

15: Response to libpq.so.2 is not working for 80 port (response to 1)

Posted by David Walker on 07/31/01 05:36 AM

currently when you're root are you getting "no such file or
directory" or "permission denied"?

is everything still working fine as nsadmin?

does nsd8x give exactly the same errors as nsd76?

16: Response to libpq.so.2 is not working for 80 port (response to 1)

Posted by Rocael Hernández Rizzardini on 07/31/01 05:50 AM

currently when you're root are you getting "no such file or directory" or "permission denied"?

permission denied, and that's because I have put a link at /usr/lib/, as I said before
[root@localhost aol32]# cd /usr/lib [root@localhost lib]# ln -s /usr/local/pgsql/lib/libpq.so.2.1 libpq.so.2
without this link I got "no such file or directory", in both cases doesn't work...

is everything still working fine as nsadmin?

yes!

does nsd8x give exactly the same errors as nsd76?

yes, the same errors as root, and no error as nsadmin, when you are talking about postgres, because with oracle there isn't problems

17: LD_LIBRARY_PATH considered harmful (response to 1)

Posted by Jonathan Marsden on 07/31/01 11:57 AM

You found it. You just didn't realize what you found!

The alteration in LD_LIBRARY_PATH is almost certainly the cause of your problem. Normal Linux boxes do not change that setting. Those who do play around with it need to understand exactly what it does...

I'd say try (as root)

  unset LD_LIBRARY_PATH
  bin/nsd76 -u nsadmin -g web -t service.tcl

Or if you truly need the Oracle libs too, try

  export LD_LIBRARY_PATH=/ora8/m01/app/oracle/product/8.1.6/lib:/lib:/usr/lib
  bin/nsd76 -u nsadmin -g web -t service.tcl

Assuming that things then work fine, you need to work out where the LD_LIBRARY_PATH is being set to *just* /usr/lib/pgsql and either get rid of that setting, or else set it to a more reasonable value that includes /lib and /usr/lib as well.

Check /root/.bash_profile for one possible place where it might be being set.

You really should not have to add /usr/lib/pgsql to your library path like this. Whose install instructions for PG or AOLserver or OpenACS told you to modify root's LD_LIBRARY_PATH to just /usr/lib/pgsql? Those instructions should probably be corrected.

18: Response to libpq.so.2 is not working for 80 port (response to 1)

Posted by Jonathan Marsden on 07/31/01 01:28 PM

One more thought... you said that libpq.so.* was in /usr/local/lib/pgsql/ but you had LD_LIBRARY_PATH set to /usr/lib/pgsql.

The PG RPMs put libpq.* in /usr/lib (even back at PG 6.5.3 they did this) so there is no lib path issue with it at all, /usr/lib is part of the default lib path. Why did you decide to "be different" about where you install these libraries? How does it benefit your OpenACS installation to do so?

Anyway, if unset LD_LIBRARY_PATH fails for you, maybe

LD_LIBRARY_PATH=/usr/local/lib/pgsql:/usr/local/lib:/lib:/usr/lib

would help nsd find this library? That's not necessarily a sound approach on a production server, but as a test it might be worth trying.

Overall, reviewing your PG installation and checking that it is reasonably standard and self-consistent seems called for.

Long term, I don't recommend messing with LD_LIBRARY_PATH at all, it is probably better to adjust the default library path via the config file /etc/ld.so.conf and the ldconfig utility instead. But you'll need to work out just what the additional lib path(s) needed really truly are or are not, first.

What surprises me is that you seem to be doing a lot of very manual installations on a Red Hat box for software subsystems that have RPMs available. As a result, you are apparently spending days tracking down obscure install issues. Is that really necessary at all?

Have you considered just doing a pg_dumpall to export all your PG data, and then removing your current PG setup and installing PG from the 7.1.2-5PGDG RPM set? This will put PG stuff in the 'normal' Red Hat expected places on your server, and that might well help avoid this sort of installation issue. Then, if you decide you trust my work enough (!), you could even take this to its logical conclusion, and also install AOLserver and OpenACS from (my) RPMs.
RPM, and .deb, and every other packaging system you can name, exist for good reasons. One of them is making installation easier. Why not give RPM a try for your PG install?

19: rpms (response to 1)

Posted by David Walker on 07/31/01 03:05 PM

some of us like installing from source and /usr/local/pgsql/lib is
the standard location in that instance. I haven't had any troube on
any of my systems.

I'd be more interested in using rpms if I understood them better.
can you tell me how to figure out what actions an rpm took or will
take and what files it puts where?

20: rpms 2 (response to 1)

Posted by David Walker on 07/31/01 03:09 PM

I got started in installing from source when the rpm version of
postgres I had would not vacuum the database. When I downloaded
the source and compiled it my problem was solved and I haven't had
any problems since.

21: Response to libpq.so.2 is not working for 80 port (response to 1)

Posted by Roberto Mello on 07/31/01 03:56 PM

'rpm -qlp filename.rpm' will show you where it will put the files. For Debian packages it would be 'dpkg -L packagename'.

22: Examining RPMs, and choosing whether to use them (response to 1)

Posted by Jonathan Marsden on 07/31/01 05:45 PM

Installing a binary RPM does two things: (a) adds a bunch of files (b) adds information about those files and the RPM from which they came into an RPM database. It may also (c) run some scripts, before and/or after adding the files.

You can see what files a binary RPM will install by doing

rpm -qlp somerpmfile.rpm

You can see what scripts it contains by doing

rpm -qp --scripts somerpmfile.rpm

Which of those scripts get executed and how is slightly longer to explain, reading the free online book "Maximum RPM" from http://www.rpm.org is probably a reasonable place to learn more.

However, maybe I'm being too logical here... if someone doesn't like and doesn't understand RPMs, why would they choose to use Red Hat, which is an RPM-based distribution? And how do they deal with managing all the Red Hat supplied RPM-based content on their systems? Those prefering .deb packaging can use Debian. Those who prefer tarballs can use Slackware, or roll their own distribution if they really want to. Rocael chose Red Hat 7.1, which uses RPMs.

RPM isn't perfect. Experts who enjoy source compilation and installs, and who know enough to troubleshoot such setups, can rightly claim that this approach is one they know and love and are more comfortable with. That's cool. But to spend literally *days* struggling with an installation issue rather than use RPMs, on an RPM-based distribution... that's something else, to my mind at least.

If the issue is with *my* RPMs, I want to know what it is -- so I can improve them, so they are of more use to more people in the OpenACS community. If the issue is a blanket rejection of RPMs in general, then that's a subjective judgement call, and I can't expect to sucessfully address that... but in that case, I fail to see how Rocael could have managed to install Red Hat 7.1 on his server without using RPMs 😊

I think we are now homing in on the issue surrounding Rocael's library loading problems -- and I have been proposing tests and ideas that do *not* demand RPMs. But it seems only reasonable to point out the relatively greater ease of an RPM-based installation compared to the difficulties he is experiencing, and to try and find out why such an approach was rejected.

23: VACUUM command not working in PG RPMs? Details please. (response to 1)

Posted by Jonathan Marsden on 07/31/01 06:00 PM

David: Which version of the PG RPMs was the problem of the vacuum command not working happening in, and on what distribution? When was this?

I assume you reported the issue to the RPM maintainer for those RPMs, right? A quick check shows nothing about this in the changelog entries for the PG RPMS I have to hand, nor anywhere in Red Hat Bugzilla against postgresql.

I don't recall VACUUM ever being a problem for my own PG installs from RPM, and I have used PG 6.5.2 (I think), PG 6.5.3, PG 7.0.2, PG 7.0.3 and PG 7.1 and 7.1.2 RPMs.
Can you provide full information, so that we can get this issue taken care of for the subset of the community that does use RPMs? Thanks.

24: VACUUM command not working in PG RPMs? Details please. (response to 1)

Posted by David Walker on 07/31/01 06:16 PM

I did not report it to any of the right people.

I only mentioned it on this thread https://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0000j7&topic_id=OpenACS&topic=11

someone at my local linux user's group gave me some tips about compiling and since it worked I didn't spend any more time worrying about it.

I've used the source in all my installs since then and I haven't had any further problems.

25: Response to libpq.so.2 is not working for 80 port (response to 1)

Posted by Rocael Hernández Rizzardini on 07/31/01 06:22 PM

Well guys, after all this talk, I'm agree using RPMs, as Jonathan says. I didn't use RPMs for this installations because one simple thing, I'm so used to install everything by hand, seeing what I'm doing (at least that's what I think.. =)), so I never tried RPMs for postgres, aolserver or even openacs. But my next installation I'll use it for shure, its just simple and more reliable.

I found my trouble, just as simple as it can be, I followed the advice of Jonathan, 
review step by step your postgres installation.

I saw:

[root@localhost aol32]# ls -la /usr/local/
total 84
drwxr-sr-x   18 root     root         4096 Jul 25 23:30 .
drwxr-xr-x   17 root     root        16384 Jul  6 18:16 ..
drwxr-sr-x    8 nsadmin  web          4096 Jul 25 23:30 aolserver
drwxr-sr-x    2 root     root         4096 Jul  9 07:19 bin
drwxr-xr-x    2 root     root         4096 Feb  6  1996 doc
drwxr-xr-x    2 root     root         4096 Feb  6  1996 etc
drwxr-xr-x    2 root     root         4096 Feb  6  1996 games
drwxr-sr-x    8 nsadmin  web          4096 Jul  8 21:42 icecast
drwxr-sr-x    5 root     root         4096 Jul  9 07:19 include
drwxr-xr-x    2 root     root         4096 Feb  6  1996 info
drwxr-xr-x    3 root     root         4096 Jul  9 07:19 lib
drwxr-xr-x   12 root     root         4096 Jun 29 11:10 man
drwxr-x---    9 postgres web          4096 Jul 30 18:07 pgsql
drwxr-xr-x    2 root     root         4096 Feb  6  1996 sbin
drwxr-sr-x    4 root     root         4096 Jul  9 07:15 share
drwxr-xr-x    3 root     root         4096 Jul  3 12:12 src

then I did:

[root@localhost aol32]# chmod -R 755 /usr/local/pgsql


and it worked!!!

Thank you all for your interest and excelent help!

26: Response to libpq.so.2 is not working for 80 port (response to 1)

Posted by Roberto Mello on 07/31/01 06:29 PM

I like to use packages (in my case, Debian packages) because I like everything neat and nice in my system, with everything in its correct path. Plus Debian has a superb package management system that makes administration and keeping things up-to-date a breeze.

When I want to see what a package will do, I can just get the source of the package (apt-get source packagename) or download the package and run the "ar" command to unpackage it. .deb packages are simply .ar files with special headers.

For things that I can't use a package, I download the source, compile and use a program called "stow" that, by using symlinks, makes installation on correct paths and uninstalling very easy (it deletes the symlinks and you're done).

So yes, using a package system can greatly reduce your headaches. I wish Red Hat would ship the version of APT with RPM support. That way you could just do as we Debian'ers do: "apt-get install whatever" or "apt-get remove whatever" and live happily ever after.

27: FATAL 1: configuration file `postgresql.conf' has wrong permissions (response to 1)

Posted by Rocael Hernández Rizzardini on 08/08/01 07:43 AM

I got this error when I did to chmod 755 -R /usr/local/pgsql


That was a bad idea. 700 is the most permission you should have on the 
   /usr/local/pgsql/data directory. I am not sure why the code is so picky
   about postgresql.conf and not about the data directory as a whole ---
   but it will refuse to start up if postgresql.conf has more than 744
   permissions.

   regards, tom lane



the answer was 744, I did 755 for because in that way the root user can work
   with the driver for the aolserver that looks for libpq.so.2, so now I did 744
   -R in pgsql/ and 755 -R in pgsql/lib/

28: Response to libpq.so.2 is not working for 80 port (response to 1)

Posted by Richard Hamilton on 10/18/01 03:23 PM

This reply is focussed on the question of where one is instructed to modify LD_LIBRARY_PATH. You will find this in section 2.3 of the 'Simple PostgreSQL Install Instructions' by Robert Mello.

I have had the same problem with AOL Server reporting the libpq.so.2 cannot be found. My AOL Server is started from a script as root and the user nsadmin passed as the user to run as.

I will remove the LD_LIBRARY_PATH that I added from the file /etc/profile. I hope this will fix it.

Any other suggestions?